Human Interface Guidelines

Lune OS aims to be an unobtrusive personal assistant - ready with details, but never in the way. It focuses on people, not the providers of their on-line services, nor the idiosyncrasies of the computer systems they use.

Design Principles

High-level Design

• Assume the user has multiple accounts (and will add and drop accounts over time) that provide similar services.
• Avoid the anti-pattern of a different app for each service. Unify info from different sources (Synergy)
  • Humans can only attend one event at a time, so the Calendar displays events from multiple servers on a single time-line.
  • Humans communicate with people, not accounts:
    • Tapping a person's name in Universal Search shows you various ways to contact that person (for example email, IM or phone).
    • The Messaging app threads together all messages from the same person, regardless of different services.
  • When a popular new service emerges, favor writing a Synergy Connector over writing an app. If the service provides a good mobile web app, there's no point in writing an app at all.
• Leverage the built-in contacts, calendars, communication, task and media APIs and services to provide infrastructure. Application APIs
  • Messaging Synergy Connectors should create contact records for IM buddies. Synergy will associate existing contact info.
  • Project Management software (such as Basecamp) should create contact records for everyone on the user's projects. This won't clutter listings, because searching in the phone app only shows contacts with phone numbers, searching in the email app only shows contacts with email addresses, and so forth.
  • To-do and Project Management software should create Calendar records for any hard deadlines.
  • Social networking software should use the media APIs, so shared photos and videos are just as accessible as the camera roll.
• Allow the user to use his/her existing data and documents, to the extent possible. Carefully consider import and export of data.
• Cache data, so your app is useable offline and has something to display as soon as launched. LuneOS-specific apps should use DB8, cross-platform apps can use IndexDB. Use DB8 Watches so your UI stays current.
• Search and browsing are both first-class UI interactions
• Apps MUST work on both phone and tablet form factors.

UI

• Assume users are distracted and might be interrupted
  • Save user's data as you go; don't have an explicit Save button.
  • Allow users to reverse mistakes. Archiving doesn't require confirmation. Permanent deletion generally should be a two-step process; favor archive & purge (like the desktop trash can) over "Are you sure?" dialogs (where users reflexively click OK).
  • Allow users to partially-complete items (to the extent possible).
  • Automatically back up data off-device [There is not good OS support for this yet.]
• Support standard gestures
  • Figure out what "back" means for your app, and hook it up to the back gesture. For example, switching to a panel that's logically "earlier", or clearing search text, so the full list is displayed.
  • Scrollers should allow both dragging and flicking
  • Lists
    • Single-tapping a list item should show the full item.
    • Allow reordering list items, if that makes sense. (Example: Searchable Notes)
    • Long-press (tap & hold) either selects for re-arranging or re-sizing, or opens a context-sensitive menu. Basic operation should not require long-presses.
    • Consider implementing the Swipe UI [Enyo DataLists will not support swipeable items until after 2.6. Until then, a long-press can open a non-modal toaster.]
  • Double-tap, spread, and pinch are mostly used in the browser and pictures.
  • 2-finger gestures: not currently supported, and use To Be Decided
• Each preference needs a strong justification to exist.
  • Only have preferences that users care about (for example, sorting by surname or given name).
  • Go the extra mile to manage details automatically. For example, the Email app can usually figure out if a provider supports IMAP or POP.
  • Carefully pick defaults; most users will go with default values
  • Support System Preferences, such as left-right hand operation, and nighttime styles. [Details have not yet been worked out for these.]
• Search is a first-class UI interaction
  • Support Universal Search (Just Type) [as soon as the OS implements it]
  • Search should have a single text field; no additional selectors or Search button.
  • Search should be live, updating the display after every keypress. (Example: Searchable Notes)
  • Normalize search terms by folding case and ignoring irrelevant punctuation. Typically, match against the first part of words.
  • Typically, space-separated search terms are ANDed. OR is not directly implemented, but search should be so fast that users can backspace and search a second term. Approximate matching and ordering the results by relevance my be possible in some cases.
  • Search all appropriate database fields. For example, search in Contacts matches by given name, surname, middle names, first initial+last name, nickname, organization, email addresses and messaging addresses.
  • Either order the results the same as an unfiltered list, or sort by relevance
