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.

High-level Design Principles

• 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.
• Sharing and sending user data off-device MUST be opt-in, not opt-out.

UI

General

• 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.
  • Favor a model where items have multiple tags, over items having a single category.
  • Small icons in listings aid visual search, by giving the list "texture". (For example, a user may not remember the name of the item he/she is searching for, but remember it had two icons in front.)
  • 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.
  • Support Quick Actions from Universal Search
• Popup UI
  • 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
• Set max-width on columns of text to 35em. Set left and right margins to auto, so the column will be centered.

Notifications/Warnings/Secondary Windows

Types

• In place: input text turns red, message next to group of controls, etc.
• Drawers and panes "deeper" in app navigation
• Toaster (non-modal)
• Dialog box or full-window pane (modal)
• Banner messages (transient; can send when app minimized; tapping re-launches app)
• Dashboard (non-modal; can open when app minimized; persists until dismissed by user, even if card dismissed) Can contain controls.
• System popup (non-modal but intrusive; can open when app minimized; persists until dismissed by user, even if card dismissed) Can contain controls.

Errors, Warnings & Messages

• Cue the user about bad input while they are entering it (for example, use HTML5 input element validation).
• Messages that relate to one control or group should be adjacent to that control or group.
• Transient error conditions should use banner messages.
• Status info (such as the time of the last successful sync) should be in a Drawer or pane "deeper" in app navigation.
• If the user must make a choice, use a non-modal toaster.
• 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.
• System popups are used when it is urgent that the user make a choice. For example, answering an incoming phone call or letting it go to voicemail.
• Apps should not use Dashboards for warnings or errors. The system uses Dashboards for persistent warnings such as low battery.

Notification & Desk Accessory Usage

• When new items are added via sync, an app may create a dashboard. For example, sync of email creates a dashboard when new messages arrive, but sync of contacts does not.
• When an app creates a dashboard, it may also send a banner message.
• A to-do app may create a dashboard to remind users of tasks scheduled for today.
• The Calendar app opens a system popup to remind users of imminent events.
• Dashboards and System popups may be used as "desk accessories"; for example music player controls, a calculator or scrapbook.
• "Notification" dashboards should be standard height. Typically, they have an icon on the left, with a badge for the number of new items. Tapping this typically opens the a card to a list of items. On the right, the text of one item is displayed. Tapping this opens a card showing that item in full.
• "Desk accessory" dashboards that the user initiates may be taller.

• 

  Standard-height "notification" dashboards on phone

• 

  Standard-height "notification" dashboards on tablet

• 

  Tall "desk accessory" dashboard

• 

  "desk accessory" calculator in system popup

Dynamic dashboard template for Enyo 2 apps

Text

• 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".)
  • Avoid negative phrases ("invalid account", "server error").
  • Minimize superfluous words like "please"
  • Technical details should be hidden behind a disclosure triangle.

The Application Menu

T.B.D.

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.

Resource Usage

Apps that have no cards, dashboards or system popups will be killed by the system. JavaScript Services are killed after a timeout unless they are called again. To keep a service running, don't increase its timeout. Arrange for it to be called regularly.

Minimized

While not maximized, apps continue to run. They should detect minimization events, and stop animation and other expensive operations. setTimeout calls will return, but the timeout will be many times the specified one.

Services & Actions

Apps and Synergy Connectors should use JavaScript Services, started by Actions, to sync data. Typically, the Action will require that an internet connection be available before the sync starts. High-bandwidth syncs might specify that a wifi connection be available. Actions can also help battery life by "batching" syncs. Always provide a way for the user to cancel any future background activity.

Typical 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.