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 (or will add and drop accounts over time) that provide similar services.
• Allow the user to use his/her existing data and documents, to the extent possible. Carefully consider import and export of data.
• Seek out commonalities and consolidate related info from different sources (Synergy)
  • Users can only do one thing at a time, so the Calendar displays events from multiple servers on a single time-line.
  • Users communicate with people, not accounts, so the Messaging app threads together all messages from the same person, regardless of different services
• Leverage the built-in contacts, calendars, communication and task services. Application APIs
• 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.
• 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 and browsing are both first-class UI interactions
  • 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.
  • Normally, 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
• 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 selectively. 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 d1).

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" or, for really unexpected errors, "Please report this error".)
  • Omit "please" and negative phrases ("invalid account", "server error").
  • 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.