How do you get a volunteer-driven application built? Throw a codeathon!

On Friday, February 12, a group of coders on Twitch will be working on Two Weeks Ready - and you can join in!

First up will be Jeff Fritz at https://www.twitch.tv/csharpfritz from 10 am to noon Eastern time.

Then, from noon to 2 pm Eastern, Michael Jolley at https://www.twitch.tv/baldbeardedbuilder

Dave Paquette takes over from 2 pm to 4 pm Eastern at https://www.twitch.tv/davepaquette

Finally, Carey Payette will be streaming from 4 pm to 6 pm Eastern at https://www.twitch.tv/codingbandit

During the livestream, you can see what is parts of 2WR are under construction and help with testing - all the information about Two Weeks Ready is on GitHub at https://github.com/HTBox/TwoWeeksReady

Take 2WR out for a spin, and feel free to add issues where you see problems with the app - and if you're up for some coding, comment on an issue in GitHub that you're interested in and work with us to build the application!

And expect more codeathons in the future!

At HTBox, we've been working on the Two Weeks Ready (2WR) app for a few months now.

One of the architectural decisions we've made early on for 2WR is to build it as a Progressive Web App rather than a native mobile application.

I hope to address the reasoning behind this decision in this blog post.

Without a doubt, native mobile applications for iOS and Android offer the maximum utilization of the mobile platform in question - access to the most features, the most performance, and distribution through the app store.

However, when it comes to building an application like 2WR natively, that essentially means creating the application twice - once in Objective C (or Swift) for iOS and again in Java for Android. Keeping the two versions of the application synchronized for features is tricky, as is deployment - every time you update the application, you need to go through the certification process into the app store. App store deployment isn't too big a deal on the Android side, but for iOS, it can be time-consuming, especially if Apple pushes back on the application for some reason. In some cases, it can take days for updates to the applications to appear in the app store.

Also, you can get into a situation where a smartphone operating system update breaks your application. Even if you can fix the problems with application immediately, there will be a delay in deployment as the application is reviewed. 

The Progressive Web App (PWA) approach to application building on smartphones works around these problems - you have an almost 100% common codebase for iOS and Android. And the coding approach for PWAs is almost always Javascript, which means there are plenty of developers available to work on it.

And PWAs do not need to be distributed through the app stores, so there's no waiting for new versions - in fact, every time someone fires up the application, they always get the latest version. 

For an application like Two Weeks Ready, there aren't any features dependent on a particular hardware platform. Everything that the application needs to do is available within the constraints of the PWA. And the ability to push out new versions and keep everyone up to date is key - you don't want stale information about disaster preparedness going out!

We chose to build Two Weeks Ready as a Progressive Web App for all these issues:

• because it made it easier for volunteer developers to contribute to the application
• made it easier to get the application into the hands of people who need it
• we're able to keep the application working through OS updates
• when updates are needed, get those updates into the hands of the users of the application as quickly as possible

From the team at Washington State Emergency Management Division

Disasters ranging from earthquakes to global pandemics can strike when you least expect them to. It is crucially important to both prepare yourself and your family before a disaster and know how to protect yourself and your family during one. To help preparedness be simple and easy, our team is developing a brand new app, called 2 Weeks Ready, to help you and your family prepare before a disaster strikes and remember what to do during a disaster. 

The 2 Weeks Ready app will be the first app of its kind to provide a hands on and interactive disaster preparedness experience. Users will be able to create and share their family disaster plans together and securely with anyone they choose. The 2 Weeks Ready app also includes an emergency kit calculator to help determine exactly how many supplies are needed to reach the goal of being “2 weeks ready.”  With learning how much toilet paper your family needs for two weeks, receiving reminders to update your family plan, and establishing an out-of-area contact, the 2 Weeks Ready app is ready to help through every step of your preparedness journey.  

Join us in developing the 2 Weeks Ready app as a resilient user interface that helps its users survive and thrive through disasters to come.    

Can you and your family take care of yourselves for two weeks after a natural disaster?

At Humanitarian Toolbox, we've focused on helping developers contribute to projects that can help people be ready when disaster strikes. For the past few months, we've been working closely with the disaster preparedness folks at the Washington State Emergency Management Division to build an application to help families and communities prepare to be Two Weeks Ready.

The goal of Two Weeks Ready is to utilize smartphones and cloud technology to help your family get prepared for disaster by organizing the information your family will need when disaster strikes.

The first steps are preparedness, that is, having lists of what you'll need for your family to survive. The smartphone application will maintain lists of what you need and what you have, manage the expiration dates of consumables, and in general, make it easier for you to put together survival kits for you and your family.

Beyond the preparedness kits, there's also key information your family will need - where to meet after a disaster, contact information, and other key data that can be entered into one family phone and synchronized between them all.

During a natural disaster, infrastructure like wireless data can be unreliable. A key feature of Two Weeks Ready is to have all the information you need already loaded on your family's smartphones before the disaster. That way, everyone in your family has what they need without having to connect to the internet after a natural disaster.

The Two Weeks Ready application is open-source and developed on GitHub at https://github.com/HTBox/TwoWeeksReady

If you'd like to be part of what we're working on, take a look at the issues available and chat with us about how you'd like to contribute - we'd love to have you be part of this project!

Find out more on our project page as well as in our Github repository

Whether you want to explore new ideas or learn specific skills, sharing your time and expertise can save lives.

HTBox is a charity that supports disaster relief organizations with open source software and services. Here, we are developers, designers, testers, analysts, copywriters, program managers and industry professionals who want to contribute our unique skills into disaster relief aid. Humanitarian Toolbox strives to create software and programs for relief organizations that are ready in times of need; for example, volunteers may create apps that map the spread of disease or maintain software that optimizes the delivery of relief supplies.

