Mobile Apps under Duress: User Interface Guidelines

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!

  1. 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.
  2. Common tasks should be “shortcutable”… perhaps the user should be allowed to define their own shortcuts.
  3. 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.
  4. All actionable buttons/icons should be large… at least 64×64.
  5. 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.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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…

Android User Interface Code is Not Easily Reusable

I’m ideally looking for someone to correct or enlighten me here, so please do!

The basic premise I want to put forward is that user interface components and libraries developed for the Android platform are not as easily reusable as standard Java Swing-based UIs. As opposed to simply linking a JAR file as you would in a J2SE or J2ME application, an Android developer must deal with the following files:

  • An XML layout definition
  • An entry in the R.java resource file
  • The class definition(s)

It isn’t just the variety of files, but the process of integrating the third-party code into your application in a clean way that I am concerned with.

Am I missing something here? Is there an easy to just import a JAR into your lib, and load all of this up at once, possibly referencing a resource file and a separate set of layout XMLs within that JAR?

Maybe I need to go back and re-read the Building Custom Components section of the Android Developer Guide. Hmm.

Cruxy: New Look and Features Coming Soon!

I’ve been working on a update to Cruxy that provides both a new look and feel, as well as adds some new much needed features (like a shopping cart). One of my primary goals was to improve the ability for visitors to quickly browse and scan through the listings and artists to find something they might be interested in. By moving towards a thumbnail-style layout with rollover popup info boxes and multi-level menus for quickly select a specific genre or media type, I think we’ve made progress toward that goal.

If you have any other ideas or approaches that you think that Cruxy interface could benefit from let me know!

view the full screenshot set

Top half of artist page

album.jpg

Droid Draw Android User Interface Builder

Droid Draw (available at www.droiddraw.org) is a great tool for rapid prototyping of Google Android user interfaces. While the XML schema that underlies the Android resource description is not *that* complicated, it is good to see that fairly robust drag and drop UI tools are coming along so well.

The Droid Draw site also offers a number of handy reference pages. Keep up the great work folks!