[OpenRelief Developer] [UX] An overview of the User Experience challenges facing OpenRelief

[Shane Coughlan]

Dear Adele, all

This email contains an overview of the User Experience (UX) challenges in OpenRelief. It is intended to outline where we stand today, but is not prescribing where we can go next. That's where you come in. :)

This is a big email.  It's not intended to overwhelm, but rather to summarize everything necessary to start UX discussions and design. Please regard this as a launch platform for that. This email is intended for the outreach list, but I'm cross-posting this with developer at openrelief.org to ensure everyone is on the same page.

== Overview ==

OpenRelief solutions consist of three parts; modules, transport systems and analysis and control systems. These can be combined to address challenges. These solutions can be understood in two ways. One is from the technical perspective and the fact that everyone can access them down - as much as possible - to the design level.  The other is that they are intended to solve real problems for real people.  Naturally it is the latter area where we need to focus when thinking about UX.

Adele, a UX expert who kindly offered to help, sent me some framing questions to get the conversation started:
(Q) Will the interface be in Japanese or will it be in different languages? 
(A) We need to support multiple languages with every solution. To launch in June we just need English, but ideally we should have English and Japanese. Then we need to make it easy for new languages to be added.
(Q) Do you plan on doing local user testing with the application?
(A) Yes. We need to prototype solutions from modules, transport systems and controls systems (either individually or in combination) and then test them. 
(Q)  What kind of displays will be used? mobile phone displays and different operating systems?
(A) Most of the initial display tasks will be computer-based (e.g. UAV mission planning and subsequent data analysis through disaster management software). We are working off pre-existing platforms to start with (see the notes below on transport systems and analysis and control systems). The former are .Net based (native Windows, can run in Linux). The latter target platform is a web application. Moving forward we need to be platform agnostic and we need to design ways to interact with OpenRelief solutions through mobile devices too.

From a user perspective, the user workflow will be something like the following:
 - Coming to OpenRelief seeking solutions (we need a really simple way to guide people to solutions on the website)
 - Getting solutions delivered and starting deployment - modules, transport systems and hooking into disaster management (a simple set-up guide)
 - Getting modules into transport systems and getting them active in the field (right now that means UAV mission control and - when possible - mission simulation)
 - Monitoring everything (a simple way to get the analysis and control systems active)

To put this in context of the actual tools let's address each part of OpenRelief in turn.

== Modules ==

Our framing principles are everything should be easy to build, use, maintain and customize, and that everything should solve problems with the greatest quality and reliability possible. Good tools cause minimal overhead when helping people overcome challenges. Keeping with that, the modules in OpenRelief will be pretty simple. Each one is meant to solve one problem well and with the minimum of fuss. Our goal is to have an earthquake detector, a submersion detector, a radiation detector, a weather station and a radio transmitter ready for a formal launch of this project in June, and they will be accompanied by two off-the-shelf drones which can be used as test platforms and the basis of our own transportation platforms going forwards. For more about the UAV/drones, please see the note on transportation systems.

We envision the modules being houses in a box that lets you know when it is switched on, and the rest is just outputted data to recording devices or computers. These computers will translate that data into something that can be used for disaster management. For more about that, please see the note on analysis and control systems. The basic modules should involve no software UX but we will probably need to develop a really simple diagnostic tool to double-check how modules are performing and to isolate faults. It will need to be extremely easy to use in the field so that people can test for dead modules, it will need to be multi-lingual, and it will need to be multi-platform.

== Transport systems ==

Transportation systems provide a way to observe and interact with disaster areas. Over time they will include air, sea and land transportation, though the system currently being prepared is a lightweight electronic Unmanned Aeronautical Vehicle (UAV). This drone will initially be based on off-the-shelf technology, and the first two airframes are currently on their way to the UK for assembly and testing. The idea of using off-the-shelf technology to get the first transportation system in the air as quickly as possible includes using a pre-existing UAV control software for autopilots. It is called Mission Planner and can be previewed here:
http://code.google.com/p/ardupilot-mega/wiki/Mission
The usability of this software has not been tested. Having an initial overview of UX impressions would be great.  Just in case someone is interested, the source code is here: https://code.google.com/p/ardupilot-mega/source/browse/

Once we have gathered data from the two test drones we can start to improve the interface, internationalization and integration with the rest of the OpenRelief technology. For example, one thing we need to integrate is the ability to simulate missions quickly.  That means looking at the approach found here (http://code.google.com/p/ardupilot-mega/wiki/FlightGear) and heading towards a way that the mission simulations and the actual mission planning is one integrated task. This is not a priority for the June launch, but it is a feature that would be very useful to have once the basic technology is deployed.

== Analysis and control systems ==

During our initial phase, the modules and the transport systems for OpenRelief will mainly be useful for returning location-based data (e.g. seismic reports, radiation readings, weather situation). This data will need to be inputted into a GIS system used in disaster management. For our purposes the best platform to target is the Sahana Eden disaster management system. This is used by the Red Cross and other agencies to do everything from mapping through to logistics. Hooking in here will mean that people can integrate OpenRelief solutions into existing workflow as quickly as possible.

It looks like the default Sahana Eden import is based on CSV (see http://en.flossmanuals.net/sahana-eden/importing-data/). However, the Eden GIS system is based on OpenLayers and GeoExt (see http://en.flossmanuals.net/sahana-eden/mapping-gis/), and the former means that it accepts data based on OGC standards like WMS & WFS or feeds in KML or GeoRSS. The system also supports importing spreadsheets and allowing Web Services via a RESTful API (see http://en.flossmanuals.net/sahana-eden/web-sevices/). All this means that we can develop a plug-in/small application that accepts the data from OpenRelief solutions and pours it onto the Eden map, hopefully in real-time.

The underlying approach to get this stuff accomplished is detailed on their site (see http://eden.sahanafoundation.org/wiki/DeveloperGuidelinesGIS), but our approach to delivering OpenRelief services is undetermined. For example, should we have a setup program that configures an Eden installation to accept OpenRelief data?  Should we have a stand-alone application that can be switched on and off?  UX input is needed to help frame what should be created in the context of the existing platform.

== Summary ==

Right now the most pressing UX question is how we structure initial arrival on the site and finding solutions. People get confused by what we mean with modules, transport systems and control systems. What we are doing is building a modular series of tools that work alone or in combination to create solutions. Helping people create their solution is our first challenge.

We also need to review the off-the-shelf technology we are using like Mission Planner to decide if it is useful for production deployment, or if it is better suited to prototyping, and we need something simpler, more international and more inherently cross-platform moving forward.

Finally, we need to hook up the OpenRelief solutions with disaster management tools. Right now we are targeting one platform, the one most likely to be used in the event of a tsunami or similar. We need to work out how we interface the data from OpenRelief modules with that platform.  The technical side is not a big deal, but the user side is. What's the simplest way for us to allow people to hook their disaster management into our solutions?  It would be excellent to have some ideas for answering this in place for June.

Regards

Shane