Why do we emphasize open source software?

Open source software allows us to maintain our focus on sustainability. In fact, much of the software used in disaster relief is outdated or built in the haste of a current crisis. HTBox is committed to the routine development of all of our projects to keep them current and always improving.

Additionally, openly sourced software lifts barriers for contributors and users of our software. This makes it an ideal choice for volunteer developers looking to make a difference and the organizations that need help. Additionally, it allows anyone to access the software and take it for a spin.

How do you build the optimal program or app for the right folks?

Some of our projects are developed from scratch by working closely with a specific relief organization. In this case, HTBox gathers the requirements for the project from the relief organization, breaks it down into work items in GitHub, and then runs code-a-thons to get the software written with the generous help of our volunteers. This way developers can concentrate on development and work can continue remotely which allows volunteers to work wherever and whenever they like.

To view our repositories, visit our GitHub account here. 

Why is HTBox interested in preserving and maintaining older software?

During a crisis, software may be developed within a disaster relief organization. When the crisis is over, however, the individuals involved in creating it often move on; otherwise, the software languishes on a shelf. Instead of allowing valuable resources to deteriorate, HTBox takes on these projects to archive and maintain for future use.

How can I become a volunteer for Humanitarian Toolbox?

First, we recommend signing up for our mailing list so that we can keep you up to date with the latest.

Second, head over to GitHub and, take a look at our projects! If there are any items that you think you could contribute todo, go for it! Work items marked, “Up for GrabJump In,s” mean we’re looking for someone to get developing on it. There are many contributors to HTBox projects that work on their own time weekly by picking up work items from the repository and contributing new code.

Of course, If you're not a developer but still want to contribute to HTBox, oour volunteer base is not limited to developers! It takes many skills to build great software and we're always on the lookout for designers, testers, analysts, copywriters, program managers, project leaders and more.

If you want to volunteer but are unsure how your skills can be put to use, shoot us an e-mail at volunteer@htbox.org!As the software continues to improve, whenever new disasters strike and disaster relief organizations are able to go into the toolbox and pick up the software they need.

We believe your time is valuable – it can save a life.

Thank you for reading.

Gabrielle Greiner

Humanitarian Toolbox Volunteer

Introduction

Are you interested in the work that goes into hackathons, or perhaps just curious to see the work that goes into Humanitarian Toolbox? This blog post is the beginning in a weekly series of topics relevant to Humanitarian Toolbox and the work that goes into it. Each week our team will be supplying a new entry on the different conflicts and challenges that come from our tech charity, and will give you a better look of how our events come together. 

Our first topic on hackathons aims to collect and share all that our team has learned so far from planning and executing a successful coding event. Every event we take what we’ve learned and use it to improve our scheduling and planning, with success. Each new event sees improvements in areas like building more software, constructing more features, and gaining more satisfaction from our volunteers.  Ultimately, we aim to improve as we learn more from each later event.

Early Planning

While we can move fast, ideally, we should start planning for an event 3 months prior to the dates. We can provide more leeway in those cases where the event is for a private company, and we will have more support and we will need to do less of the demand generation for volunteers.

All of these actions should be completed by 30 days before the event:

1. Estimate the attendance for the event. As the size of the event grows, we will need more features or applications for volunteers to work on. We want to maximize the amount of work that gets done, and that means minimizing the integration issues between feature or application teams.
2. Pick the app / project that will be the focus of the event. Depending on the expected attendance, we may work with more than one application. When we have multiple applications, we may want to consider a ‘primary’ and a ‘secondary’ focus. That depends on the size of the estimated attendees, and whether a member of the requesting organization can and will attend.
3. Secure the venue. This may be a checkbox item for those events that are hosted by a corporate partner, or are co-located with a conference.
4. Secure food and other logistics. Other logistics include internet access, building security protocols, lodging, travel.
5. Recruit volunteers. It’s important to remember that we need volunteers outside of developers. Our most successful events have had help with the logistics, scrum master, UX design, and most importantly, domain experts from the requesting organizations.
6. Build (or update) the project backlog. This will be done with the HTBox coordinators to manage expectations around customer rollout. There are several sub-tasks associated with this task to ensure that our developers are as productive as possible:
   1. Review the existing issues and update the priorities.
   2. Label existing issues. Pay special attention to the “Jump In” tag. Also, update based on “bug” or “feature” tags.
   3. Add any new requirements in cooperation with the requesting organization.
   4. Define a milestone for the event.
   5. Assign issues to that milestone. These can also be subdivided for P1, P2, and P3 goals. A successful event should be able to manage all the P1 issues even if the attendance drops. Stretch goals could be P2 and P3 issues for the milestone.
7. Define initial milestones. By 30 days before the event, our most engaged volunteers should be able to begin working on some of the features. This task also has a number of sub-tasks:
8. Clean up stale milestones. Often earlier events may have left some unfinished tasks in the existing milestones. These can confuse volunteers: Some volunteers assume they should work on these issues; others assume those issues should be dropped.
9. Define milestones for before and during the hackathon event. We should define weekly scrum milestones leading up to the event.  These should include tasks for onboarding volunteers (fork the repository, clone and build the code), and simple tasks to help developers become familiar with the project (scoped bug fixes).
10. Assign issues to the milestones. This is the first pass assignment and will likely be refined each scrum. Historically, we have had higher velocity during the event than before. However, there may be advantages to defining slightly aggressive milestones leading up to the event in order to encourage work.

March to Event

Starting one month before the live event, we want to start building momentum. The purpose of building this momentum is to make the in-person event a “sprint to the finish” rather than a launch event.

