The next big challenge of the Internet is mobile access. More and more information is available on the Internet and intranets and mobile users will also need access to it. Wireless Application Protocol (WAP) based devices make it possible to access Wireless Markup Language (WML) based services with mobile browsers. The first WAP compliant devices have already been released on the market and more are to come.
In the future there will be a need for Web services that are specially targeted for mobile users. We have studied this mobile-aware approach to service design by implementing a WML application and evaluating it on three different WAP platforms. Based on our evaluation results, we recognize challenges for future WAP devices and mobile-aware services.
We have also studied if it would be possible to access the already existing Internet information with WAP devices. We have developed an HTML/WML conversion proxy server, which converts HTML-based Web contents automatically and on-line to WML. This approach gives the mobile users transparent access to their familiar Web pages from their mobile phones and other mobile devices. Our study indicates that if HTML-based Web services follow certain guidelines, they can be converted automatically to WML and adapted to the client device. In principle these guidelines already exist as W3C Web Content Accessibility Guidelines and W3C Note for HTML 4.0 Guidelines for Mobile Access.
The rapid growth of Web services has led to a situation where companies and individuals rely more and more on material that is available on the Internet and intranets. An increasing number of people use Web services both at work and at home. The next step is to gain access to Web services for mobile users too. Already before WAP some simple interactive services have been available on mobile phones. These services are based on the GSM short message service (SMS) and include schedules, news, sport results, weather forecasts and so on. Although the available SMS-based services are quite awkward to use, they have become very popular. This indicates a need for additional mobile Web services. Access itself will probably be the killer application for the mobile Internet. 
Wireless Application Protocol (WAP) together with Wireless Markup Language (WML) constitute an open architecture for mobile Web services. They make it possible to provide markup-language based services for different mobile devices equipped with WAP browsers. The selection of WAP devices is expected to range from mobile phones to palmtop computers. The international specification work on WAP is still going on (February 2000) in the WAP Forum and several details must still be worked out . The first WAP-compliant devices were introduced to the market during the fall of 1999. The WAP services currently available are not generic but they have been tailored to specific WAP devices.
How should the service providers create services to the growing variety of mobile clients? Simultaneously with the ongoing international specification work of WAP, we have studied two different approaches to bringing Internet services to WAP phones and other mobile devices. The mobile-aware approach is to design and implement totally new services that are specially designed for mobile users. A more generic approach is to develop techniques with which current Internet services can be converted transparently and in real time suitable for mobile users. We have implemented and evaluated both kinds of solutions. As an example of a mobile-aware application, we have implemented a Business Card Search Service (BCSS). Our mobile-transparent solution is an HTML/WML conversion proxy server. Through the proxy server, the users can in principle access exactly the same Web services as from their desktops. If it is possible to convert services transparently to mobile users, the service providers will save a lot in implementation and maintenance costs. However, we assumed that this mobile-transparent approach would not produce results as good as services designed specially for the mobile clients.
In this paper we first describe our technical framework as well as the implementation of the mobile-aware application and HTML/WML conversion. Then we describe our iterative design approach, evaluation methods and results. Finally we analyze the evaluation results and recognize possibilities and challenges for future WAP devices and applications. We also point out recommendations for Web page design.
Symbian has classified future mobile devices into three categories: communicators, smartphones and feature phones. The classification is based on input methods and display size. Display sizes vary from 48x48 pixels in a feature phone to full VGA in certain communicators. The main input method for communicators is a QWERTY keyboard or an emulated keyboard on the screen. A keypad is recommended for smartphones. 
WAP devices will include all of Symbian's categories. In addition to the display and input methods, future WAP devices will also vary by accepted content types and network connections. During the fall of 1999, WAP devices began to appear on the market, the first two being the Ericsson MC218 palmtop computer with a WAP-browser and the Nokia 7110 WAP phone.
Because the variation of WAP devices will be very wide, the services have to take into account the capabilities of the mobile clients. The WAP specification defines the User Agent Profile (UAProf), which will be used to transmit information about the client. It includes device hardware and software characteristics as well as application and user preferences. The UAProf specification was not published until November 1999 in the WAP Forum . That is why we could not yet utilize it in our design.
The contents of the WAP services are implemented in Wireless Markup Language (WML) and WMLScript. XML (eXtensible Markup Language) is a metalanguage for describing other markup languages. As a metalanguage XML makes it possible to define customized markup languages for different purposes . WML is an XML-based markup language designed for low-end devices and slow, unreliable networks. WML provides basic means for document formatting and user interaction but presupposes little of how they are actually implemented. Developers of WAP services only design the interaction logic in the application. Each client device then implements these interactions in its own way.  
As an example of a mobile-aware application, we have implemented a Business Card Search Service (BCSS) in WML. Our mobile-transparent solution is an HTML/WML conversion proxy server. Through the proxy server, the users can in principle access exactly the same Web services as from their desktops. These two design approaches are illustrated in figure 1.
As test platforms, we have been using three WAP device simulators. The UP.Simulator 3.1 (UP) by Phone.com (www.phone.com), Nokia WAP SDK 1.01 and Nokia WAP Toolkit 1.1 (Nokia, www.nokia.com) offer WAP phone simulators. Wireless Application Reader by Dynamical Research Systems Ltd. (DSR, www.wap.net) simulates a palmtop-computer-like device with a resizable display window. All the simulated browsers run on the Windows operating system and handle WML version 1.0 or 1.1. The test platforms can be seen in figure 2.
With our Business Card Search Service (BCSS) the user can search contact information by making queries to a business card database. We could not utilize User Agent Profile (UAProf) specification yet but we studied how the same WML code would work on different devices.
The Business Card Search Service (BCSS) offers three different query forms. The so-called simple search form uses only last and first name as search criteria. The extended search form includes additional search possibilities for title, organization, etc. With the free text search the user can search a string from any of the business card fields.
The search results are displayed as a list of names. The user can set the application up to show either organizational, phone, email or address information in addition to the name in the result list. If several persons meet the query criteria the user may decide to make a new, more refined search or browse through the list to find the correct person. When the user finds the right person she/he can get the full business card information by following the corresponding link in the result list. The user can also browse the business cards or the included photos without returning to the result list.
The structure of WML is based on deck/card metaphor. A WAP application may consist of one or several WML decks. A WML deck is divided into cards. A deck is sent from the server in one transaction but the browser usually shows only one card at a time. Typically all the contents of a card do not fit on the screen of a WAP phone so the user has to scroll the screen to see the card in full. 
The Business Card Search Service consists of an LDAP (Lightweight Directory Access Protocol) database, WML and WMLScript document templates, and server software written in Java. The content format of the business cards is based on vCard defined by the Internet Mail Consortium (IMC) . The server fills in WML document templates with data extracted from the business card database.
During our Business Card Search Service development process the specification work of Wireless Application Protocol (WAP) and Wireless Markup Language (WML) was still going on. The three browsers that we used in our tests each used a different content type for WML documents. The image format was a problem too. In the beginning of the implementation none of the WAP device simulators accepted the WAP bitmap (WBMP) format. The UP simulator handled only the BMP format and the DSR Wireless Application Reader accepted only GIF images.
In the Nokia simulator, the application could not redefine the texts for the soft keys. That is why we decided to avoid soft keys and used links instead.
In our initial design we divided the result deck into three cards. The first card contained the business-related items and the second contained more personal information like home phone number and a photo. The third card of the result deck was a prefilled query form to be used as a template for making a new query. Only the DSR simulator supported navigation between WML cards. The links to the following cards required several user actions on the other two browsers. Our expert evaluation suggested that a single scrollable card would be easier to use. So we rejected our initial design and implemented the business card as a single WML card.
Web environment may include separate specialized proxy servers that perform different tasks of conversion, caching and content adaptation. Proxies may support the adaptation of Web application content to different terminal and network environments. A proxy server can for instance try to minimize the information flow over low/medium speed wireless links. The proxy server may filter out some content types of HTTP streams (e.g., images, Java script or Java Applets). It can also modify the content (e.g., image depth and size) based on the user's preferences and channel throughput. 
Our HTML/WML conversion has been implemented into a proxy server (Figure 1). In addition to the conversion, the proxy server includes both caching and content adaptation. WML devices access HTML services through the proxy and thus get transparent access to the HTML services. The conversion first checks and validates the HTML document. Then, the server parses the document, converts the contents and rearranges the contents as WML decks and cards (Figure 3).
In addition, the conversion proxy aims to format the document according to the capabilities and preferences of the mobile client. Without the User Agent Profile (UAProf)  we could only adapt to the User Agent type (the browser in the client device).
The parsing breaks the HTML data into its logical elements, such as start- and end-tags, attributes and text. The parser also checks the document against the given Document Type Definition (DTD) and it corrects errors. When converting from HTML to WML, some data is inevitably lost. The terminal adaptation phase may work optimally only if it has access to all information in the original HTML, so it is reasonable to integrate adaptation to the document type conversion. The document type conversion is done by a script. During the conversion an intermediate tree structure (which corresponds to the resulting WML decks) is created. Then, the tree is manipulated according to adaptation rules, which utilize information about the capabilities of the requesting user agent, configuration parameters (such as force conversion of HTML table items to separate WML cards) and the user's preferences. After the whole document has been processed, the tree structure is converted to one or more WML decks. Each deck includes a hierarchical group of WML cards. Each child card has a link back to its immediate ancestor card and to the next child card (if any). The depth of the hierarchy is not limited.
For HTML tables we have three different conversion methods, which convert the original table to a WML table, to an indexed sub-tree or to a list. The method is chosen according to the size of the table and user agent capabilities. WML (since version 1.1) supports tables that are in many ways similar to HTML tables. However, the presentation is complicated because user agents with small screens have to figure out how to present a large table in an understandable manner. Moreover, the WML 1.1 tables may not be nested. The indexed sub-tree is a two-level tree, where the root card is an index of links to the leaf cards. Each leaf card presents the content of a single table cell. This conversion method works well when converting layout tables. The simplest way to convert tables is to convert them to lists. We concatenate the contents of the table cells to form a list that produces compact and clear output, but dismisses with the table structure. This method is similar to the one that the Lynx browser uses.
HTML forms contain a group of user input elements. All essential HTML user-input elements can be converted relatively easily to WML controls. However, the graphical layout and most of the grouping of the user input elements are inevitably lost in conversion. User input elements on a form are converted to a single card, where they appear in the same order as in the original HTML code.
Each HTML frame of a frame set is converted to one or more WML decks. Frame sets are converted into decks that provide indices to WML decks that correspond with individual frames.
Images are currently presented as short text entries using either the included meta data or the image source file name. However, in the near future, we aim to adapt and convert image files according to available UAProf information. The image map is converted to a list of links. Lists are converted to a set of paragraphs, each starting a new line.
One HTML document typically produces several WML decks.
The problem in creating indices is to find informative labels to the links. HTML 4.0 includes many possibilities to include the meta data but unfortunately these possibilities are seldom used. If the meta data was not present, we inferred the labels from the text or other content of the element.
Tables are common elements on Web sites. They are used either to generate page layout or to organize information. In the automatic conversion, it is difficult to define the purpose of the table. That is why we had to decide the conversion method based only on the size of the table and user agent type.
"Submit" buttons often caused problems when filling in and submitting forms. Often the button was not a standard HTML button but an image. Our conversion was not able to cope with image buttons. Logging into sites is often based on login scripts, which could not be converted. Preformatted text also was a problem because the formatting does not function on a small screen.
Often there was so much material on the Web pages that even if we managed to make the conversion, it was difficult to access the resulting WML decks and cards with a small display. Our conversion was not able to judge the importance of individual information elements.
Our human-centered design process employed four kinds of activities as described in the ISO standard 13407 "Human-centred design processes for interactive systems" :
In the design process we used three different points of view: the technology itself, the mobile user and the service provider. Service providers, device manufacturers and end users have actively participated in our design process.
Our initial user requirements and context of use analysis were based on a literature survey of current research results, analysis of corresponding products and scenarios of typical usage situations. Our design process allowed us to identify new user requirements and feed them back into the process throughout the whole life cycle of the project. Design rationale has been very essential in this kind of design process where the WAP specification work is still going on. We need to keep track of the changes in user requirements as well as the changes in the technical possibilities and how we responded to these .
Evaluation has been a continuous activity throughout the design process. The aim of the evaluation was to find usability problems, to understand the reasons for the problems and to give feedback and new ideas to the design. In this way we could assure that our design was going in the right direction.
The main evaluation method has been the design walkthrough. This means meetings, where the users, application field experts, designers and usability experts together go through design solutions to get feedback and to generate new ideas. We also had small-scale user trials as well as expert evaluations throughout the project. In the end of the project we had a more thorough user evaluation for both the Business Card Search Service and the HTML/WML conversion.
The Business Card Search Service was evaluated with six test users, aged 13 - 52 years (table 1). The experience of the users with mobile phones varied from modest to expert. All but one had a personal mobile phone. The Internet experience of the users was moderate or better.
We evaluated the application with each user in a separate two-hour session. Each user tested the application on at least two platforms. The order of the devices was changed for each user, so that half of the users started with the PDA type device and the other half with a phone. The phone simulators were run on a PC with a touch screen so that the users could press the keys of the phone. The test set-up is illustrated in figure 4. The simulated PDA device was run on a PC and operated with a mouse. We had two sets of test tasks so that the user would try each available search method. The task sets were identical except for the given search information.
The HTML/WML conversion proxy was evaluated with four test users, who were all familiar with mobile phones, the Internet and computers (table 2). However, the users were not very versatile in their mobile phone skills. The attitude towards new mobile phone services was positive, except for that of one of the users who wanted to restrict his phone for only speaking purposes.
The system was evaluated with each user in a separate one-hour session. All tests were carried out with the Nokia WAP simulator, which ran on a PC and was operated with a mouse. The test session included filling in background forms, explaining to the users the basic idea of the HTML/WML conversion, doing four test tasks and conducting a final interview. The themes of the evaluation were general impression, ease of use, navigation and usefulness.
The test tasks included both familiar and unfamiliar Web pages. The test tasks included navigation, browsing, using frames and menus, editing text, etc. The users could also try the conversion with their favorite sites.
All the evaluation results were analyzed in the project group. We identified new or revised user requirements, classified them and decided how to respond to the requirements. Most feedback of the evaluation led to changes in our software. We also faced requirements that we could not respond to: features that could not be implemented, bugs in the simulators, requirements for the WAP devices and requirements for Web page designers.
We concluded the results with challenges for WAP devices, possibilities and challenges for future mobile-aware services and recommendations for Web page design.
Although we evaluated the Business Card Search Service application and the HTML/WML conversion proxy separately and with different users, the results include similar issues. Below, we present first similar issues like platform-related results and usability problems in scrolling, navigation and using forms. After that we describe the results that are specific to the design approach: mobile-aware Business Card Search Service or mobile-transparent HTML/WML conversion.
The WML application could only utilize the soft keys and navigation keys of the phones. There seems to be a need to utilize the keypad more. All users suggested that shortcut keys would be useful. On the Nokia simulator most test users tried to start the search by pressing the green phone key. The users would also have liked to have had a short cut key for returning to the home page of the site. Both predefined shortcuts like the green phone and user-defined personal shortcuts would be useful.
After pressing "Back" the browsers did not return to the section on the previous page where the user had followed the link. This was frustrating, especially since scrolling a long Web page is a slow process. Another useful feature would be the possibility of scrolling the page so that the user could go straight from the top of the page to the bottom and vice versa.
Scrolling was difficult for most test users: the UP simulator gave no hint that more text was available than seen on the screen. The Nokia simulator had a scrollbar to indicate that there was more text available above and/or below. Most users did not, however, notice the scrollbar. The users who were most experienced in using the Internet tried more actively to find whether there was more text below. In figure 5 there are screen views of scrolling down the query form of the Business Card Search Service.
With the small screen of a phone it was difficult to form a mental map of the structure of the Web page or the application. Even a few lines of text on a regular Web page requires quite an amount of scrolling on a small screen. Often the test users quit halfway through and returned back to the beginning of the page. Only a few users tried to scroll immediately just to see if there was something more outside the visible screen. The scrollbar of the Nokia simulator went unnoticed even by those test users who owned Nokia 5110 or 6110 mobile phones with a similar scrollbar.
In task two of the conversion proxy user evaluation, one of the users stated: "I expected the result to be the first thing on the page, not somewhere down there". He found the page that displayed the e-mail address requested but did not scroll far enough to find it.
One of the users suggested that scrolling would not need to proceed only row by row. After the cursor reaches the bottom row, the browser could present the whole new screen of text. Only one row of the previous screen would need to be left visible to preserve the continuity. A find function would also be useful in browsing through the information on long pages.
In the WAP phone simulators, navigation arrows were used for scrolling. Scrolling may be easier with a phone that has a scrolling wheel like Navi Roller on Nokia 7110.
The users seemed to scroll more boldly on a familiar page, knowing it contained the links they were looking for. All users agreed that browsing through familiar pages was easier and required less mental strain than unfamiliar pages. The users claimed that they did not use the mental image they had about the page. They seemed to simply search for the link that they knew would be on the page and followed a familiar path from there. The appearance of the page was not the most relevant thing as long as the navigation path remained intact.
In the Business Card Search Service tests the users who had seen more of the page on the DSR simulator remembered quite well which information was left outside the visible screen. This encouraged them to scroll down the screen.
In the WAP phones, the visualization of the forms was quite different. The UP simulator represented each field in a separate window, whereas Nokia represented all fields on the same screen. With the UP simulator, the user could input text to the input field immediately but was forced to go through all the fields of the form. The users often thought that they had to fill in each form in the search. The situation is illustrated in figure 6.
In the Nokia simulator the user could select which fields to edit. The fields looked like the user could input text directly into the field on the form. It was confusing that the input fields could not be edited on the form screen but the user had to select the field first. The input operation was quite complicated, as illustrated in Figure 7. After a) identifying the search field the user had to b) select the field to be edited c) edit the field text and finally d) submit the field.
The users sometimes had difficulties in identifying input fields, which on the Nokia simulator were not very visible. When searching for an input field, the users often passed the field several times while scrolling up and down without identifying it.
The test users suggested that the names of the fields could be left out. "We can recognize an email address or a mobile phone number, you dont have to name it!" Leaving out the names would not work in all cases, e.g., you cannot always say if a name is a name of a person or a name of a city. However, often the texts could be replaced with descriptive icons to save screen space. Unfortunately we could not try this because of the problems with the graphics support in the WAP device simulators.
In the search results list, we presented the name of the person and his/her organization on a single line. This text was a link to the business card of the person. When all this text was shown underlined and highlighted as a selected link, the screen became too cluttered (Figure 8). We decided to add extra line breaks to the results in order to avoid this cluttering on the small screen. Trying to improve the readability of the results on the phone screen, we could not utilize the wider screen on the PDA type device.
During the test and in the final interview, the users suggested some improvements to the application. The user has to be able to suspend a search when needed. The users pointed out personal preferences for the order of the information on a business card. It is essential to get the most important information first because scrolling takes time. In different contexts of use, the users need different search fields. It would be useful to let the user set up which fields of the business cards she/he needs and in which order. Also, personally set short cut keys would improve the efficiency, especially for frequent users. From email addresses and phone numbers there should be links to send email or to make a phone call.
Our test application did not include the possibility of storing the business cards. In practice, the users will probably have a personal database of business cards on their phones. It would be useful to get an automatic update and notice when a persons business card has changed.
Our conversion worked quite well with frames. Often, however, the frames had strange names like "menu1.htm". When the titles were not descriptive enough, the users had to use a trial and error approach to browse the contents. The users did not feel comfortable selecting a link named as a file name. Some test users selected these links only after trying everything else first. In figure 9 there is an example of converting frames. The frames are converted well to a list of links but the conversion could not find meaningful names to the links.
A layout table is often used as an alternative to frames. On this kind of a page, menu links are in the left column and the contents in the right column. When the page was converted to a WAP phone, the user saw first the list of menu items and then the contents. When the user selected a menu item, a new page was loaded. The part of the page that was visible on the screen of the phone remained unchanged because it still presented the menu links. The user got the impression that she/he came back to the same page from where she/he just left. All the test users had problems with layout tables. Figure 10 illustrates the situation. The user has to browse through the list of menu items before getting to the contents. Each time after selecting a menu item, she/he has to browse through the same list again before getting to the actual contents.
Missing line breaks on the pages caused confusion in layout and navigation. In figure 11 there is a view of a news service. The number of a news item acts as a link but it is difficult to identify if the title of the news is before or after the number.
One test user suggested a variable font size so that he could browse through the contents without actually reading it yet, and then select a piece of the page to be read in larger font. Lars Holmquist has studied this kind of approach . In his approach the "small font" is actually graphics, which presents the structure of the page. This approach requires transmitting images, which is not very fast. If the WAP phones would support small fonts, the zoomed out content could still be sent as text.
Often the pages that we considered informative, such as timetables, news, opening hours, etc., did not work well with the conversion proxy. Timetables could not be found due to error messages or could not be shown properly due to problems with preformatted text and tables. News pages required logging in, which was also prone to errors.
Many of the error messages seem to be caused by imperfect or faulty HTML code. Despite the faults, regular Web browsers show many of these pages correctly. However, the conversion often turned out to be difficult or impossible.
Even if the conversion succeeds technically, there is still a problem with the amount of information. Mobile users would benefit from a Web page design where the most often needed information is on the top of the page. Another need is better facilitation of scrolling and navigating within a page on WAP phones.
As a whole, the evaluation results indicated that even complex-looking and visually impressive pages could be converted in a useful way.
All the test users considered the Business Card Search Service useful. This kind of system could replace an ordinary telephone directory or a directory inquiry service. The users mentioned several other mobile phone services that they would like to use, e.g., banking, sport pools, bus and train schedules, a postal charge service, information searches like Yahoo! and AltaVista, chat, a weather service, service catalogues, tourist information and a dictionary.
The test users of the HTML/WML conversion said that they could use the conversion to find small bits of information, such as timetables, TV schedules, movies, price lists, happenings, addresses and news. Although the users could describe what kind of information they would like to access with their phones, they could not imagine many situations in which they would need the information on the phone. "We do have the Internet at work and at home, may be at a bus stop to check the schedule."
The implementation of the Business Card Search Service revealed many challenges in designing and implementing this kind of mobile-aware application. The interaction logic of the mobile browsers varies a lot and this makes it difficult to design a user interface that as such would work well on different platforms. The main problems in our HTML/WML conversion were the difficulties in separating contents and presentation as well as the missing meta data to name and describe the HTML elements. Both of the design approaches have their benefits and problems. The mobile-aware application has to adapt to different mobile devices. It is worth considering if the application could be designed on a bit more general level to make it mobile-transparent. Then the conversion proxy could take the responsibility of adapting the service for different platforms.
Below we summarize our findings as challenges for future WAP devices, challenges and possibilities for mobile-aware WAP services and recommendations for Web page design to support HTML/WML conversion.
In our tests we used the first versions of the WAP device simulators by Nokia, Phone.com and Dynamical Systems Research Ltd. There were some bugs in the simulators and they were sometimes a bit unstable and slow. The main problems were varying support for graphics, missing support for soft keys, implementation of the forms and problems with navigation arrows. Many of these problems still exist with the first WAP devices that are commercially available. Hopefully the problems will be solved in forthcoming WAP devices.
Two of the devices did not support the visualization of WML decks and cards. That is why we did not use this metaphor in our WML application. We replaced the deck cards with a single scrollable card. If future devices support the deck/card metaphor, the applications could be designed accordingly.
Scrolling was a problem with WAP applications. The users gave up easily if they had to scroll down to find a piece of information. The contents of the applications should be designed so that the key information is on the first screen. WAP devices like Nokia 7110 include a scrolling wheel (Nokia Navi Roller) for faster scrolling. In addition to this, the device or browser could support scrolling e.g., with an adaptive scrolling speed, an illustrative scrollbar and a find function.
It would also be useful if pressing the Back key would return the application to the section of the previous page where the user followed the link. Scrolling could be avoided by facilitating zooming in and out to the contents of a page. It was especially difficult to navigate in tables. More studies should be done on how to visualize tables on a small screen.
Filling in forms was quite a complicated process in both WAP phone simulators. The same problems seem to exist with the first WAP devices. Hopefully in future devices the forms will become easier to use.
Short cut keys would also be useful; for instance, the users found the "Green phone" key of the Nokia simulator as an obvious "Accept" key. The efficiency of the services could be improved if the applications could utilize the keypad of the phone better. Short cut keys could also be user programmable.
WAP specification work did not progress as fast as we expected in the beginning of the project. That is why we could not utilize User Agent Profiles in our application. In future versions the adaptation of the service must be based on the attributes of the User Agent Profile. In our study with the Business Card Search Service, the usability of the service was improved by letting the users select which business card fields they wanted to see and in which order. This kind of content and presentation adaptability would probably be useful in other services too.
In our project, the support for graphics was quite modest in the simulated WAP devices. Using descriptive icons instead of texts, where possible, could save valuable screen space in future services.
Network connections with mobile systems are often less stable than fixed connections. That is why it is important for users to be able to trace and cancel selected operations.
Future applications should be able to utilize links to e-mail addresses and telephone numbers to send e-mail or to make phone calls.
In real applications, often part of the information is stored on the user's own device and part on the server. There should be means to update and maintain the information automatically.
In future versions of the conversion proxy, even graphics and other media could be converted. The user should be informed of the existence of different elements, even if the conversion cannot convert them. However, it would be useful to recognize and skip some less important elements.
Sites that are navigable and readable with the conversion proxy are usually sites with a simple structure and few tables. Use of descriptive file names and the "alt" attribute for images and frames is important. Also, the closer the code is to the HTML standard, the easier it is to develop the conversion rules.
Familiar pages were easier for users to navigate. This suggests that if an already existing Web service is provided to WAP users as a separate application, it would be a good idea to maintain the basic structure of the site.
Frames were easy to convert and the result was easy to use. We could not convert layout tables so that the result would be usable. It was difficult to distinguish layout tables from other tables in the conversion.
Some elements turned out to be problematic in the conversion. Image buttons should have textual alternatives. Login scripts cannot be converted; there should be alternatives for them. Preformatted text does not work on the small and variable-size screens. Missing line breaks create confusing layout or even navigational errors. Line breaks should be used to enforce the visual structure of the page by grouping data. Style sheets for different screen sizes should be provided instead of preformatted text.
Many Web sites were loaded with a lot of textual information. The main pages should be kept simple and the extra material should be put on additional pages for those who need it and are able to access it. Anchor links within a page are very useful because they reduce the need for scrolling.
The World Wide Web Consortium, W3C, has recently published two guidelines for improving Web accessibility. The work on HTML 4.0 Guidelines for Mobile Access is still going on but a Note for Discussion was released in March 1999 . This planned guideline will include instructions on how to make a Web site available to users with slow mobile network connections and/or small devices. Web content Accessibility Guidelines version 1.0 was released in May 1999 as a W3C recommendation . These guidelines give instructions on how to make a Web site accessible to users with disabilities and to people using text or voice based browsers, slow networks or small screens. The guidelines point out that everybody can have accessibility problems depending on his/her context of use and the available terminal. The duty of the designer of a Web service is to assure that the accessibility problems can be overcome.
The recommendations of the W3C Accessibility Guidelines include the following:
The W3C guidelines have not been designed especially for conversion proxies in mind. In spite of that, we found out that most of our conversion problems could have been avoided if the Web sites that we were using in our tests would have followed W3C Accessibility Guidelines. The Mobile Access Guidelines Note was even a bit too strict for our purposes. However, by following it, the designer of a Web site can almost be sure that the page can be automatically converted to WML. When the designers of Web sites start to follow these guidelines, their sites will be available for a variety of devices, browsers and networks. Because the amount of the different mobile devices is growing all the time, this kind of approach should be very appealing to the site designers.
The information content and number of services on the Internet is growing rapidly. At the same time the number of users and the variety of their devices is growing. Service providers face a big challenge in how to respond to the growing demand. Users want to use the same services with different devices depending on their current context of use. The services have to adapt their contents and presentation according to the user's personal and device characteristics and the context of use.
Our experience shows that it is possible to make Web services that adapt to different terminals, both desktop and mobile, without diminishing the site's visual appeal. To support the conversion, the Web page designer has to follow certain guidelines. In principle, these guidelines already exist as W3C Accessibility and Mobile Access guidelines. The guidelines do not restrict the visual design of the service but rather recommend alternative formats and proper use of meta data. When designing a service for both mobile and desktop users, this approach is worth considering.
There will still be a need for mobile-aware applications designed and tailored to the exact needs of mobile clients. In these applications usability can be improved by using descriptive icons instead of texts and adapting contents and presentation to user needs.
In WAP devices, better support will be needed for navigation and scrolling. Forms should be easier to use and it should be possible to define and use short cut keys.
Our future plans include more studies on the adaptivity of the services. The WAP Forum is still working on the specification of the User Agent Profile. We will study user needs for adaptivity more thoroughly. We will also study how the User Agent Profile could be utilized both in mobile-aware applications and in the HTML/WML conversion. We believe that when providing services to the growing variety of mobile devices, service adaptivity is the key issue.
Our research project was carried out with the financial support of the the National Technology Agency of Finland (Tekes). Our work was also supported both financially and technically by companies Ericsson, Radiolinja and Teamware. The authors would like to thank these partners for the fruitful co-operation.
Eija Kaasinen, M.Sc in Software Engineering, is a Group Manager at VTT Information Technology, Human-Centred Design Research Group. Her research interests include methods for human-centered design, intelligent and adaptive user interfaces and usability issues in mobile applications. Eija Kaasinen is currently in charge of usability design and evaluation activities within different research projects dealing with mobile applications and services.
Matti J. Aaltonen received the M.Sc. degree in technical mathematics in 1984 from the Technical University of Tampere. Following completion of the M.Sc. degree, he spent five years at the Technical University of Tampere working at the department of mathematics. From 1989 he has been working at the Technical Research Centre of Finland as a Research Scientist. His main interests are in user interface and graphics programming.
Juha Kolari, M.Sc. in Psychology, is working at VTT Information Technology as Research Scientist. His research interests include usability design and evaluation as well as usability issues with mobile services.
Suvi Melakoski is studying Software Engineering at Tampere University of Technology. She was working at VTT Information Technology as a Usability Research Assistant in 1999.
Timo Laakko is a Research Professor at VTT Information Technology, Service Platforms Research Group. He received a D.Tech in 1994 from the Helsinki University of Technology in Information Processing Science. His research interests include wireless internet, multimedia applications and communication and product models. He is currently the project manager of two research projects, both of which are related to the development of application environments and platforms for Wireless Application Protocol (WAP).