• Intro
• Downloads
• Community
• Development
• News
• TALK

Maemo User Interface Issues (Presentation)

Latest revision as of 15:25, 3 March 2010

This presentation will be given at the Maemo Summit 2008 by Tim Samoff

"An Unofficial Guide to Creating a Most Excellent maemo User Interface" is about a year old. It was written in an attempt to assemble some useful Maemo-related UI philosophies and techniques for Maemo developers to consider when coding and/or porting software to the Maemo platform. Initially, there was a little help and guidance from the Nokia Maemo team, but little input from the greater Maemo Community (aside from blog comments and miscellaneous emails). I'd like to open the document up for community scrutiny, critique, and editing -- with the possibility of adding it to the official maemo.org wiki compendium.

[edit] Outline of the Program

15-20 minutes on slides and explanation

• Title
• About Me
• About Guide
  • Inception
  • Participation
  • Hopes & Dreams
    • Wiki
• Why?
  • Developers & End-Users
  • Gnome Human Interface Guidelines
• Utopian User Cycle
• The "Bridge" Metaphor
• Examples
  • Facebook Updater
    • Process
    • Standards
    • Consistency
• Conclusion
  • Community-driven
• Questions/Comments

5-10 minutes Q&A & Discussion.

[edit] Slides

• View the presentation.

[edit] Commentary

[edit] From Eric Warnke / brontide

I don't know if I will be able to attend this session, but wanted to give my feedback on the current state of the Maemo UI standard by Tim. I agree that we need to improve the quality of the baseline Maemo application that is out there, but I think we are shooting too short with many of the examples given. Modal dialogs are something that all applications should attempt to minimize at all costs. I'm not saying that dangerous actions should be taken without some sort of mitigation, but the UI should be optimized for speed and obviousness.

In the example of closing the facebook app there are a few other possibilities that might be better in a mobile applications and still fulfill the rule of last surprise for the user.

1. Ok: Confirmation prompt to close the app. This fulfills the rule of least surprise, but forces the user to confirm a rather trivial action.
2. Better: Confirmation prompt if the user has a facebook request pending, or un-sent status text. This allows the application to close is there is no danger in loss
3. Good: Close never prompts, but unsaved text is automatically saved and restored on next launch. Transactions with facebook run until completion even if the UI is closed.
4. Best: Good + uses osso tools to save the state automatically so that hildon can close this application when it's in the background and the system needs memory; hildon will relaunch it when needed. The user need never know the application was closed.

So I say that we need the UI to get out of the users way. Applications should be quick to launch and quick to close, state should be updated at regular and sane intervals so that accidental, deliberate, or powerloss does not result in loss of data to the user. Dialog boxes demand attention and should be used sparingly as it prevents other things from occurring. I would personally rather see an action as undoable rather than prompting to confirm.

My other pet peeve is not taking advantage of the, poorly documented, hildon-input-mode in order to hint to the system what kind of data to expect. This allows, for example, turning off auto-capitalize, turning on the numbers only, activating "phone number" mode so that the OSK has keys grayed out. I will post a python example soon so that other developers need not suffer as I did to figure this out.

[edit] Q&A

[edit] Your Question(s) Here

@Developers and End-Users:

• Who are the Maemo target users?
• Is there existing user research about the Maemo end users?

Thanks, Ellen

[edit] External Links

• "An Unofficial Guide to Creating a Most Excellent maemo User Interface"
• Gnome Human Interface Guidlines