1. Assist with onboarding volunteers. This has generally meant teaching .NET developers about Git, GitHub, Github Desktop, and the Fork / Pull Request model. We have also had to help developers learn how to pull upstream changes into their local fork. Pro tip: Just explain the fork / pull model. Experience has said no on asks until they’ve made days of work on a local cloned copy only to find that they do not have commit privileges.
2. Stress the automated unit tests. It has really helped volunteers have confidence. They can make changes and run the existing unit tests to feel confident that they haven’t introduced regression bugs. I’d like to start from a position that we won’t merge a PR without new tests, but that may not be practical. The carrot is that we will help them create the tests.
3. Encourage feature teams to open their pull request early. We can comment on the code as they are working. It can help us ensure that we can avoid work going in the wrong direction. Tag that PR with the ‘WIP’ tag. (It stands for ‘Work in Progress’). That tells reviewers to comment, but not merge the PR.
4. Schedule online standups / scrum meetings. We should touch base with the volunteers each week during this period. We can answer questions, encourage more involvement, and create a sense of community. HT Box project leads will also attend these meetings. Have also experimented with recording the weekly meetings each week.
5. Refine milestones after each mini-sprint. During each online meeting (or offline afterward), the HTBox principals should update the board for the next sprint. This may include reprioritization (with the requesting organization), and pulling issues into or out of milestone sprints. 
6. Setup a schedule to review and merge pull requests. Volunteers are giving us their time, and the sooner we respond to their pull requests, the ‘stickier’ those volunteers become. We do all have busy schedules, but we need to ensure that we can respond to a pull request within 24 hours or so. (Note that for really large PRs the review may take longer. When that happens, the reviewer should add a comment that they’ve started the review.)
7. Setup slack channel. We’ve all used Slack with different organizations. We’ve all had positive experiences. We’ve found this is a good way to get volunteers communicating with each other.

Finally, right before the event, we need to define the final milestone and update the backlog with the issues we want to complete during the event.

At the Event

The event is the key momentum builder. We want all the participants to have a great time, and feel that their time was well spent. Here are the keys we’ve found so far:

1. Welcome and ice breaker. Get people talking as soon a possible when they arrive. We’ve never done a formal ice breaker activity, and we believe the developers would not respond well, but we need to do what we can to get teams to gel quickly.
2. Get permission to use pictures and names from volunteers. (See next section).
3. Introduce the ‘customer’. This has had two very good effects. First, developers know who can answer feature questions. Second, and more importantly, it puts a face on the problem and the work. It’s been energizing for the volunteers. When the customer is not there in person, schedule a skype call at the event start.
4. Take some B roll shots that can be used later in PR activities. Where applicable, get a short interview from the customer and some volunteers.
5. Continuously manage pull requests. The HTBox core team will be spending their time reviewing and merging pull requests. This activity will grow as time goes on. By the end of the event, we’ll be spending all our time merging and updating the core repository. As the pull requests start coming more quickly, we will need to make sure people re-base their pull requests so that merges are easier. (You did explain rebase when you introduced git, right?)
6. Recognize team members. We need to be the cheerleaders during the event. I suppose we could go too far with recognizing volunteers, but we haven’t seen any evidence of this yet.
7. Remember to mark issues as closed (If the PR doesn’t properly identify the issue or work item.) Communicate progress toward the milestone.
8. Consider recruiting a project leader. We can’t scale if we are the only possible project leads. One of the HTBox principals should be always involved, but when we can identify potential leaders, we can scale.

Post Event

After the event we want to capitalize on the event. We want to capitalize in two ways. First, we want to keep the volunteers engaged after the event. Second, we need to publicize what happened and grow awareness of what we did.

1. Review the issues list. The end of the event is the end of another sprint. We need to groom the board just like we do for other sprints.
2. Define new milestones. We want the existing volunteers to stay engaged. We need to define the next milestones.
3. Assign issues and tasks to milestones. This will give the volunteers guidance on what to work on as they stay engaged.
4. Write Blog post. This is the first public announcement. We need to publicize our success. Make sure to highlight many of the volunteers. (See previous section for permission). Add the photos or videos from the B roll. It needs to go live within 3 days of the event.
5. Press Outreach. After the blog post has been written, we should create the short press release and announce what we’ve done, in the markets where the event occurred, and the home market for the app’s test deployment. This can refer to the blog post for more details.
6. Encourage continued involvement. Immediately after the board is filled, we can continue to engage volunteers online and encourage more involvement. If we have identified a potential project lead, we can help engage that person to transition the day to day project leadership.
7. Work with requesting organization to encourage a (test) deployment. Assuming we’ve met our goal, we should push for a deployment that can create a second press story, and a chance to reach out to those volunteers that have helped to show how their work has been used.

Conclusion

While this is the sum of our knowledge from the hackathons that we have hosted so far, we strive with each hackathon to improve upon our guide.  We’ll revisit this document after each in-person event in order to share and expand on our body of knowledge and to use as a resource for the future. 

-Bill Wagner

Humanitarian Toolbox President

We updated our About section to include Our Vision for what Humanitarian Toolbox is and strives to be.  You can read it below:

Humanitarian Toolbox (HTBox) is a charity supporting disaster relief organizations with open source software and services.  We are developers, designers, testers, and industry professionals who want to contribute our unique skills in disaster relief aid. Whether it is through creating apps that map the spread of disease or maintaining software that helps to optimize the delivery of relief supplies, Humanitarian Toolbox has a goal of creating software and programs for relief organizations to have ready in times of need.

