Learning the Lessons of WAP (a case study)

The Challenge of Multi-channel Delivery

Current web application vendors can rely on their users to download the most recent version of their web browser when necessary. At present, therefore, designing and presenting content for the Web is primarily done in HTML, and it is usually aimed at the most recent generation of browser technology for the personal computer: Internet Explorer from Microsoft, and Netscape's Navigator.

 

The challenge now, and in the future, is in delivering meaningful content to a wide range of mobile communication devices, with a spread of computational and presentational capabilities - any implicit assumptions about the form factor of the target device must be abandoned. WAP can potentially be used to accommodate the range of form factors that will be present in the next generation of personal communicators connecting to Internet-based systems.

Integration with Existing Web Architectures

The current generation of web applications must be reinvented to succeed in the mobile market. The existing server-side structures designed for HTML are here to stay, so they must be re-engineered to play their part in the mobile Internet.

 

Many of our clients have existing server-side business models that can be readily adapted to deliver content to WAP-enabled devices.

Application Architecture

Our application architecture is based around the Java 2 Enterprise Edition (J2EE) platform. It consists of an n-tier, distributed computing model that can provide scalable and robust deployment of e/m-commerce systems that can be accessed securely over the Internet.

 

We anticipated the need for our applications to access a wide variety of backend systems. Building a service-oriented architecture around existing IT infrastructures will be a critical factor in the success of many web-focused systems. This architecture will allow a logical and functional (rather than physical) view of system services, increasing the ease of component-based development and reducing the time to market of new systems, by leveraging the power of legacy development.

 

The following diagram represents the basics of our architecture:

 

Services

The following section contains a list of the services that we wanted to deliver to users of WAP devices. While not all were required as part of the global-chat and stock information systems, they were investigated as part of our ongoing review of the requirements and deployment of WAP-based applications.

Session Management

Effective management of server resources, and the handling and security of user sessions, is an area that is poorly handled in many traditional CGI- and servlet-based systems. We wanted to develop a session management mechanism that would leverage the functionality of the Java HTTPSession object, and the power inherent in the JINI leasing model.

Security

Security constitutes one of the primary requirements in any business information system; this is particularly true of the banking and finance sector, and was something that our client was extremely conscious of.

 

We are currently using Netscape Directory Server to implement basic authentication and to retrieve user information. Security over the wire can be implemented using Wireless Transport Layer Security (WTLS); WTLS is the wireless equivalent of Secure Socket Layer (SSL) also known as Transaction Layer Security (TLS).

Directory Services

Directory services, particularly LDAP, are enjoying widespread adoption at the moment, and have an important and relevant role to play in e/m‑commerce. With the small screen size of most WAP devices, user configurations and preferences play a more significant role than on the larger screens of the wired Web. Delivering meaningful content to an individual using a particular device needs the services of a powerful mechanism to retrieve configuration information quickly - this a role ideally suited to LDAP.

Messaging Capabilities

Messaging and e‑mail capabilities are at the heart of successful e/m‑commerce. The adoption of SMS and its success in the marketplace provide a useful indicator for the predicted adoption of the more advanced capabilities of e‑mail on mobile communication devices.

Interface Design Issues

Moving from HTML 4.0 to WML 1.1 was a real culture shock. Once the back-end architecture was in place, the main challenge we faced was that of delivering usable applications through a device with a small screen and limited bandwidth.

Interactivity

The growth of the Web was partly due to ordinary people being given the ability to create interactive content.

 

"...my definition of interactive includes not just the ability to choose (the content), but also the ability to create. We should not only be able to follow links, but create them - between all sorts of media."

Tim Berners-Lee, Weaving the Web

 

While current WAP-enabled mobile devices have little or no multimedia capability, the principle remains the same: ease of use and the ability of the user to direct and control their online experience is crucial to the success of WAP applications.

The challenge we faced with WML was to allow individuals the ability to manipulate, link and create content through their WAP devices as easily and creatively as they were able to in the mid-90s with HTML on the Web.

 

From our experience in writing WML, and the feedback we received from our test users, we knew that more attention had to be paid to the usability of our menu layout and overall navigation design.

 

Applications must allow the user to choose the functionality they require from the business functions available; preconceptions about layout, structure, and content must be kept to a minimum. This is especially true for devices with limited bandwidth and computational resources, where redundant functionality will cost the user both unnecessary time delays and expense.

 

This is the challenge that must be met in order to accelerate the acceptance of WAP devices; it will require a new way of thinking about the presentation of information and the input of data through non-computer terminal devices.

Even a basic computer monitor can display 800 by 600 pixels, and a single line of text can accommodate 100 or more readable characters. We also have color and a wide variety of different styles, typefaces and graphics at our disposal in order to make the browsing experience both easy and pleasurable for the user.

 

The screen size on the Nokia 7110 mobile phone is 96 by 44 pixels - less than one-hundredth of the area! It can only fit around 14 characters on one line of text.

 

Our initial interface was very much driven by the structure of the basic functional requirements. After implementing a rather clunky UI first time round, we realized that to design WAP applications successfully, we had to rethink things completely. It was necessary to abandon all preconceptions about functionality in order to take advantage of WML, and avoid its limitations.

 

Our 'second take' at the user interface design considerably improved the user experience, and increased our awareness and understanding of the issues involved. The key areas we targeted were:

 

Ø       Reduction of the amount of user input - it is slow and cumbersome on a phone

Ø       Simplification of the menu structure

Ø       Giving easy access to the main menu, to stop the user from feeling lost

Ø       Consistent naming of menu options

Ø       Reassuring user with visual clues (such as the synchronization of menu options and the titles of screens)

Ø       Providing the ability to undo any choice easily

 

Navigation is more difficult with a small screen, so the menus have to be extremely easy to navigate, and the structures as shallow as possible. Clicks/selections must be kept to an absolute minimum. Simplicity and brevity are the name of the game.