Application developers are held to a very high standard with regard to User Experience. Use the checklist below to evaluate your application to ensure that it delivers a User Experience that is consistent with HP webOS platform's core applications, embodies the design principles set forth in the UI Guidelines (see the Early Access documentation for TouchPad UI information), and meets/exceeds the user's expectations.
If you can check each checkbox below, you're ready to upload your app to the App Catalog. If you cannot check certain items, explain why when you submit your application.
| Take a Quick Look |
Take 5-10 minutes to launch the application and try many of its features. See "how it feels" overall. Pay special attention to how scene-to-scene navigation & transitions work.
|The application launches quickly and displays content as soon as possible.|| |
It takes less than 3 seconds to launch the application
|Navigating to scenes in the application works the way HP webOS interaction guidelines specify.|| |
On a tablet device, try to minimize the amount of screen transitions the user needs to navigate through. Instead, try to bring new information into the view – for example, use Sliding Panes to navigate through hierarchical content, or use an Interactive Pop-up to perform sub-tasks in the application.
When it is necessary to navigate to a new view within the application, always provide the user with a button to navigate back to the view from which they came. The button should be contained inside a header or footer and aligned to the left. The button should be labeled with the title of the previous view.
On phone devices, the Back Gesture is used to navigate to previous scenes in the scene hierarchy. The scene does not include buttons to navigate to previous scenes in the hierarchy.
Users tap items in a scene to interact with them. Tapping opens a new scene or performs an action.
|All interactive UI elements can be tapped easily and successfully.|| |
All tappable UI elements should be at least 54 pixels tall and 54 pixels wide. If the visual component of a tappable item is smaller than the recommended size, the div it is enclosed should at least be 54 pixels tall and wide to ensure tappability.
| The application works well on |
all targeted webOS devices.
The application has been tested on all webOS devices (either on the device or in the emulator) that it is intended to support and its UI works effectively on all screen sizes/resolutions for those devices.
| Dig Into the Details |
Take 15 minutes to explore key features in detail. Pay special attention to how the things in each scene work, look and feel. Note how well you can interact with the application.
|Views contain controls that react to gestures in the way webOS users expect.|| |
Users can flick and drag to scroll content directly. The app does not include buttons or other controls to scroll content.
Users tap items in a view to interact with them. A tapped item displays immediate visual "tap feedback" so it's clear that the item has been tapped. Tap feedback is the "right" size. It is neither larger nor smaller than the object being tapped (button, row height, etc).
Views support gestures like pinch/spread to zoom in/out of content like images and maps.
|Creating, Editing and modifying Preferences works the way webOS users expect.|| |
When editing content that resides on the device (or in an account the device is connected to) like Contacts, Calendar Events, Tasks, etc., back-stepping automatically saves changes made in the scene.
When creating content that will be sent or posted elsewhere (like an email message), the UI includes a button to send/post the item. Back-stepping saves (but does not send) the item.
When the user edits content in a scene and throws the card away, the changes are saved.
A good practice when saving changes after back-stepping or exiting is to notify the user with a banner-only notification (see below) that changes have been saved.
If the form or a task flow includes a button to leave the scene, it is labeled "Done", rather than "Save".
When changing application Preferences, changes are either applied immediately or are applied when the Back gesture is performed.
For long or complex forms, provide a means for the user to cancel changes without saving. This should be provided using an explicit "Cancel" button.
|Text and labels are easy to read on the device.|| |
Body text should never be smaller than 16 px.
Labels should never be smaller than 14 px. In general, font sizes between 16-20 px work best on webOS devices. Use 20px or larger for header items.
|Data entry is quick and easy|| |
The virtual keyboard is set as expected when the user enters a field. Examples: The email keyboard for entering email addresses; the Form keyboard when form filling; the URL keyboard when entering web addresses.
|The application displays messages when appropriate.|| |
When the application requires a decision from the user before it can proceed, it displays a dialog.
When the app is running in the background and does something the user should know about, but does not require them to interact with it immediately, it displays a banner notification.
When an application is running in the background or foreground and does something that the user should know about, but does not require any further interaction from the user, it displays a banner-only notification.
When the app is running in the background and does something the user must know about and interact with (e.g., calendar reminder, phone call), an alert is displayed.
| The application displays feedback if an action takes |
more than 1 second to complete.
When the app performs an action that takes more than 1 second, an activity indicator is displayed.
When a view takes more than 1 second to load, the app displays UI elements or cached content, and displays an activity indicator while the rest of the content is loading.
When a user taps a button that initiates an action that takes more than 1 second to complete, the app displays a small activity indicator on the button and changes the text label to indicate what the app is doing. (Use the Activity Button for this.)
When an application performs an action that takes more than 1 second to complete, and the approximate duration of the action is known by the application, use a Progress Bar to give feedback to the user.
| Inspect the Application Menu |
This menu appears in the upper left hand corner of a scene. Users can tap it to see standard menu items (e.g., Help), and others that are useful in the current scene. Take 10 minutes to check the important scenes in the app and see if each scene's Application Menu meets the criteria below.
|The Application Menu contains the Standard menu items, in the standard order.|| |
All App Menus contain Edit menu item drawer (first position) and Help menu item (last position).
If the application manages Preferences and/or Accounts, a menu item appears immediately above Help.
If the application manages Preferences only, the menu item is named Preferences.
If the application manages Accounts only, the menu item is named Accounts.
If the application manages Preferences and Accounts, the menu item is named Preferences & Accounts.
If the application supports printing, a Print menu item appears above the Preferences/Accounts menu item.
|If there are general actions a user can perform in a view, they can appear as additional menu items in the App Menu.|| |
The view’s menu items appear between above the Standard menu items, and are separated from them with a menu divider.
Items that appear in the menu should those that are only to be used occasionally. More frequently-used commands should be visible directly in the view.
|The Help command opens a view that includes at least one method of contacting the developer for support.|| |
Tapping the Help menu item opens a Help view.
The Help scene displays at least one method of support (developer website, phone number, email) that works. It can also contain links to application-related help, frequently asked questions, etc.
| The Application is a "Good Citizen" |
No one likes an app that ignores system-level preferences, especially when the user set them themselves, or hogs the processor and memory so much that other apps perform poorly. Take a few minutes and see whether or not your app behaves well in these situations.
|The application respects system-level preferences and settings. It does not override or manage those settings within the app.|| |
If the application uses Location (GPS) information, it uses Location Services and respects the user's OS-level Location Services preferences.
|The application behaves responsibly when it is minimized to a card, and continues to run in the background.|| |
The application checks for and displays notifications at reasonable intervals.
The application does not cause other apps to "slow down" or work poorly while it's running in the background.
Processor-intensive applications (like games) pause when they are minimized to a card.
|The application's size is as small as possible.|| |
The application's size is 500 MB or less
|Symbols are removed.|| For PDK applications, make sure your executable is stripped of symbols. You can use the strip utility program that comes with the ARM compiler to remove symbols from your executable. |
In Windows, you can find this utility at C:Program FilesCodeSourcerySourcery G++ Litearm-none-linux-gnueabibinstrip.exe. No output file needs to be specified, symbols are removed in-place.
If the application embraces all of these values, it will delight users and will be an outstanding citizen on the HP webOS platform.