What makes HTBox unique is our focus on sustainability through the use of Open Source software. Developers want to give to charity using their skills – building software. But how do you build the right thing for the right folks? HTBox deals with the requirements gathering part of the process so that developers can concentrate on development. And it’s not only for developers – there are lots of skills needed to build software beyond development.

Open Source lifts barriers for contributors and users of software, making it an ideal choice volunteer developers looking to make a difference and the organizations they need to help.  Anybody can access the software built by HTBox, whether they want to contribute to it or just take it out for a spin. Our repositories are publicly available on GitHub at https://github.com/htbox

The projects that HTBox is primarily involved with are those benefiting disaster relief organizations.  Some projects are developed from scratch, working closely with the organizations' leaders to build something unique. HTBox gathers the requirements for these project from the relief organizations, break them down into work items in GitHub and then runs code-a-thons and test-a-thons to get the software written with the help of our volunteers as well as continues to engage volunteers online via our repositories.

Other projects are build from software dveloped within a humanitarian organization during a crisis.  When the crisis is over, often the people involved in creating it move on or the software languishes on the shelf. Instead of deteriorating, HTBox takes on these projects so they can be maintained and ready for future usage.

Because much of the custom software used in disaster relief becomes outdated or is not maintained after its initial use, HTBox focuses on sustainability, applying professional software processes on the various projects to keep them current and always improving. There are many contributors to HTBox projects that work on their own time weekly, picking up work items from the repository and contributing new code. As the software is always maintained and improving, organizations are able to leverage the solutions from HTBox whenever new disasters strike.

For volunteers who want to start contributing to HTBox, we recommend signing up so that we can keep you up to date with the latest. Also you can head over to GitHub and take a look at our projects. If there are any items that you think you want to do, go for it! You’ll find work items marked “Jump In”, which means we’re looking for someone to get developing on it.

Our volunteer base is not limited to developers! It takes a lot of different skills to build great software, and we're always on the lookout for all skillsets including but not limited to designers, testers, requirements and project leaders.  Together the impact of our solutions is greatest when together we have the greatest diversity of contributors and volunteers supporting them.

Lastly, if you're interested in donating to HTBox, we are a registered 501(c)3 charity and thankful for any donations you can make to support out mission to help those in need through open source software.

Humanitarian Toolbox wants to introduce the new project lead to the team, James Chambers. James is a consultant and Microsoft MVP who has joined on to lead the allReady project.  We have a quick introduction and interview with James here, to welcome him to the team.

What drew you to working with Humanitarian Toolbox?

JC: As software developers, it’s difficult to know how your skillset can be used to donate to worthy causes. Much of volunteer work is soft skills, such as organizing volunteers and managing resources for food banks or housing. Software developing is more difficult to donate. Humanitarian Toolbox enables developers to contribute their skillset to help charities around the world. Additionally, this can have a much broader impact by engaging with other developers on projects that can be used by multiple charitable decisions. It’s impactful way to use our abilities.

What work will you be doing with Humanitarian Toolbox?

JC: I will be working on assisting organizers for codathons and conferences, and helping them enable developers to find success in open source. Some of our most consistent and greatest contributors have come from those codathons, which make them an essential part of Humanitarian Toolbox. Some work has been varied, from hosting community stand-up, answering questions from developers, and connecting people who can answer questions.

Currently, my focus is working on allReady. AllReady is in transition as a real-world project that is being used by disaster preparedness campaigns in the United States. We have made huge milestones with allReady, and have had over 1000 pull requests from over 100 contributors. While we transition to maturity with allReady, we will make it a goal to make a meaningful difference in disaster preparedness.

What do you see in the future for Humanitarian Toolbox?

JC: In the future, I see developers who feel welcome to contribute at the skill level that they have, to serve organizations that they care about. I hope to help build a community with hundreds of developers with varied backgrounds, as an army of volunteers who can change the world through software.

Thank you James, we look forward to your work with Humanitarian Toolbox!

It’s been four years since our founding team began making plans for Humanitarian Toolbox. We’ve now reached an important growth milestone: We’re beyond ‘startup’ and entering the ‘second stage’ phase of our existence.

This is a major milestone for us as an organization. We created a business plan that reflected our experience as startup business founders: We bootstrapped the organization. We tested our core concepts. We found potential customers. We released a Minimum Viable Product for our first entry. All the while, we managed our finances carefully as we proved our core business model.

Now, it’s time to grow.

We’ve validated our core value proposition, our ability to create and deliver software, and our ability to work with our customer organizations. The next steps are to scale the organization, and prove that we will be effective maintaining and supporting all our applications.

The most important part of this plan is growing the organization. Our first board meeting of the year was our most significant. We celebrated what we have done. We have managed to survive those first difficult years for a new organization. We’ve proven that we can build software with volunteer developers in a sustainable and consistent fashion. We’ve proven that we can deliver software that our customers will use.

Then we created our goals and plans as an effective force for good. We’ll be adding project managers to our team. We’ll be launching development on new applications. We’ll be releasing updates to our first application. We’ll be growing the capital in the organization. We’ll be reaching out to more donors and partnering with our customers to secure grants to build and maintain more applications.

All of these actions mean we will expand our reach, help relief organizations do more, and yes, save lives. We could use your help. If you want to work on one of our projects, checkout our github page: http://github.com/htbox to find a project. If not, we value your contribution to help us grow and achieve our mission to save lives with software.

-Bill Wagner

Humanitarian Toolbox President

In our ThatConference 2015 recap in September, one of the marquis projects we talked about was CrisisCheckin, the “first responder’s phone book”, which was conceived based upon the challenge that disaster site coordinators and leaders often face in trying to manage and deploy resources.  CrisisCheckin is being developed with several scenarios in mind, but one of our primary use cases is was defined and tested as part of Operation Dragon Fire (ODF), which focuses on enabling data sharing during disasters and medical emergencies. 

