One of my students at ITP is working on a mobile application for the Android platform that will be used under duress and in generally stressful conditions. These situations might include documenting children at a refugee camp, capturing medical information in a remote clinic, or identifying victims after a national disaster.
I’d like to use this post to build up a list of useful guidelines for building mobile application user interfaces that can be effectively used during these situations. More specifically, with the capabilities of modern smartphones (large screen, capacitive/multi-touch touch, accelerometer, compass, camera and so on), what more can an application provide than just dumb entry forms and checkboxes.
Here’s my start… please add your own in the comments!
- Applications must be INSTANTLY responsive. Not only is there no time to lose in these situations, but the patience of the user will be at an all time low. Any data lookup should be cached, paged or otherwise optimized.
- Common tasks should be “shortcutable”… perhaps the user should be allowed to define their own shortcuts.
- Any queries or searches should be auto-magically remembered and available via dropdown so that the same text doesn’t have to be remembered multiple times.
- All actionable buttons/icons should be large… at least 64×64.
- Lists of selectable, pre-populated options should always be used instead of freeform text entry to improve accuracy of data entry. If freeform is required, suggestions for existing matches of data should be provided.
- Any network transmission of data or remote access should be done in the background without interrupting the work at hand. Again, remember the user should be expected to have ZERO patience.
- All color palettes should be HIGH contrast – the lighting situations may not be good AND the device screen brightness will most likely be set to very low in order to maintain the best battery life
- If the camera is expected to be used for image capture, remember that a 3 or 5 megapixel image can be quite large. Determine the need for resolution quality of the documented image and downsize that at capture time. Otherwise, loading, saving, and transmitting the captured photo could take up a lot of processor time and battery life.
- Make sure your UI works in both portrait and landscape modes… you just want the app to work no matter which orientation the device is being held.
- GPS – if you can use geolocation data to make the life of the user easier by prepopulating data or automatically geotagging items, then do it! However, they may need to turn off GPS in order to save battery life, so make sure to gracefully degrade.
- Any persisted data should be stored on the external SDCard storage so that it can easily be removed, backed up, read on a PC, etc… the phone might die, but you should be able to pop out the card and put it into a SDCard reader for any device to read. This may mean that instead of using the SQLite database on the device, you instead use an XML, JSON or CSV format on the card.
- If you need to record audio notes, a bluetooth or wired headset should be used. The built-in mics aren’t very good on most devices out today.
- Swiping, multi-touch or other gestures can be very natural and intuitive UI control mechanisms if used properly. If your applications lends itself to these, make sure you work closely with users to make sure they work… they should be almost natural for a user to do (like swiping photos left and right in a photo gallery) as opposed to some complex secret handshake.
Any more? Please add your ideas in the comments below…
Found this post about the Ushahidi iphone app and some critique and pointers for developing apps for this purpose – http://blog.ushahidi.com/index.php/2008/09/16/t…
Found this post about the Ushahidi iphone app and some critique and pointers for developing apps for this purpose – http://blog.ushahidi.com/index.php/2008/09/16/t…
nathan,
have you considered building on top of something like open data kit? it has a lot of the functionality you describe already. see videos at http://code.google.com/p/open-data-kit/
I am not building the app myself, but I will make sure my student as considered using ODK.
Otherwise, I was hoping to build a list of general design goals here, as opposed to specific tools, but thanks anyhow!.
nathan,
have you considered building on top of something like open data kit? it has a lot of the functionality you describe already. see videos at http://code.google.com/p/open-data-kit/
I am not building the app myself, but I will make sure my student as considered using ODK.
Otherwise, I was hoping to build a list of general design goals here, as opposed to specific tools, but thanks anyhow!.
Usability, usability, usability – I agree, the interface and hardware must be designed with the ZERO patience threshold in mind. Also, do your risk mitigation assessment for power management. A mobile device/application, however well designs loses all functionality when the device power fails. Add a dynamo or solar charger, or better yet, one of those “mother-of-all-lithium-ion-batteries” from Socket Communications to keep you going for three to five days (recharge on the way back to the guesthouse in the evening). This is what we did for Save the Children's mission in El Geneina in West Darfur early this year.
Provide visual and auditory cues and feedback. Cues give users insight into what can be done. Feedback tells users what they've done. Under conditions of high stress, the interface should mitigate how much information the user has to process while using the system.
Usability, usability, usability – I agree, the interface and hardware must be designed with the ZERO patience threshold in mind. Also, do your risk mitigation assessment for power management. A mobile device/application, however well designs loses all functionality when the device power fails. Add a dynamo or solar charger, or better yet, one of those “mother-of-all-lithium-ion-batteries” from Socket Communications to keep you going for three to five days (recharge on the way back to the guesthouse in the evening). This is what we did for Save the Children's mission in El Geneina in West Darfur early this year.
Provide visual and auditory cues and feedback. Cues give users insight into what can be done. Feedback tells users what they've done. Under conditions of high stress, the interface should mitigate how much information the user has to process while using the system.
Great point – active, clear, instant feedback of success or failure is also critical. If you have one chance to get the data in correctly, you need to know its good to go.
Here is some potenital ideas on types of feedback for confirmations:
– Loud beep tone sequences: upward sequence for success, downward sequence for failure/error
– Change entire screen background color: White for input, Green for success, Red for failure
– On Android, proper use of status bar notifications is essentially… subtle notifications that don't interrupt the current workflow, while still letting you know there is new information to review when you have a minute.
One of my mantras is “electricity is the true enemy” though actually it should be “batteries” perhaps. Great point and glad to see there are some good options for extended power that can work in the field.
I also have to reiterate from my list that all data should be persisted on removable media, like SD Cards, instead of on the device itself. That way you can always quickly switch devices, load the data on a PC, etc…. and even, if necessary, you can protect sensitive information by swallowing it! 🙂
Hi,
This is a good list. I've been thinking about an emergency preparedness application so some other ideas come to mind that may apply depending upon the application…
Allow hands/eyes free audio interaction when the user may be following instructions from the device, such as when being directed to render first aid.
The application can be used to deliver timed reminders
Ideally the app adapts to a wide variety of hardware capabilities such as screen size, presence of BT, data plan etc.
The app should remain useful in an offline situation. The cell network may be temporarily down. The app should store and forward, opportunistically. All functions should be considered and designed in their online and offline modes.
The app should anticipate required actions that will occur in duress. For example, when installed, it should remind the user to input key ICE (In case of emergency) information until it is done.
Good luck in this!
Great point – active, clear, instant feedback of success or failure is also critical. If you have one chance to get the data in correctly, you need to know its good to go.
Here is some potenital ideas on types of feedback for confirmations:
– Loud beep tone sequences: upward sequence for success, downward sequence for failure/error
– Change entire screen background color: White for input, Green for success, Red for failure
– On Android, proper use of status bar notifications is essentially… subtle notifications that don't interrupt the current workflow, while still letting you know there is new information to review when you have a minute.
One of my mantras is “electricity is the true enemy” though actually it should be “batteries” perhaps. Great point and glad to see there are some good options for extended power that can work in the field.
I also have to reiterate from my list that all data should be persisted on removable media, like SD Cards, instead of on the device itself. That way you can always quickly switch devices, load the data on a PC, etc…. and even, if necessary, you can protect sensitive information by swallowing it! 🙂
Hi,
This is a good list. I've been thinking about an emergency preparedness application so some other ideas come to mind that may apply depending upon the application…
Allow hands/eyes free audio interaction when the user may be following instructions from the device, such as when being directed to render first aid.
The application can be used to deliver timed reminders
Ideally the app adapts to a wide variety of hardware capabilities such as screen size, presence of BT, data plan etc.
The app should remain useful in an offline situation. The cell network may be temporarily down. The app should store and forward, opportunistically. All functions should be considered and designed in their online and offline modes.
The app should anticipate required actions that will occur in duress. For example, when installed, it should remind the user to input key ICE (In case of emergency) information until it is done.
Good luck in this!
1. Privacy and anonymity: Unless specifically otherwise, have you taken adequate steps to safeguard the privacy of the individuals you are collecting data about? Are you sending data over the operator's mobile network in an encrypted format? Where will the data ultimately go to and be held?
2. Steganography: You might not want to be seen to be doing any kind of data collection. Can the application and data be hidden? Can the mobile device you're using just look like your personal phone?
3. Separate data from app: I agree that keeping data stored/backed up on something like and SD card is very important but makes the encryption element potentially more important. Consider keeping the configured application & state stored on the SD card too – i.e. you can rapidly swap to a “warm spare” device is the first fails or is compromised.
4. Simulation / Training / Documentation: recognise that if the application is going to be used by agencies in a relief situation, they are going to want to field trial the heck out of it, conduct training on it and provide documentation. Put effort into supporting this.
this kind of interface would be excellent for schools, use of mobile tools by students. under duress is probably an apt description
1. Privacy and anonymity: Unless specifically otherwise, have you taken adequate steps to safeguard the privacy of the individuals you are collecting data about? Are you sending data over the operator's mobile network in an encrypted format? Where will the data ultimately go to and be held?
2. Steganography: You might not want to be seen to be doing any kind of data collection. Can the application and data be hidden? Can the mobile device you're using just look like your personal phone?
3. Separate data from app: I agree that keeping data stored/backed up on something like and SD card is very important but makes the encryption element potentially more important. Consider keeping the configured application & state stored on the SD card too – i.e. you can rapidly swap to a “warm spare” device is the first fails or is compromised.
4. Simulation / Training / Documentation: recognise that if the application is going to be used by agencies in a relief situation, they are going to want to field trial the heck out of it, conduct training on it and provide documentation. Put effort into supporting this.
this kind of interface would be excellent for schools, use of mobile tools by students. under duress is probably an apt description
Great. This list and notes are getting quite good.
One that may be missing and can be of relevance is having a night mode. Screens may be to bright for its night use, and sometimes this may compromise security/safety. Normally it will switch the background color to black and use red/blue/green for text.
In terms of UI, and this may be exclusively out of personal experience, persistent tabbed browsing can provide some benefits. Another path could be sliding panels to send loading apps to the background.
Anyway, will post other ideas if they come.
Great. This list and notes are getting quite good.
One that may be missing and can be of relevance is having a night mode. Screens may be to bright for its night use, and sometimes this may compromise security/safety. Normally it will switch the background color to black and use red/blue/green for text.
In terms of UI, and this may be exclusively out of personal experience, persistent tabbed browsing can provide some benefits. Another path could be sliding panels to send loading apps to the background.
Anyway, will post other ideas if they come.