• Browsing is a first-class UI interaction
  • If items can be selected by tags or categories, provide an all-tags or all-categories listing.
  • Allow users to arrange or order items
• Support Copy & Paste and Universal Search actions
  • Support copying of text if at all possible
  • Support pasting text wherever it makes sense
  • Make it easy to push text to the Universal Search field, for re-use by other apps.
  • Allow item creation from Universal Search
• Popup UI
  • Favor in-place UI over dialogs and toasters (for example, overlay an item with action buttons, or use a context menu).
  • Only use modal UI when activity cannot continue without user input.
  • Implement modal UI with a dialog + scrim, or whole-window pane.
  • Implement non-modal UI with a context menu or toaster without scrim.
  • Buttons on dialogs and toasters should have action verbs, for example "Send", "Delete", or "Cancel". Avoid "Yes", "No", and "OK" if you reasonably can.
  • A couple buttons with short labels can be arranged horizontally, if they fit on a phone-size display. Long labels or multiple buttons should be arranged vertically.
  • For right-hand operation, place "Cancel" the the left hand side. Reverse this for left-hand layout.
  • Use color intelligently. Half or fewer of the buttons should be colored. For example, use classes: "onyx-affirmative" on a Send button, or classes: "onyx-negative" on an irreversible delete.
  • See Creating Usable UI - Buttons (but note the code is Enyo v1).

Visual Design

• Visual design should use realistic data, varying in length, rather than lorem ipsum.
• Make users' hastily-scribbled notes look good.
• Tap targets should be at least 48 CSS pixels tall and wide - that's about two lines of text
• Allow for screens as narrow or short as 384 CSS pixels

Messages/Notifications

• Cue the user about bad input while they are entering it (for example, by turning text red).
• Messages that relate to one control or group should be adjacent to that control or group.
• Otherwise, if the message is something the user must deal with sooner or later, use a dashboard or non-modal toaster. Transient error conditions should use banner messages.
• Modal dialogs or panes should only be used if the app cannot continue without the info. For example, if an account must be set up before the app is useable.
• Text should tell the user how to resolve the situation, using control labels where possible. (For example, "Check the user name and password", "Ask an administrator to upgrade your account", "Quit and restart this app", or, for really unexpected errors, "Please report this error".)
  • Omit negative phrases ("invalid account", "server error").
  • Minimize superfluous words like "please"
  • Technical details should be hidden behind a disclosure triangle.

Transitions

• Cross-fades are often used when switching to info at the same level.

Cards

• Only use multiple cards only for separate user tasks. For example, composing an email uses a different card than reading received emails.

Basic User Interface

The main user interface in a webOS Ports app generally focuses on a screen size-aware enyo.Panels kind and a gesture area (virtual or otherwise).

Commonly, the top-level layout uses an enyo.Panels with a CollapsingArranger, which adapts to both tablet- and phone-size screens.

The first panel, which is referred to as the Menu Panel, should contain the app's main menu. The second panel contains the content associated with the main menu's options. This is the Content Panel and it usually starts off blank. Most often a second enyo.Panels kind is nested inside this one to allow for easy transitions between content.

Reference Apps

The best references to work from when implementing a webOS Ports style UI are the existing core app rewrites:

Calculator

Calculator on Github

Calendar

Calendar on Github

Contacts

Contacts on Github

File Manager

File Manager on Github

Memos

Memos on Github

Messaging

Messaging on Github

PDF

PDF on Github

Settings

Settings on Github

Testr

Testr on Github

Proposed Extensions

Consider implementing the Swipe UI

Analyze whether Intents would simplify your app.