Initially the use case was focused on people-related resources, but based upon early potential user feedback, it has been expanded to include physical resources such as blankets, equipment, and medical supplies as well.  Much of the work starting at ThatConference was been focused on integrating this additional feature set, conducting exercises with target users, and developing issues and milestones from the feedback we have received.  Over the last seven months, we have had continued development work from volunteers including during codeathons at CodeMash and Grace Hopper Open Source Day.  As part of our partnership with National Organizations Active in Disaster (NVOAD), we recently conducted an ODF virtual test with the NYC VOAD and an exercise with the CDC and San Mateo County Health System.

During the NYC VOAD virtual test in March, we got valuable feedback from participants that included representatives from TeamRubicon, The Salvation Army, and NY Disaster Interfaith Services.  One of the core feature requests that will be integrated for future milestones is to enable organization-based check-ins so that entities with their own structured resource deployment processes can register their capabilities and resources without complications that may come from each individual representative having to register.  Participants also provided input on design and approaches to visualizing the data, which is particularly challenging because of temporal, location-based, and dynamic nature of the data set, but it is a critical element achieving the goal of providing the response community with visibility in to the types and location of their peer resources.

Earlier this month, the CDC and San Mateo County Health System conducted “Silver Dragon X”, a full scale exercise to increase public health and safety readiness to respond to a health-related emergency.  The exercise tested fire departments and community volunteer response teams to conduct door-to-door inspections and deliver key information in the community within a designated period of time.  As part of the exercise, CrisisCheckin was tested at two field locations.  Users provided detailed feedback on usability, the mobile form entry experience, and priority data types.  Users also experienced a common disaster scenario challenge during the exercise: limited or no connectivity on mobile devices.  Enabling asynchronous data capture is a key capability for activities that involve field data capture and a central database.  Capability enhancements and bug reports are being integrated to the CrisisCheckin issues list for the next sprint.

To date, we have 76 contributors provide 839 commits and close out 114 issues.  Thanks you all who have contributed so far!  There are still plenty of opportunities to participate in this project.  If you are interested in helping us build a valuable and easy to use tool for disaster responders, check out the project overview and issues list on GitHub and sign-up to volunteer!

-Harmony Mabrey

Humanitarian Toolbox Core Team Member

Thank You!

allReady started as an aspirational vision to harness the energy and generosity of volunteers to “put disaster response out of work” by helping every community and family be prepared and ready to reduce and avoid the impact of disasters big and small.

That vision - coupled with support and contributions from the initial jumpstart with Microsoft’s Developer Division, to code-a-thons at multiple technology conferences and technology companies to individuals from around the world – has become a thriving, actively developed open source solution that’s nearing “going live” to support its first major preparedness campaign.

We want to thank everyone of you who has supported the project with code, time, expertise, support and visibility.  Without you allReady would still be a sketch on a whiteboard and not about to support of an important campaign to keep families safe in their homes.

allReady to “Go Live” in June

As announced during our recent Standup on March 19^th, we have identified our next major milestone for the allReady project to “Go Live” and help a community be prepared in a big way. The Northwest Region of the American Red Cross (we’ll call it the Seattle Region for reference below) will be holding a large preparedness event in their territory on Saturday, June 11. Per Regional Preparedness Manager, Allison DeDonato:

“This event will be a preparedness education expo in partnership with Puget Sound Energy (PSE), the primary energy provider in the Seattle area. The Red Cross, along with local Fire Departments and community partners, will come together to promote community preparedness and accept reservation requests for smoke alarm installations. There will be four event locations, each a Lowe’s (hardware) store. Three locations will be in King County, WA and one will be in Snohomish County, WA.

We have held two similar events in the past with PSE that each generated an attendance of approximately 5,000 people. This is what we are expecting for this event too. Our goal is to get a minimum of 25% of the attendees (1,250) signed up for a (free) smoke alarm installation.”

This is great opportunity to showcase a year’s worth of work by demonstrating how impactful a volunteer-built application can be. Equally meaningful, we’ll be bringing allReady back to where it all began as a gesture of thanks to Microsoft contributions and support.

allReady will not be expected to take appointment reservations. Instead, the Region will use another open source web application called getasmokealarm.org (GitHub Repository). getasmokealarm will be set-up at public-facing kiosks in all four stores. In addition, attendees can make requests by SMS by texting alarm to 844-811-0100 (feel free to try it while it’s in demo mode - the feature will go live on or about April 15).

So, what is expected of allReady?

1. allReady must be able to accept the request data generated by getasmokealarm via API.
2. allReady should feature the Seattle Region campaign and provide access to getasmokealarm from its home page and campaign pages.
3. allReady must be able to register volunteers who want to assist with installations. While the Seattle Region expects 1,250 installation requests, it is safe to assume that some attendees and, perhaps some Lowe’s employees, will want to volunteer to assist the campaign.
4. allReady must be able to construct and schedule installation itineraries and assign them to registered volunteers. Once the June 11 event ends, that’s when the real work begins: satisfying more than 1,000 requests. Typically, up to three smoke alarms are installed per home. That means the Region may need to install as many as 4,000 alarms in 6-8 weeks. The itinerary workflow is discussed in the Standup video and detailed in the whiteboard images.
5. allReady must also be able to create single-day, “rally” events in which a geographic area is selected for canvassing by 20-50 volunteer teams.
6. allReady must be able to provide a dashboard-like view of the campaign’s progress. Possible items for inclusion could be a quantitative display and map showing pending and satisfied requests, average installations per day and top volunteers.

