Top Tips for Designing Great webOS Applications
Palm worked very closely with a group of developers to create the first batch of webOS applications—we all learned a lot in the process. If you read this document you will benefit from a few things we learned along the way:
- Start Out Right
- Make Things Readable and Tappable
- Design the webOS way!
- Communicate Effectively and Appropriately
- Use webOS UI controls appropriately
- Make it easy for the user
Start Out Right
Immerse yourself in Palm webOS applications.
Using real webOS applications on an actual webOS device will help you understand how the standard apps work, and how it feels to use them.
Follow the webOS User Interface Guidelines.
The webOS Human Interface Guidelines help you understand how to design a webOS app so your app looks, feels and works like the other applications on the platform.
Design Your Application Carefully.
Read the Application Checklist before you design your application...and use it to evaluate the quality of your app before you submit your application to the App Catalog.
Test Your Application.
You can develop and test your app on your computer, but it is important to test on a real webOS device, to verify its operation. For example:
- whether the font sizes are readable
- whether the tap targets (for icons, lists, etc.) are big enough and provide the right kind of feedback
- how your app really performs on the device
Make Things Readable and Tappable
Use readable font sizes.
The font size for content in your app should never be smaller than 15 pixels; labels should never be smaller than 14.
Run your app on a device, if you can. If you can't, test them on your computer, take screen shots and scale them down - so you can see what the app will look like when it's running on a webOS device . If you're developing on a 72 dpi monitor, scale your screen shots to 65%. If you're working on a higher resolution monitor, scale the screen shots appropriately — that is, to the actual size of the webOS device screen.
Make tap targets big enough to tap.
Users will tap your application with their fingertip. Make tap targets big enough to tap—generally, 48 x 48. If an icon is smaller, oversize the enclosing
Make sure lists display right-sized tap feedback.
Make sure every tap yields useful, accurate tap feedback. Make sure the tap does not produce under- or oversized visual feedback when tapped, especially in lists.
Check the tap targets the user will actually see.
Make sure tappable objects look tappable. Make them look like buttons or tappable rows. Do not use tiny text links — they're hard to tap.
Use standard push-buttons.
Use the standard push-button styles that webOS provides in the Mojo.Widget.Button API. Here are the rules for button styles and colors:
- Use the primary style (dark gray) for the action in a scene or dialog that the user is most likely to perform. If the action is positive (like "Turn Wi-Fi On"), consider using the affirmative style (green). If the action is destructive (like "Full Erase"), use the negative style (red).
- Use the secondary style (light gray) for all other buttons in the scene or dialog.
If you want to use custom colors, use an approach that is similar to our dark gray/light gray approach. For example, use the darkest hue for a default action and lighter hue for other actions.
Design the webOS Way!
Support navigation patterns webOS users understand.
Create a clean hierarchical scene-flow that uses buttons and list items to move into the hierarchy, and the back gesture to navigate back. Don't include navigation buttons (like Home, Previous or Back) in your UI.
Create accounts the way Palm webOS apps do.
If your app requires the user to create or log into an existing account, set up the account in an Accounts scene that can be accessed via the Preferences & Accounts menu item in the Application Menu. See the Palm Mail, Contacts, and Calendar applications for examples.
Don't display the same buttons in every scene.
Buttons at the bottom of a scene are for actions, not navigation. Do not put the same set of buttons at the bottom of every scene, especially when porting applications from other mobile environments
Streamline your application design by creating unique scenes. Use the command button area at the bottom of each scene for the most important actions performed in that scene.
Use fixed and floating headers properly.
- Fixed headers stay at the top of the screen and often contain other controls (like View Menus) to control what is shown below. Use fixed headers when the title and controls in the header need to be visible at all times.
- Floating headers display a title for a scene, but scroll away when the user scrolls the scene. Use a floating header for the title of a scene that is important when the user first opens it, but isn't needed after that.
Provide navigation hints.
You should include visual indicators when more content exists in a scene, so a user knows they can scroll to it:
- If a scene contains a lot of content that can be scrolled to vertically, implement a bottomScrollFade to show that there's more content below. When you do, you'll also notice that commandMenu buttons float over content at the bottom better, as well.
- If a scene contains content that can be scrolled left/right, include controls (like buttons) the user can tap to navigate to the next or previous item. If you don't want to display them all the time, consider displaying them after a tap.
Check System Services when your app launches.
If your app make use of system services like GPS Location or Time, check those values in webOS when your app launches. Don't ask users to enter their location if they've already indicated that it's okay for any app to use their current location via their Location Services preference.
Communicate Effectively and Appropriately
When your application needs to communicate with the user, keep it short, sweet, and simple.
Create simple dialogs.
A dialog conveys a message to the user and provides a simple choice using a simple set of buttons. Don't use dialogs to render complex UI with many different choices or settings.
When you display a message in a dialog, left-justify the title and the message. All buttons should be full-width and appear below the message.
Use dialogs sparingly.
Display a dialog only when you require a decision from the user. Use banner notifications for information.
Provide feedback during long processes.
If your app is performing a task that might take more than 2 seconds, display an activity indicator. In some cases, it's helpful to display a transient banner notification, to display short phrase that describes what the app is doing. Doing so allows the user to interact with other parts of your app while the task is completing. If it's unsafe for the user to do anything else your app while the process is underway, display a large progress indicator and disable the scene until the action is finished.
Use webOS UI Controls Appropriately
Use webOS controls in webOS apps.
Don't use UI elements from other mobile or desktop platforms in your app. Use webOS UI elements in webOS apps.
Don't change toggle button labels.
Don't change the text labels in toggle buttons. They should only say "On/Off." If you can't articulate what you need using On/Off, use a check box or a pop-up menu instead.
Regarding mobile advertising...
If your app must include advertising, display the ad in a standard location (like at the top of the scene, below a header). If an ad does not occupy the full width of the screen, center it horizontally it in the scene. For more information on mobile web advertising guidelines, check these websites:
Make it Easy for the User
Make it easy to enter data.
In scenes where the user enters values in multiple fields, put the cursor in the first field when the scene loads, and set the keyboard to the proper type (text for a city name, number for a zip code) so the user doesn't have to do it manually. This makes data entry feel easier and go faster. When the user presses the Enter key, move to the next field and set the proper default keyboard type in that field, as well. When the user presses Enter after typing in the last field, invoke the default pushbutton.
Make it easy to find data.
In scenes that display lists, consider implementing them user a filterList so the user can type to auto-filter the list.