Application UI Design Recommendations
From Openmoko
NOTE: These design recommendations are outdated and not relevant since 2007.2 got out!
This section will try to maintain UI interface design recommendations and guidelines. Application work flow, usability will be defined here.
There are a few guidelines at the top of the Applications page. Those should probably be moved here since that page seems to be more like a roadmap than technical guidelines.
Contents |
Application menus
Applications should have a dropdown menu displaying the name of the application and containing at the very least the option "Close". (Not "Quit"). The application name here needs to match the name that is in the main system dropdown (upper left corner). Try to avoid the way the Calendar is known as Dates in the main menu. This leads to confusion.
It's a good idea to populate the dropdown with the new/edit/delete options, with separators to keep the menu clean. The best example of this is the Contacts application which has a menu with:
New Contact // Import / Export // Add Group / Edit Contact / Delete Contact // Close
The dropdown on the right should be used for filtering data. It may be application-specific (eg by week/month in the Calendar app)
Application panels
The convention for data-intensive applications is to split the display between a list in the top half of the screen and details about individual entries in the bottom half. The two halves are a fixed size, so when the keyboard popup appears, the details section is mostly obscured. This is actually a serious problem with this layout convention. The details area has to be scrolled one line at a time to enter text.
A horizontal bar between these two panels typically also contains the new/edit/delete functions but is much more amenable to finger taps. There is currently no convention for closing an application using an icon that can be easily tapped with a finger.
If you implement searching, the search icon is on the left side of this bar.
- This convention which has so far been followed is inappropriate for most applications. The Neo has almost the smallest screen on any PDA. Every user interaction has to have a value. The user did not click on "todo list" so he could squint to see the first 3 items in an almost unusable form at the bottom of the screen. He interacted with his PDA, and the PDA should respond by providing him full and convenient access to his information in its own screen. The screen on the Neo can show only one thing well at a time.
Persistence guidelines
Do not require users to find the equivalent of file->save to make data persistent.
As soon as changes are made in the details panel, you should reflect those changes in the overview panel and in the persistent store. For example, renaming a contact in the details panel should make the change visible in the list panel if the record is visible there and should be saved immediately too.
Unfortunately this approach might not work well with an 'undo' strategy.
For some data edits, a new window can present the data of interest in the full screen. This probably works better with the keyboard and it also works well with conventional 'cancel' and 'save' buttons. This is how new events are edited in the Calendar.
Touch Gestures
The only gesture widget seems to be the corner-scrolling thing we get in the tasks app and one or two others. "Spinning" this widget clockwise scrolls the active window backwards.
There should be rudimentary gestures in scrollable lists (integrated into the GtkList widget, or a MokoUI wrapper?). In essence, a 4-way special pie menu should appear when a mouse-down event is encountered inside a scroll list. Releasing in (or near) the center generates a regular left mouse button click. Dragging up/down should scroll the list (with acceleration), and releasing to the right or left should generate middle/right mouse button events. There is no use for "drag-and-drop" in most lists, so this shouldn't cost us anything, and opens us up for having a very usable cellphone contacts list.
It would be useful to have global gestures so we don't have to have some huge persistent buttons taking up a big part of the screen. I suggest making it like a book: a swoosh left to right across the top of the screen brings up the home app, like flipping to the front of the book. A swoosh across the top from right to left switches to the next application, like turning to the next page. (Gratuitous animation can wait until we have a better gpu :)
Buttons
Every button must be as large as possible to allow them to be operated with fingers.
Any confirmation buttons such as Ok and Cancel are best located in the lower half of the sceen. This allows for the buttons to be pressed easily when using the phone with only one hand.
Always use a consistent order throughout your application. In most computer systems the left button is typically a positive response allowing an operation to proceed, the right button is typically a negative response and halts any operation.
Where the button ordering differ, make the highlighted button the non-destructive option, eg. don't save, don't quit.
Colors
Application colors should match the current theme. The sandy hues with brushed metal look seems to be the only theme currently.
Avoid indicating information to the user only by alternating between colors that appear to be similar to those with colorblindness, such as red to green. There are many ways to convey information that are usable by everyone, such as choosing an icon that changes instead.
Tap behavior
Definitions These definitions apply to both finger or stylus mode application interactions.
tap: a single short tap on the screen. Equivalent to Onmousedown & onmouseup in less than 1 second. Taps are to be used as the primary function call for applications. Equivalent to a normal (left button) mouse click in desktop OS's.
tap & hold: A long single tap. Equivalent to Onmousedown for > 1 second. This calls any secondary functions available on the tapped screen element. This is equivalent to the right mouse click in desktop OS's.
tap & drag: A single tap & movement of the finger/stylus. Equivalent to Onmousedown & Onmousemove < 1 second.
Double tap & triple tap: Two or three short single taps in < 1 second. Equivalent to a double click on a desktop OS's. Note, this is to be used in rare circumstances, it is not required to launch applications or open files as in desktop OS's, a single tap has been assigned to this. Single tap places a cursor, double tap selects a word, triple tap can select a sentence & single tap again clears the selection and places the cursor again.
Example Usage
tap: In window
press button, follow link, open list, select list item, place voice call to selected contact in list, Zoom in to image or browser window, etc
tap: On icon
Open file with associated application, execute application, etc.
tap & hold: In window
can either open a dialog with advanced options or execute some default action.
tap & hold: on icon
in file browser, selected text, etc - open dialog with advanced actions: cut, copy, paste, rename, delete, properties, edit/customize, etc.
tap & drag: In window
Four way scroll within window. Page scrolls in the direction of the finger/stylus direction, equivalent to moving scroll bars, this allows the user to see contents as it comes on to the screen
tap & drag: On icon
Does nothing. Four way scroll interaction over-rides even if screen is not scrollable.
double/triple tap: In window
Used to highlight a word (double tap) or line (triple tap)
double/triple tap: On icon
Does nothing, a single tap event should have already been called, launching the icon's action.
Built-in applications and UI usability and consistency
Contact Application
A contact application should allow for quick editing, entry and selection of contacts. As much of the screen as possible should be devoted to the list of contacts.
The contact list should be sorted alphabetically and either text or icons should indicate what details are present in the contact, ie. if it is a phone or email contact.
Search methods should include name, number, location, date added.
Dialer Application
Most phone dialers display the number at the top, the keypad at the bottom. Use the standard 3x4 (wide x high) layout. DTMF tones should be audible when the phone sound is on. A backspace key to erase incorrect numbers is highly recommended.
A method to link from the dialer to the contacts page should be present for ease of use. Once a contact has been selected and the call is being connected the keypad can be hidden and other buttons displayed. But the option to reveal the keypad should be easily selectable.
When a call is in progress the number and the contact name (if applicable) should be visible. If there is room a photo can be displayed.
IM Application
- something something