During the Standup it was emphasized that UX design will become a priority as we move toward this milestone. Upon viewing the video of the Standup, Allison replied to Jim:

“The direction that the team is taking the project is pretty much the ideal situation for us. To be honest, I couldn’t think of anything that needed to be added to the conversation. I especially appreciated the focus on the “requesters” and volunteers. Since you are a Red Crosser, I am sure you understand that consumer and volunteer experiences are the most important aspects of any project we are working on.”

Finally, while Seattle will be the first beneficiary of our work, a number of states & regions of the Red Cross will be eager to get their hands on allReady including Idaho, Montana, North and South Dakota, Nebraska, Kansas Minnesota, Iowa, Missouri, Wisconsin, Illinois and Maine. That’s a lot of impact we can have together.

How You Can Help allReady Go Live

If you live in cold environs like us, June may seem a long way away. Yet, the Seattle event is just 2 months from now. Tony Surma and James Chambers are leading the ongoing posting & managing of tasks and contributions in our repository at GitHub in the “June Go Live” milestones.  There you can see the prioritization of the needed features and bug fixes to go live.  Besides directly contributing code, you can also help by reaching out to engage additional contributors to accelerate development and grow the focus on UX and testing.

Thank for all your continued good work.  We’re allReady excited for June!

- Jim McGowan & Tony Surma

Jim McGowan is the Director of Planning and Situational Awareness for the American Red Cross, North Central Division headquartered in Chicago.

​Tony Surma is co-founder of Humanitarian Toolbox.

See the latest on the allReady project and the Microsoft technologies it's built with in the "In the Code 2" video series which is part of Microsoft's Connect(); //2015 Conference this week. 

With the wrap-up of ThatConference 2015, Humanitarian Toolbox is pleased to announce that the collaboration codeathon between ThatConference and Humanitarian Toolbox has been an overwhelming success in the development of applications for the Red Cross and National Organizations Active in Disaster (NVOAD).

Over the weekend preceding ThatConference, 22 attendees volunteered their time to help build software for two Humanitarian Toolbox apps: AllReady and Crisis Check-in.

AllReady, an app that connects volunteers certified to install smoke detectors with homes that require smoke detector installation, was initially developed by Microsoft at the Visual Studio 2015 launch event. At ThatConference 2015, development on AllReady continued with the support of our Red Cross subject matter expert, Jim McGowan, who assisted in providing advice on the features that would be useful for app users.

Crisis Checkin, a “first responder’s phone book” was developed to make it easier for coordinators and leaders at disaster sites to manage and deploy people to more effectively provide relief to those affected. We’re currently enhancing the application to enable organizations to check in physical resources, like blankets, bucket trucks, potable water and so on. Crisis Checkin’s development at ThatConference 2015 was supported by our NVOAD representative, James McGowen, who also helped in refining application requirements and offered advice on useful features and options for their staff and volunteers.

The productivity of the ThatConference codeathon on the development of these apps can be seen from their results. After an intensive two day codeathon, our team of volunteers implement 11 features across both Crisis Checkin and AllReady. Along with this, there were over 100 commits to implement those features.  We had four accepted open pull requests that volunteers were carrying forward and will represent in new features shortly.

This is the third year that Humanitarian Toolbox has hosted this codeathon as a collaboration with ThatConference, and it’s always been a productive event. We would like to thank the principal organizers, Clark Sell along with Keith Burnell for their hard work in the organization and planning of this event. We would also like to thank all the volunteers and their hard work in turning this event into such a success.

Bill Wagner, Humanitarian Toolbox President, on the event:
“We’re thrilled with the support and generosity of the community of developers at ThatConference. They have consistently turned out to help us build software for Humanitarian Toolbox. More lives are saved because of their dedication, hard work, and professional skills.”

Thank you! 

Your HTBox Team

As part of the Visual Studio 2015 release event on July 20th, 2015 our newest project "allReady" was launched.

allReady is focused on increasing awareness, efficiency and impact of preparedness campaigns as they are delivered by humanitarian and disaster response organizations in local communities.  As preparedness and resiliency of a community increases, the potential for impactful disasters (both large and small) is greatly decreased.  The rule of thumb in the industry is that an hour or dollar spent before a disaster is worth 15-30 afterwards.

However preparedness activities, like ensuring working smoke detectors are in homes, are often not as visible or emotionally salient as saving children from a burning building - for example.  The goal of allReady - in part - is to grow awareness and engagement of communities and volunteers in preparedness campaigns to grow their impact and - aspirationally - "put disaster response out of business" through communities that are fully prepared and resilient to inevitable disasters.

To learn more about the need for allReady, the technologies, and how the app came together, please view our Project Page, the readme file on our GitHub repository and watch the In the Code video series.

The genesis for this application and the need it fulfills came from our team working with a number of members of community and humanitarian organizations including Jim McGowan of the American Red Cross who we would like to thank for supporting our efforts and the efforts of the teams at Microsoft as a subject matter expert, the provider of the aspiration to "put disaster response out of business" and a great collaborater in the early and often messy stages of starting a new application.

Lastly, we're thankful for Microsoft and their many engineering teams that came together to jumpstart the development of the project as part of the Visual Studio 2015 release event and then turn over the project to us so that it can be maintained and improved by the technical community at large and ultimately deployed in support of organizations delivering preparedness campaigns everywhere.  They have given the app a great start and strong delivery of a 'first sprint of many' that sets us and the community up to build the project going forward.

To stay up to date on the project or to sign up to contribute to allReady please fill out our quick sign up form.

Everyone at Humanitarian Toolbox (HTBox) is grateful to TechWell Conferences for their generous support. We've written before that they have helped test our code by holding a two-day Test-a-thon during their conferences for testing and quality assurance professionals.

