Introduction

This document provides guidelines for creating highly usable WAP Push enabled applications. In addition, the Openwave Mobile Browser alert user interface (UI) model is explained in detail.

WAP Push Usability Guidelines

Mobile device and WAP browser manufacturers employ a variety of UI models for presenting pushed content. Given this, applications should distinguish the user's device and branch accordingly, to provide the best user experience possible for the given device.

For more comprehensive application usability guidelines, including information on how to distinguish between various devices, refer to the appropriate Application Style Guide for your market. For WAP Push programming guidelines, refer to the Openwave WAP Push Library Developer's Guide.

The following detailed usability guidelines are applicable to most WAP Push enabled mobile devices, including all devices running Openwave Mobile Browser:

• Allow users to register for pushed content from both your mobile and PC-based web sites.
  
  Your PC-based users may not know the URL of your mobile web site. If you allow the user to register for your WAP Push service from your PC-based site, you can automatically navigate the user to your mobile site by pushing a service indication or service load to their mobile device. For PC-based registration, solicit the user's phone number and the name of their network operator. Save the phone number and the operator's well known Push Proxy Gateway (PPG) address in your user database for subsequent push requests.
  
  If the user's mobile device is connected via Openwave Mobile Access Gateway (MAG), capture the user's subscriber ID and PPG address from the corresponding HTTP request headers. Save the subscriber ID and PPG addresses in your user database for subsequent push requests.
  
  
• Only push content to users who are expecting to receive it.
  
  Allow users to explicitly register ("opt-in"), before pushing content to them. Don't "spam" users with unsolicited pushed content.
  
  
• Refer to service indications as "alerts" in your user interface and user documentation.
  
  Most network operators, device manufacturers, and application/content providers have standardized on this more user-friendly term.
  
  
• Personalize your pushed content for the user.
  
  Make sure the URL for each push submission links to a document containing personalized content. For example, an email application should link each "new email" alert to the user's personal email inbox.
  
  
• Allow users to set push preferences.
  
  When it makes sense, allow users to specify their personal preferences for receiving pushed content. For example, a news service might allow users to request periodic alerts on an hourly, daily, or weekly basis, or to temporarily disable all alerts until the user explicitly re-enables the feature.
  
  
• Preface alert title strings with the name of your application.
  
  Most devices use a single inbox to present alerts pushed from all applications. In order for users to distinguish your alerts, include the name of you application at the front of the alert title. For example:
  • Mobile Email: 6 New Messages
  • ABC Travel: Your flight is delayed
  • Instant Message: Karen says "Hi!"
  
  
• Keep alert title strings short.
  
  Most devices only display one line for each alert title string and truncate the string if it is longer than one line. Keeping the alert title short allows it to be fully visible without forcing the user to move the cursor and wait for the line to scroll.
  
  
• Ensure all alerts remain active for at least 24 hours.
  
  Allow the user to have adequate time to view each alert. Most network operators will configure the default expiration for at least 24 hours, so if you don't specify the expiration for a service indication, you shouldn't have to worry.
  
  
• Link all alerts to the same URL, for any given user. In response to the URL, display the current alert status or a history of unacknowledged alert details.
  
  Most devices limit the maximum number of alerts that can be displayed and/or stored. Users who receive a high volume of alerts may not get the chance to view and select each alert before it is deleted or overwritten by the device. To ensure the user doesn't miss any critical alert details, link each service indication to the same URL on the application server. The URL should return a page that describes the user's current alert status or a history list of unacknowledged alert details. For example, an email application should link each email alert to the user's email inbox. The email inbox allows the user to view all recently received email messages, even if the user missed the alert for a specific email message.

• Beep, buzz, or flash a light, indicating that an alert has arrived (not all indicators are available on all devices).
• Display a popup message, which informs users that an alert has arrived and allows them to view it or skip it. The popup message is usually of the form: "Alert from <alert title string>. View it now?".
• Display an alert icon.