Enabling Two-Way Communication in Crisis360

One of the initiatives at Smartbridge that contributes to our culture of continuous improvement is the quarterly hackathon. During a recent hackathon, our team accepted the challenge of integrating two-way communication in Crisis360.

Diving into the Challenge

During each Smartbridge hackathon, multiple teams comprised from each practice come together to build creative solutions for challenging problems, all within a 12-hour day. The challenge of enabling two-way communication on Crisis360 was certainly no easy venture. Put simply, Crisis360 is a comprehensive emergency and incident management software, that allows businesses to get real-time status updates on any resource, location or entity during a crisis. Crisis360 was originally designed to send broadcast messages to all users who are logged into the mobile application. However, it lacked the ability to send messages and receive responses from people who are not on the app.

Two-Way Communication in Crisis 360

The Process

The day started at 9am with a brief presentation of projects, team members and overall goals. Our goal was to build the basic back-end and web services required to enable two-way communication in Crisis360. Our primary objectives were the following:

  • Ensure flexibility and efficient configuration.

  • Support both Crisis360 users and non-users with the integration. 

  • Support in-app communication, along with regular device communication.

Two-Way Communication in Crisis 360

Once everyone on the team understood their responsibility in the project, the UX team redesigned the user interface to incorporate the new functionality within the current application. While white boarding their ideas, here is a sketch the team worked up:

Two-Way Communication in Crisis 360

As the UX team got their creative juices flowing, the back-end team started brainstorming the changes needed to support the concept of two-way communication in Crisis360. Despite trouble with the large format printer, the team was able white board the updated data model, and the web API design.

Two-Way Communication on Crisis 360

Additional Challenges

As the day progressed, several challenges arose when our team attempted to translate the design into code.  Our team worked against the clock to resolve them in time for the final presentation, due at 7pm. The following issues caused us to shift our strategy:

  • Lack of familiarity with the existing Crisis360 components and technologies.

  • Not having a fully functional development environment.

  • Key resources who had background knowledge of the Crisis360 system were not present. 

Finding the Solution

Due to several challenges, we were unable to complete everything we originally set out to accomplish. However, we pieced together a solution that acted as a starting point for building a fully functional two-way communication feature. Here are the milestones we were able to overcome:

  • A web application POC for sending SMS messages. 

  • High level database design to support a two-way communication feature.

  • Database tables with test data and stored procedures.

At the end of the day, we realized we set out to accomplish a goal too ambitious for a 1-day hackathon. However, our team learned how to use Twilio API for sending and receiving SMS messages from web applications. We also gained experience handling a high quality deliverable under short time constraints. Most importantly, our teamwork abilities strengthened while working in an agile environment. Overall, it was an enjoyable experience for our team.

Explore our Solutions

Smartbridge hackathons are one of the things that spark creative solutions among all of our practices. Learn more about these solutions and how they can help your business.

Smartbridge Solutions
By |2018-11-20T09:06:36+00:00November 20, 2018|Categories: Enterprise Mobility|

Receive more posts just like this, right in your inbox!

↓ Sign up for emails with the latest from Smartbridge.

Sign up for emails
Or add this feed URL to your favorite blog reader.