In 2015, they will continue to support HTBox by holding Test-a-thons at both STAREAST in Orlando and STARWEST in Anaheim. The work performed at these events greatly increases the quality of the software we produce and ultimately will help the users of our software.

TechWell recently increased their support to HTBox by donating $50 of each conference registration they received during the month of December 2014—$2,000 in total. It's been a fantastic show of support from an organization that is already donating time and space during their learning events. Most importantly, this will aid in our 2015 disaster relief efforts.

We couldn't be happier for TechWell’s support and we hope to see you at one of their upcoming testing events this year.

We are back from ThatConference after hosting another successful codeathon. I'm always thrilled to see the participation we get from our friends in the upper midwest. A couple dozen developers gave up their entire weekend to write code for Humanitarian Toolbox on the Saturday and Sunday before ThatConference. 

I also must thank Falafel Software for their generous sponsorship that enabled us to host the event again. We greatly appreciate the support.

We worked on two different applications while there: Crisis Checkin and the Humanitarian Data Bus.

Crisis Checkin

We spent two days working on the mobile applications for Crisis Checkin, using the Xamarin toolkit.We had a UX designer at the event, so we made the most of the opportunity. At the end of the two days, we now have UI screens for all the major interactions on all the major mobile platforms. We have an API design for the server side code, and we're ready to start implementing the WebAPI services.

Humanitarian Data Bus

The Humanitarian Data Bus is a new project. The purpose of this application is to provide a common interchange mechanism for disaster relief organizations. There's a large amount of data that different organizations collect during recovery and rebuild. This application will enable those different organizations to share that data. It will mean that everyone involved has better information, and therefore makes better decisions during the recovery and rebuild operations. 

The overall architecture was created, and the initial shell of the application was coded. It's had a strong kick start, and we'll be getting that code on our github page soon. When it appears, we'll be ready for more work and more pull requests.

Again, I want to thank our hosts at ThatConference. They did a wonderful job to make our codeathon a success. They provided space, food, and got the word out to interested developers. We couldn't have done it without your support.

I'm very excited with the progress we've made in the crisis checkin application in the last year. A gropu of volunteers, donating their own time, built the first version of the web-based crisis checkin application.

We're ready to start having disaster organizations start working with the application and give us feedback. 

This is a great milestone for us. We've built our first app, and we're putting real bits in front of the people that respond to disaster events. All of you that have spent time on the application have helped us reach this important goal. There's more that we need to do. The beta is just the first time that disaster workers will use the app. We'll get feedback and address it. We'll be ready to launch more apps.We've had a lot of support from partners, disaster experts,developers, sponsor organizations, and other volunteers. Thank you!

If you want to pitch in, please join us.

You can read more in our news section.

Last weekend, we were in Salt Lake City for a Humanitarian Toolbox hackathon, sponsored by our great friends at Pluralsight. We spent our time working on the crisis checkin application. 

Salt Lake City has a great developer community. I was impressed with the turnout, the skills, and the progress we made.

Everyone had the app installed and running on their machine by mid-morning. The team helped us find and diagnose some challenges for new contributors. We've updated the getting started page on the project wiki, and it should be easier for new developers to join in.

After that, the group formed four different feature teams. We added quite a few features:

• We created a new Cluster Coordinator role. This is an important milestone for our partners in relief organizations.
• We created the ability for an administrator or cluster coordinator to email all volunteers that are present on a given day.
• We added a feature test project and framework. We also created some tests for the main scenarios.
• We made lots of progress on Xamarin based mobile apps for iOS and Android
• We made lots of progress on a WIndows phone mobile app.
• We made significant progress on upgrading to ASP.NET MVC version 5. This will make it much easier for us to integrate OAuth into the application, and enable volunteers to register using facebook or linked in.

Richard Campbell and I had a great time with everyone. It was great to spend some time developing with old friends that we've known from conferences over the years. It was equally great to meet new friends and spend time developing our application.

Most of all, I'm thrilled that the folks who attended have continued to work on the application after the event. I've been receiving pull requests from several of the attendees that wanted to finish features they were working on at the end of day.

Thanks again to Pluralsight for helping us organize the event, feeding all of us, and having some of their development team join us and drive our application forward.

A couple weeks ago, I was at Boston for Agile Development East, along with Microsoft people for a Visual Studio 2013 Launch Event. While there, we hosted another volunteer hackathon for the Humanitarian Toolbox.

I continue to be happy with the response we're getting.  Agile Development East is a testing and project management conference, although it's growing a more developer centered audience.  We had a great response from all those communities. Some project managers approached us about running projects for us. We had testers spend some time on the apps doing exploratory testing.  Our release is getting closer.  They found a few, but far fewer than at the earlier StarWest event.

We had a number of new developers approach us and talk to us about contributing. That's helping us get these first applications ready for use by humanitarian organizations. 

We also had a few community leaders from the Boston community approach us about running projects.  We've got enough of a backlog to do that. We've also learned enough that we're getting close to scaling Humanitarian Toolbox out to local community groups worldwide.  We've learned quite a bit about keeping ongoing development happening after our in person events. To be fair, we've made some mistakes, but we have learned from them.  We're getting more organized, and we're growing the skills to run these distributed projects that are moved forward in volunteer efforts.

I also recorded a new .NET Rocks show, talking about Humanitarian Toolbox, and the new support for Typescript in Visual Studio 2013.

Two weeks ago we had the opportunity to work with the dedicated Testing professionals at StarWest. The organizers invited us to bring some of our in-progress apps to a test-a-thon. Conference attendees gave their time to work through the scenarios we've completed and give us feedback.

