User interface

---

Approach

What information would be needed from the user, and what information would be returned to the user as the answer?

Input information

Many different types of information were considered, but postcodes were eventually chosen because:-

• they are unique (unlike street names)
• they are international (many countries use them)
• they are small
• they are widely known (unlike map references)

The next part proved to be more interesting…

Output information

The obvious question was should it be graphics based or not? Most devices used to help people get from A to B are graphical in nature, (the map being a prime example), because graphics are relatively easy to understand ( "->" is more obvious than "go right" or "allez aux droite", for example) and aren’t language-specific. Problem is, graphics are storage-intensive and mobiles have very little storage space, so a graphical output would run out of space very quickly. Because of this it became obvious that the output information should be text based. Happily, this decision made the software much faster because it’s quicker to handle text than graphics.

So postcodes were chosen for the input information and text was chosen as the output information. What implications did that have for the user interface?

Interface design

First, a bit of detail. WML sites are divided into "decks", much as HTML sites are divided into "pages", but each "deck" is divided into "cards", and the browser screen displays one card at a time. From a quick bit of back-of-the-envelope thinking, it was thought that 4 lines (with 16 characters per line) would fit nicely on a screen. So the first-draft interface design looked something like this:-

First-draft interface design

• Input:

• Reply: "n"th card

Then this design was checked to see if it would actually fit a range of phones in the real world…

Testing the design in the real world

Information on 30 Wap mobile phones was gathered via phone (see appendix 5 for more details), email, friends and the Web, and was then collated (see appendix 6 for more details). As this continued, it became obvious that there were several bottlenecks that would have to be negotiated.

Bottleneck: Screen size and variable font width

Mobile phones don’t use monotype fonts – the width of a character depends on which character it is, ie "I" takes up less space than "W". That meant that the number of characters that can fit on a line depends on which character it is: a postcode of IJ11 1IJ would take up far less space than WC8W 8XX. The postcode issue wasn’t really a problem, but it did have implications for the reply – specifically, it would have to be assumed that each letter in the reply was the maximum character width. That meant that the maximum number of characters per line shrank dramatically – 12, 11 or even 10 characters in the worst cases. Building a standard card layout in these circumstances was impossible. How could this bottleneck be negotiated?

Getting around the screen size and variable font width bottleneck.

The short answer to this is: there is no solution. The multiplicity of screen sizes and font sizes means that you can’t realistically tailor a card to fit all screens. So this problem was solved by ignoring it – the user interface was built as one giant card. Just as a HTML browser allows you to scroll if the page is too big, a WML browser will allow you to scroll if the card is too big. So this wasn’t really a problem at all. On to the next one….

Bottleneck: Maximum deck size.

Currently, mobile phones transfer data at a low rate of speed, which means that accessing large Wap sites involves a prohibitively large download time. Consequently, manufacturers impose a maximum deck size on their phones as a work-around. Now, of the 30 phones surveyed, maximum deck details were available for 9, and if the Nokia Communicator range (which are effectively PDAs with atypically good specs) were discarded, that left just 7 phones. Those seven had maximum deck sizes ranging between 1.3 and 2.8Kb, so 1.3Kb was taken as the maximum. How big was that? Well, if you consider a typical line in the reply, say "Go from Bristol to Swindon on the M4 for 20 minutes then", then that’s 56bytes. Call it 64bytes for good measure. So, 1.3Kb divided by 64bytes = approx 20 lines. 20 lines was too small. How could this bottleneck be negotiated?

Getting around the maximum deck size bottleneck

20 lines was too short for a reply. But only 20 lines could be sent down at a time. How to cope? Phrased that way, it was obvious: the reply would have to be chopped up into 20-line chunks, each chunk would be sent down as one deck, and links to the next chunk would be inserted at the bottom. That had implications for parsing, but that’d work. So, on to the next problem…

Bottleneck: Maximum cache size.

Each mobile phone had a limited amount of storage. Of the 30 phones surveyed, cache details were available for 8, and (again) leaving out the Communicator range bought it down to 6. These six had maximum cache sizes ranging from 40 to 50Kb, so 40Kb was taken as the maximum. That’s equivalent to 30 decks or 600 lines, and that was more than enough room for a reply.

Getting around the maximum cache size bottleneck

Thankfully, that bottleneck was wide enough to cope and any reply requiring more than 600 lines was outside the scope of this thesis. However it should be noted that the technique of inserting links at the bottom of each chunk rendered this problem moot: one just links to the next chunk and the incoming chunk displaces the oldest chunk. So, that problem was solved, and it was the last one.

Consequently, the second-draft interface design looked like this:-

Second-draft interface design

• Input

• Reply:

- and that design was the one that was adopted.