10/18/2018
`
`Two approaches to Bringing Internet Services to WAP Devices
`
`Two Approaches to Bringing Internet Services to WAP Devices
`
`Eija Kaasinen1, Matti Aaltonen1, Juha Kolari1, Suvi Melakoski1, Timo Laakko2
`
`
`1 VTT Information Technology
`
`Sinitaival 6
`
`P.O.Box 1206
`
`FIN-33101 Tampere, FINLAND
`
`+358 3 316 3323
`
`{eija.kaasinen, matti.aaltonen, juha.kolari}@vtt.fi
`
`
`2 VTT Information Technology
`
`Tekniikantie 4 B
`
`P.O.Box 1203
`
`FIN-02044 VTT, FINLAND
`
`+358 9 456 4505
`
`timo.laakko@vtt.fi
`
`
`ABSTRACT
`
`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.
`
`Keywords: WAP, mobile access, HTML/WML conversion, usability, evaluation
`
`
`1. INTRODUCTION
`
`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
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`1/21
`
`EX2003
`
`

`

`Two approaches to Bringing Internet Services to WAP Devices
`10/18/2018
`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. [5]
`
`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
`[12]. 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.
`
`
`2. THE TECHNICAL FRAMEWORK
`
`2.1 WAP devices
`
`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. [8]
`
`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
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`2/21
`
`EX2003
`
`

`

`Two approaches to Bringing Internet Services to WAP Devices
`10/18/2018
`published until November 1999 in the WAP Forum [11]. That is why we could not yet utilize it in our
`design.
`
`2.2 Development environment
`
`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 [6]. 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. [12] [13]
`
`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.
`
`
`
`
`
`Figure 1 Mobile-transparent and mobile-aware approaches to Internet access
`
`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.
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`3/21
`
`EX2003
`
`

`

`10/18/2018
`
`3. BUSINESS CARD SEARCH SERVICE (BCSS)
`
`Two approaches to Bringing Internet Services to WAP Devices
`
`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.
`
`3.1 Functionality
`
`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.
`
`3.2 Implementation
`
`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. [13]
`
`
`
`
`
`Figure 2 Business Card Search Service (BCSS) on the test platforms: UP, Nokia and DSR
`
`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) [9]. The
`server fills in WML document templates with data extracted from the business card database.
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`4/21
`
`EX2003
`
`

`

`10/18/2018
`3.3 Implementation issues
`
`Two approaches to Bringing Internet Services to WAP Devices
`
`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.
`
`
`4. HTML/WML CONVERSION
`
`4.1 Implementation
`
`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. [7]
`
`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) [11] we could only adapt to
`the User Agent type (the browser in the client device).
`
`
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`5/21
`
`EX2003
`
`

`

`10/18/2018
`
`
`
`Two approaches to Bringing Internet Services to WAP Devices
`Figure 3 HTML/WML conversion.
`
`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.
`
`4.2 Conversion rules
`
`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.
`
`4.3 Implementation issues
`
`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.
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`6/21
`
`EX2003
`
`

`

`Two approaches to Bringing Internet Services to WAP Devices
`10/18/2018
`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.
`
`
`5. EVALUATION
`
`5.1 The design process
`
`Our human-centered design process employed four kinds of activities as described in the ISO
`standard 13407 "Human-centred design processes for interactive systems" [3]:
`
`understand and specify the context of use
`specify the user and organizational requirements
`produce design solutions
`evaluate designs against requirements
`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 [4].
`
`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.
`
`5.2 User evaluation
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`7/21
`
`EX2003
`
`

`

`10/18/2018
`
`
`Two approaches to Bringing Internet Services to WAP Devices
`
`Figure 4 The test set-up
`
`
`
`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.
`
`
`
`Table 1 The test Users of the Business Card Search Service. 1=modest skills, 6=expert.
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`8/21
`
`EX2003
`
`

`

`10/18/2018
`
`
`Two approaches to Bringing Internet Services to WAP Devices
`
`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.
`
`
`
`
`
`Table 2 The test users of the HTML/WML conversion. 1=modest skills, 6=expert.
`
`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.
`
`5.3 Analysis of the evaluation results
`
`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
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`9/21
`
`EX2003
`
`

`

`Two approaches to Bringing Internet Services to WAP Devices
`10/18/2018
`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.
`
`
`6. EVALUATION RESULTS
`
`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.
`
`6.1 Platform-related results
`
`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.
`
`6.2 Scrolling
`
`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.
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`10/21
`
`EX2003
`
`

`

`10/18/2018
`
`
`Two approaches to Bringing Internet Services to WAP Devices
`
`Figure 5 Scrolling the search 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.
`
`6.3 Navigation
`
`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
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`11/21
`
`EX2003
`
`

`

`Two approaches to Bringing Internet Services to WAP Devices
`10/18/2018
`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.
`
`6.4 Forms
`
`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.
`
`
`
`
`
`Figure 6 Filling in a form in the UP simulator
`
`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.
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`12/21
`
`EX2003
`
`

`

`10/18/2018
`
`
`Two approaches to Bringing Internet Services to WAP Devices
`
`Figure 7 Filling in a form in the Nokia simulator
`
`
`
`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.
`
`6.5 Business Card Search Service related results
`
`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 don’t 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.
`
`
`
`
`
`Figure 8 Search results with links to business cards
`
`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.
`
`http://wwwconference.org/www9/w9cdrom/228/228.html
`
`13/21
`
`EX2003
`
`

`

`Two approaches to Bringing Internet Services to WAP Devices
`10/18/2018
`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 person’s business card has changed.
`
`6.6 HTML/WML conversion related results
`
`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.
`
`
`
`
`
`Figure 9 Conversion of a frame set
`
`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 se