This was our first chance to have a set of testing professionals do a thorough round of exploratory testing. Unlike all our testing to date that has been developer-authored unit tests and integration tests, the StarWest volunteers brought a different perspective, that of a testing professional.

They found many issues, they gave us several enhancement requests by approaching the app from a different perspective and suggested some new workflows. We'll take those new suggestions to our subject matter experts and see what they think. They also spent quite a bit of time doing negative testing, trying to exploit areas of the app to do things that shouldn't be allowed. Sometimes they were probing for authorization errors, sometimes probing for data exploits.

We feel good about where we are because the list is manageable given that this was the first time anyone had probed the app. Most of the items represent new features, not broken features, and there are only a small set of security issues. Overall, the test professionals made a great contribution to the application. They have given us a set of issues and a set of enhancement ideas that will make the final application much better. It's a strong and important contribution.

Many thanks to StarWest attendees, to the TechWell team for all of their support and to Microsoft for sponsoring the Humanitarian Toolbox at Star West. We should also mention the efforts by volunteers from Neusdesic who participted in the testathon for the duration. It was a worthwhile and valuable experience; we will definitely do this again.

We want to recognize and thank the attendees of the Grace Hopper Open Source Day who supported our project this last Saturday for the awe inspiring amount of focus and dedication they gave to building out mobile clients for our Crisis Checkin solution.

As David Washington summarizes in his blog post, the attendees built common data model specs, user scenario documents and starter apps for iOS, Android and Windows Phone.  3 apps in 6 hours!

The team far exceeded our expectations and we look forward to how these will be carried forward and in the future deployed for use by response organizations in the field.  You can see the results yourself (as well as contribute if you like) at the project repository on github - https://github.com/HTBox/crisischeckin.

Thanks again to those who were part of Grace Hopper Open Source day and to David Washington for representing the Humanitarian Toolbox at the event!

We at the Humanitarian Toolbox are thrilled to participate in the Grace Hopper Conference Open Source Hackathon Day.  We’ll have a team adding mobile support to the crisis checkin app. I’m really excited about this for several reasons. I can’t be at the event, but David Washington will be on site and acting as the project lead.  He’s done a fantastic job already by organizing the volunteers and making sure that everyone that attends will be able to contribute as soon as they arrive.

Based on early registrations, we’ll have up to 20 people or more participating.  We’re hoping to get a great kick start on the three main mobile platforms we want to support (iPhone, Android, Windows Phone).  This is great because it adds a lot of diversity to our application. In addition to the web, we’ll have native mobile support for our users.  I also like the symbolism of adding platform diversity for the crisis checkin app at the Grace Hopper Conference. The Grace Hopper conference celebrates women in computing, and we’ve had a low percentage of women joining our Humanitarian Toolbox hackathons so far. We want to have more participation, and the Grace Hopper conference is a great way to start.

I’m also thrilled that there’s at least 20 people signed up. That’s a great crowd, and a great group to add features to the crisis checkin app. I’d love to see everyone that helps this weekend continue to stay involved.

Have fun this weekend, and know that we appreciate everyone’s involvement.

-Bill Wagner

We're live with our new website today at http://www.htbox.org rebuilt on a new platform with a new visual design and support for mobile access.

Started at the hackathon at That Conference, the new website is built upon N2CMS, an ASP.Net MVC based content management system, that allows us to keep the content up to date and build new features with less development effort.  Some of the upcoming new features for the website including listings for projects, contributors and response organization requests as well as a full featured blog with rss feeds and syndication of blogs from project leads onto our website.

We've moved to the new address at www.htbox.org which we will use for all links and materials going forward as www.humanitariantoolbox.net was always a spelling challenge - even for those of us who typed it a lot!

Just like the projects in the toolbox, our website is being developed openly and the source can be found at http://github.com/htbox/htbox-website.  If you see something that isn't working or have ideas for new features please add an issue to the repository and we will prioritize it for development - or of course you could help us build it if you like as well!

Today we at NetHope, CrisisCommons and GeeksWithoutBounds are proud to announce, in partnership with Microsoft and DotNetRocks the launch of the Humanitarian Toolbox.

The Humanitarian Toolbox is an initiative intended to help bring the expertise and good will of the software development community to the humanitarian world. Ever since the devastating images of the East Asia Tsunami in 2004, developers around the world have helped humanitarian organizations address some of the most complex problems through the power of technology.

Over the past few years, this effort has culminated in the organization of hackathons and code camps that focus on working on problem statements defined by humanitarian organizations. Those of us from the humanitarian community have seen the potential these efforts hold, but sadly often these efforts have not been sustainable and little happens in-between the hackathon weekends.  One of the main reasons for this has been a lack of infrastructure to coordinate these efforts, which often are distributed around the world.

This is the reason we have teamed up with Microsoft, which has generously offered their Team Foundation Services as the infrastructure backbone for the Humanitarian Toolbox. By being able to break the problem statements into individual chunks of work and to clearly define each of them through storyboards, larger problems can now be addressed by this volunteer community of software developers. By having an infrastructure that also enables distributed software development also means that people can continue to work on problems even after they participate in a hackathon.

We are therefore reaching out to the broad software development community, looking for developers, designers, testers, database administrators, project managers, scrum masters and UX masters who want to give some of their time to share their expertise in software development to create solutions that will help save lives and reduce suffering. It is your chance to leave a footprint on this earth and a legacy of good.

We from the humanitarian community are very excited to bring some of our complex problems and get you to help us solve them leveraging your valuable software development expertise. Visit our website, sign up to be notified when new problems get defined, follow us on Twitter and help us bring the humanitarian community into the information age.