By ultan o'broin on Oct 05, 2011
Here are design considerations to optimize the mobile enterprise applications user assistance. These considerations are based on Oracle Applications User Experience research into mobile user assistance, ethnography, and context of use. Understanding mobile app users' profiles and the mobile context--and how it differs from the desktop--is critical to delivering a successful overall user experience.
1. Forget the notion of porting over documentation manuals in any form to mobile devices. Users on the move do not have time to read such content. How the mobile app communicates with users must reflect a world of changing location, frequent disruption, and the need to complete tasks rapidly or to maybe revisit them later when time, social circumstance, or information availability changes. Brent White's blog entry on mobile design principles will help you focus on how design must reflect the mobile user context.
2. Pay close attention to the language in the app UI. Language drives user action. If a term requires explanation to users then it's probably the wrong term. Explaining terminology slows down users and wastes valuable real estate in the UI.
Generally, web-based mobile apps terminology can follow the desktop version, while native apps can use the familiar terms provided by their platform. Test any new terminology along with interactions before you release the app.
The style of language (formal, casual, and so on) must reflect the user profile. Check out these excellent mobile international style guides from Microsoft for examples.
3. Avoid writing procedural user help about the task flow. If such usability isn't intuitive, then the app usability has failed. A quick first-run only orientation to new feature functionality is all that's needed in terms on onboard assistance for mobile apps, along with some basic instruction around areas that might not be often used, such as settings or configuration.
Full screen overlays or component popups can act as a modal barrier to task completion, slowing down users working under pressure. Use inline information instead.
4. Eliminate errors by affirmations in advance, using placeholder text showing examples of data format, usage intention and so on (check out the HTML5 placeholder types for examples, and native device apps can offer similar features). Allowing users to quickly enter numeric, date or other data in the format they want and then seamlessly converting it to the accepted storage format is also the way to go. See the Oracle Application Development Framework (ADF) Trinidad converter demos for the idea.
5. Allow users to complete fields on the screen in any order they like, and then perform a validation on final action rather than validating each field one by one and slowing down task completion.
Validate data input on the device before submission to the server, saving on round tripping time from the mobile device if you can. Use those validation or conversion features to speed up the entire task completion process, reflecting a mental model of users knowing their data entry is valid on the mobile device rather than hoping it was on the server.
6. Inline placement for messages for task-completion errors and confirmation messages is best as this approach doesn't block access to the page or disrupt the user too much if they want to complete another task from the same page. Dialog boxes are still best for those critical issues, however (at this point, the user action has already stopped).
7. Show the message clearly with distinct visual indicators and near the point of the error (see the ADF Trinidad demo on messages for an example). Different types of messages (error, warnings, or confirmations, for example) require different visual indicators and styling so that users can learn the intent of each type quickly and also rely on such visual indicators elsewhere without the benefit of reading the message text too.
8. Centralized lists of messages in a notifications center are the way to go for sure, but allow users to control which ones they want to see and when. Android does a great job on notifications, but Apple’s iOS5 looks set to create a new standard in mobile notifications and their personalization (the following screens are from pre-released software).
9. Choice of content for messages may vary depending on what application functionality is available or regional user preference even. For example, our research into expense report submission confirmation messages, revealed that US and UK-based mobile app users wanted to see the word successful in the message (indicating the task was completed as intended), though UK-based users were less adamant about the word. UK users preferred to have more details of transaction objects in the message content (for example, the expense report and amount), whereas US users preferred a simpler message without all the details. So, how do you resolve such differences?
A difficult question to answer without access to the entire task flow or application features, but in this case, let context win out over consistency. Include the word successful, as users want to be assured that their task is done. Although only one word, it shapes their perception of what has happened. Are users on the move likely to remember all the expense details anyway after they dismiss the message? Probably not. So, allow users to refer back to a notifications center that reminds shows that the action was successful and all relevant transaction details as well as further activity around the transaction (approval, deposit of reimbursement, and so on).
10. What about audio, sound, or vibrate options as messaging for mobile app activity? These options can be offered as a personalization feature if your development effort can afford it, but don't expect a whole ton of usage uptake right now. Auditory messages can be ill timed for sure depending on the context. Who wants to receive a message like this during a business meeting?
Informational messages can always be recalled from a centralized notifications list, as they frequently don't demand immediate response. This is superior from showing them suddenly on the page during transaction completion, disrupting the current activity anyway.
As for SMS (text messaging) used for application confirmations, sure, such a personalization option can be considered, but as a lower priority, as there may be security issues at stake in an enterprise environment. Functionality that enables users to see confirmations from a centralized notifications center and to take any follow up actions arising from that location (for example, knowing when an expense report is approved) allows for more efficient working.
You may have other considerations. If so, then find the comments. To explore this area further, don’t forget to check out Marta Rauch's (@martarauch) presentation at LavaCon 2011 on mobile user assistance usability guidelines.