
Position paper on
WAP Application Usability in GSM Markets
Paul Smethers
Phone.com, Inc.
Corporate Headquarters
800 Chesapeake Driver
Redwood City CA 94063 USA
+1 650 562 0200 (Tel)
+1 650 817 1499 (Fax)
www.phone.com
Copyright ©2000 Phone.com
Overview
WAP is the "Wireless Application Protocol" used to provide Internet content to wireless devices like cell phones and PDA's (Personal Digital Assistants). It operates by taking developer content written in WML (Wireless Markup Language) over HTTP through the Internet to a gateway (typically managed by a telecom operator) that converts the HTTP protocol to the WAP protocols for wireless transfer to a browser running on a wireless device. WML is an XML-based markup language that has elements that make it easy to author content with existing Internet tools that run well given the constraints of small wireless device (small screen, poor text input).
WAP has been rolled out worldwide and is most successful in the U.S. and Japan. European WAP deployments began this year (2000) and are having less success then elsewhere in the world due to multiple browsers with different interaction models. Content written for one WAP browser typically does not run well on another WAP browser.
Problem Statement
WAP Applications in Europe are not as usable as wireless applications in the U.S. and Japan
- "Usable" is defined as intuitive user interface interaction for average consumers: We have measured usability through "usability tests" (end-user testing of WAP applications), and studies of operator usage statistics.
- WAP doesn't standardize the interaction model: This is so that WAP can exist on many different types of devices, like phones and PDAs, all with different screen characteristics, keyboards, (pens, keyboards, or phone dial pads), and key mappings.
- Most developers in Europe use Nokia SDK for development: This causes many applications to be developed that only work well on the Nokia 7110 WAP browser.
- All WAP browsers have a different interaction model: This means that an application written for Nokia won't run in a usable manner on a Phone.com browser or other 3rd party browsers. The same is true between all WAP browsers. This is mostly a browser issue, not a device issue, as Phone.com WAP browsers run the same interaction model on all devices it is ported to.
- Wireless interaction and navigational models are different from PC models: This means that the content to be delivered to these two very different paradigms, and how users expect to navigate in these paradigms are very different. Wireless models tends to be hierarchical, while PC Internet use works well in its current linear model.
End-users of non-usable applications will not adopt or use WAP until these issues are addressed
Solution Constraints
- The issue is with "Interaction," not with "Presentation": Presentation is handled well with CSS, but interaction issues deal with how an element is operated by the user. Interaction is still mixed into content and presentation.
- The standards must allow for the development of a single application for all wireless devices.
- Most wireless devices cannot be upgraded by consumers.
- Consumers will buy whatever device is popular.
- Consumers will reject the wireless Internet if their device doesn't run applications well (they will not understand why it doesn't)
- It will likely take 1 year for a new standard to solve this issue and for new devices to emerge using the standard. This means there will be 100's of millions devices with incompatible interaction models before a standard can be deployed with a solution.
Candidate Solutions
- Encourage authors to target applications to key browsers: There are no solutions for developers today other than to analyze the market and provide the application targeted for the most popular handsets. If developers target their applications for the primary interaction models in GSM, then application usability of WAP in GSM will improve greatly.
Note that this also starts a market-war similar to what happened in the PC world, where applications began to only support Netscape and IE, and all other browsers have to mimic these browsers in order to run the existing mass of content. This means that market leaders will likely emerge and other devices/browsers will need to copy the market leaders to run the mass of content that will be developed before there is a standard that solves this problem.
- Semantically enrich the markup language: This would be like adding new elements to XHTML that have clearer interactive meaning. This would be the addition of common missing elements that are required for basic interaction issues.
- Enable developer control of the interaction model: This would mean developers can explicitly state their interaction model intentions.
Market Example
WAP defines a SELECT
element for providing a list. Some devices interpret this as a popup menu list; others interpret it as a menu that can be used for navigation. The interaction purpose of this element is not defined by WAP, so if a developer uses it, their application may run poorly on one device and well on another.
To solve for this example, a standard must be declared for a higher-level construct like "Navigation Menu" and "Option List" that includes specific interaction instructions. This higher-level construct explicitly defines the intent of the interaction independent of the content or presentation. These new higher-level constructs must be defined clearly in their purpose so that browsers can still customize to the native device user interface model and features/limitations, but the developer gets the intended result.