In the previous chapters, we have looked at the foundations of the technology:

(1)

Building a Mobile Information Site:

By Example

201

C H A P T E R

5

I

n the previous chapters, we have looked at the foundations of the tech-nology: how information gets to your mobile device, where it comes from, and how it should be formatted to work properly. Now, we’ll take a look at how to build a mobile information site.

In this chapter, I try to illustrate how to do the things I have been discussing in the previous chapters: creating a presentation that works on a mobile device as well as in a regular Web browser from a source file in a generic XML format—or XHTML. These examples are pretty simple as mobile appli-cations go, but the intention is really more to give you a feeling for what the medium allows, not so much to deliver a set of ready-made designs. I also try to apply the analysis method I outlined in Chapter 2, “Designing Mobile Information,” but as long as we are working only with information browsing, there is not really very much to be discovered and analyzed in terms of tasks and goals.

A formal method would be more relevant for software development, but this is an exercise in information design. In contrast to graphic design, where it is often cheaper to develop in an informal setting, we do employ some formal concepts in our design.

The wireless user interface part consists, as you can probably guess at this stage of the book, of a WAP stack of cards. All the applications presented here are basically database applications, but I use a file structure expressed in

(2)

XML to demonstrate how they are organized. Mind you, for reasons of clarity, my structure may not be the most efficient. In addition, the limitations of the wireless medium are far too great to enable anything but a text-based narrative.

Developing Services for Mobile Users

Developing services for mobile users is much more like developing an appli-cation than setting up a Web service (which conceptually is much more similar to writing a magazine article, or a paper). It is also much more complicated to develop WAP applications than to write an HTML page. There are functions you should take into account, like variables and the history mechanisms. In addition, the fact that a WAP application is XML means that you cannot afford any of the fudging errors you can in HTML: You must nest all the tags properly and make sure the cards have the proper set of parameters with correct attributes.

In this chapter, I will be using the Ericsson SDK to develop WML pages and illustrate how they will look on different devices. I will not go into the server-side development or the database development. I will assume that the XML files appeared magically out of thin air.

Examples: XSLT and WML

Let’s start by looking at some existing pages and exploring what would happen if you used XSLT to transform them into WML.

My Home Page

Let’s, for instance, start with my home page. I’ve edited it for length; otherwise, it would take several pages in this book. It is now very short, as Web pages go:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML>

<HEAD>

<TITLE>Who is this guy? A presentation of Johan Hjelm.</TITLE> </HEAD>

Who is Johan Hjelm? </CENTER>

(3)

An Army captain with twelve years of experience in Swedish journalism, I am now a visiting researcher at <A

HREF="http://web.mit.edu">MIT</A>, with the <A

HREF="http://www.w3.org">World Wide Web Consortium</A>. I am financed

by the very nice company <A

HREF="http://www.ericsson.com">Ericsson</A>.

My career on the web started in 1994, which makes me roughly the same age in Internet years as in physical years, since there are seven Internet years to a man-year. I fell in love with Mosaic, and immediately realized that I had to be there - this was the future happening beneath my feet.

So I quit a comfortable job as the editor in chief of a small magazine, and decided to invest my time in web development. Unfortunately, me and the financier didn’t agree (he later went broke, so I was right), but meanwhile, I had written the first book about the Internet in Swedish. This landed me a job at Bonnier Affärsinformation, the largest publisher of business

information in Scandinavia, as an Internet technician. You were a god if you could spell TCP/IP in those days.

Some of my talks and publications are:

<TD WIDTH="33%">Presentation

at the EITC 97</A> </TD> <TD WIDTH="33%"><A HREF="Engelska/future.htm">The future

of publishing: A vision</A> </TD> <TD WIDTH="34%"><A

HREF="Engelska/ieprc/IEPRC%20nov%2013.html">Electronic

shopping in Sweden</A>. Talk to the IEPRC.</TD> </TR>

</TABLE> </BODY></HTML>

On the screen of my laptop, the page looks like Figure 5.1.

Even on my laptop, I can display only some 20 to 25 lines of text at a time. Now, as you realize, it is not very interesting to even try to display my Web page on the screen of a mobile device. It is simply too much for something that only has 8 or 12 lines of text. It would look bad even on a handheld computer, such as the Ericsson MC218 (which has a quarter-VGA screen).

(4)

And I have not even used any particularly advanced features! The number of lines on the screen is not more than 12 to 15, depending on resolution. And, of course, the lines are shorter. Figure 5.2 is an example.

Clearly, rendering my home page in its current format on the Psion is a bad idea. Instead, we need to transform this content to WML. An alternative is to apply a style sheet, but the problem with that is that style sheet implementa-tions are not available for handheld devices (there is no stylesheet-compatible browser even for the MC218, and that has a Strongarm processor and 64 MB of RAM—much more than what most mobile phones have). Stylesheets also do not automatically section the content, which you can do when you transform content.

To format the page for mobile viewing, you insert DIV elements (in HTML) or div elements (in XHTML) (note: in HTML you use uppercase, in XHTML lowercase for the element names) into the text, which can be used to parameterize it as WML cards, as we described in Chapter 3, “Optimizing the Web for Mobile Access.” This parameterization can be done when you convert your pages to XHTML, for instance. As HTML browsers ignore the unknown tags, your content will appear as HTML on your screen. Here is what my HTML page would look like with DIV elements inserted:

(5)

!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML>

<HEAD>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (Win95; I)

[Netscape]">

<TITLE>Who is this guy? A presentation of Johan Hjelm.</TITLE> </HEAD>

Who is Johan Hjelm? </CENTER>

An Army captain with twelve years of experience in Swedish journalism, I am now a visiting researcher at <A

HREF="http://web.mit.edu">MIT</A>, with the <A

HREF="http://www.w3.org">World Wide Web Consortium</A>. I am financed

by the very nice company <A

HREF="http://www.ericsson.com">Ericsson</A>.</DIV> <DIV id="card2" class="wmlcard" title=" Me and the web">

My career on the web started in 1994, which makes me roughly the same age in Internet years as in physical years, since there are seven Internet years to a man-year. I fell in love with Mosaic, and immediately realized that I had to be there - this was the future happening beneath my feet.<DIV>

So I quit a comfortable job as the editor in chief of a small magazine and decided to invest my time in web development. Unfortunately, me and the financier didn’t agree (he later went broke, so I was right), but

Figure 5.2 My home page (in the abbreviated version) rendered on a Psion 5 simulator,

(6)

meanwhile, I had written the first book about the Internet in Swedish. This landed me a job at Bonnier Affärsinformation, the largest publisher of business

</DIV>

<DIV id="card4" class="wmlcard" title="Talks and publications"> Some of my talks and publications are:

<TD WIDTH="33%"><A HREF="Engelska/eitc/EITC-1.html">Presentation

at the EITC 97</A> </TD> <TD WIDTH="33%"><A HREF="Engelska/future.htm">The future

of publishing: A vision</A> </TD> <TD WIDTH="34%"><A

HREF="Engelska/ieprc/IEPRC%20nov%2013.html">Electronic

shopping in Sweden</A>. Talk to the IEPRC.</TD> </TR>

</TABLE></DIV> </BODY></HTML>

The parameters on the DIV elements can be used as input to a script that is reworking the page, or they can be used by an XSLT stylesheet that trans-forms the page. If you are using a script to rework your pages, it can be extensively parameterized by the DIV parameters.

Now, Let’s look at how the text would look as WML.

<?xml version="1.0"?>

<!DOCTYPE WML PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

An Army captain with twelve years of experience in Swedish journalism, I am now a visiting researcher at MIT, with the World Wide Web Consortium. I am financed by the very nice company Ericsson.

</card>

(7)

</do>

My career on the Web started in 1994, which makes me roughly the same age in Internet years as in physical years, since there are seven Internet years to a man-year. I fell in love with Mosaic, and immediately realized that I had to be there—this was the future happening beneath my feet.

</card>

So I quit a comfortable job as the editor in chief of a small magazine and decided to invest my time in Web development. Unfortunately, the financier and I didn’t agree (he later went broke, so I was right), but meanwhile, I had written the first book about the Internet in Swedish. This landed me a job at Bonnier Affarsinformation, the largest publisher of business

</card>

Some of my talks and publications are: <table columns="3">

<tr><td><a href="Engelska/eitc/EITC-1.html"> Presentation at the EITC 97</a></td><td><a href="Engelska/future.htm"> The future of publishing: A vision </a></td><td><a href=" Engelska/ieprc/IEPRC%20nov%2013.html"> Electronic shopping in Sweden</a></td></tr>

</table> </card> </wml>

Now, as you can see in Figure 5.3, there is already far too much text to fit on a cellphone screen. All that chatter about what a nice person I am evidently is not very impressive to a mobile user. The table comes through rather well, but the texts are too long, too. They should have been columns instead of rows. Repurposing content is obviously not the solution for creating mobile information services because the content that is repurposed is mostly long text pages. In reality, the generic WML applications will be another aspect of the content presented and retrieved using HTML forms.

Now, if you had to redo all your pages for use in WML, there would not be much scope for WAP. Companies are already complaining about the expense

(8)

of providing multiple versions of the information. But you don’t have to. Using a database-backed publishing system, you can generate the WML code straight out of the database system, for instance, by using a class library such as JAFFA from Ericsson, a Java library to generate WML. Another solution is to have your information in XML and transform it out into the different formats that you are going to use using XSLT.

The advantage of using XSLT is that you can use it not only for transforma-tions, but also for filtering of information. The rules in the style sheet can be used to move the tags, and the content they enclose, around in the document. This filtering option means that in a document such as my page, you can use the rules to move the table card to be the top card. Users who are not inter-ested in all the text can select the information they were looking for right away. In fact, it is probably a good idea to put the text outside the table alto-gether—it does not add much to the experience of the mobile user, after all. A problem with converting existing sites for mobile users is that you cannot transform a document from HTML to an XML format. For one, there are too many broken HTML pages out there (a lot of people don’t bother to validate their HTML, even though there are simple-to-use validators, such as the one on the W3C site, available). For another, HTML is not really a structured information format. You have to convert the document into XHTML if you do not want to use another XML format. My home page would look like the following example in XHTML:

<?xml version='1.0'?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

Figure 5.3 The first card of the preceding WML file. As you can see, the screen is too

(9)

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">

Who is this guy? A presentation of Johan Hjelm. </title>

href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" type="text/css" media="screen" ?><?xml-stylesheet

href="xhtml.css" type="text/css" media="screen" ?>

<body>

<h1 align="center">Who is Johan Hjelm?</h1>

An Army captain with twelve years of experience in Swedish journalism, I am now a visiting researcher at <a

href="http://web.mit.edu">MIT</a>, with the <a

href="http://www.w3.org">World Wide Web Consortium</a>. I am financed

by the very nice company <a

href="http://www.ericsson.com">Ericsson.</a></div> <div id="card2" class="wmlcard" title=" Me and the web">

My career on the web started in 1994, which makes me roughly the same age in Internet years as in physical years, since there are seven Internet years to a man-year. I fell in love with Mosaic, and immediately realized that I had to be there - this was the future happening beneath my feet.</div>

So I quit a comfortable job as the editor in chief of a small magazine and decided to invest my time in web development. Unfortunately, me and the financier didn’t agree (he later went broke, so I was right), but meanwhile, I had written the first book about the Internet in Swedish. This landed me a job at Bonnier <quote

xml:lang="se">Affärsinformation</quote>, the largest publisher of business

information in Scandinavia, as an Internet technician. You were a god if you could spell TCP/IP in those days.</div>

<div id="card4" class="wmlcard" title="Talks and publications"> <h2>Some of my talks and publications are:</h2>

(10)

href="Engelska/eitc/EITC-1.html">Presentation

at the EITC 97</a></td>

<td width="33%"><a href="Engelska/future.htm">The future of publishing: A vision</a></td>

<td width="33%"><a

href="Engelska/ieprc/IEPRC%20nov%2013.html">Electronic shopping in Sweden</a>. Talk to the IEPRC.</td> </tr>

</table></div> </body></html>

As you can see, the XHTML page does not look very different from the HTML page at all. Try bringing it up in an ordinary HTML browser, and it will just show you a normal HTML page. It appears in exactly the same way because an HTML browser will ignore the tags it does not recognize, such as the end tags. Simple as that may sound, there is a lot more compromise to writing workable XHTML. For one, the markup now has to be XML. This requirement means that tags must nest properly, that you cannot use certain variable names, and so on. On the other hand, XML brings you a wealth of possibilities.

By the way, WML is supposed to be so much more efficient in the over-the-air transmission. Let’s see: The WML deck in the preceding example is 1825 characters long, of which 119 are overhead. The Web page is 2274 characters, of which 161 are overhead. If we were to transmit this as SMS messages and assuming that we can receive one SMS message per second, knowing that the SMS messages are 56 characters long gives us 32 seconds transmission time for the WAP deck and 40 seconds for the HTML page. And users get tired of waiting after 3 seconds. Oh, well.

But this transmission scenario is not the entire story. The WAP gateway collapses the markup using tokenization, so each markup tag becomes just four characters long. As a comparison, the WML deck became just 1428 bytes when I compiled it. This size reduction represents a decrease in size of 22 percent. It also means that it would take just 26 seconds, instead of 32, to transmit over the air. Of course, with a file this large, it is difficult to notice a difference of 19 percent. If the file had been 280 characters long and the trans-mission time had been 5 seconds, it would have shaved off almost 1 second. When the proportion is that large, it is large enough for you to sit up and notice.

As you can see, it is not easy to create a logical division of a text, even one as simple as my home page. Let’s instead try to apply the method described in Chapter 2. First, we identify the objects in the page; then we look at the actions associated with each object; and finally, we look at how to enable the user to perform those actions when the page is presented as a mobile application.

(11)

There are three objects in my page (and remember, this may be a subjective view): the first introductory paragraph, then the two following paragraphs, describing me, and finally, the table, which is a compound object consisting of several hyperlink objects.

The objects do not really have very much in the way of tasks associated with them, apart from browsing the text and thinking that I must be a really nice guy (after all, this is not a banking application). The first object has the task of following links; the second object no task; the third again the task of

following links. The attributes to these tasks are the links themselves.

An alternative way of organizing a deck of WML cards would therefore be to create two or maybe three cards: the first with the links in the first object, the second with the links in the third object. If a third card were available, it would be an introductory card, at least if I was designing the application. Now, moving on from my relatively simple page, let’s take a look at some other examples.

Train, Bus, or Flight Time Tables

In many ways, transit schedules are a no-brainer for a transactional applica-tion. When is the next bus? Which train should I take? Is the flight late? Can you think of any question (save probably “what time is it?” or “how much money do I have in my bank account?”) that will generate less of a narrative in response? One of the first Web pages was the Caltrain time table. Well, what if you could access it from your mobile phone? The same principles could also be used to design a mobile flight information system. In both cases, there is a mission control that has a real-time update of the information and feeds it to text-based monitors in stations and airport terminals. This feed is easy to tap into a database or Web page, or even an XML page. From there, it can be retrieved as a WML deck. Although there is only one source for the information, there are considerable problems with the navigation through it. While a bus timetable is fairly easy to navigate (the reason we start with the bus), flight information requires a number of additional navi-gational steps.

For a flight information service, the navigational steps would look much the same. You can also get to your destination, though, in other ways. If your ticket allows, you can change flights. You will want to know if the flight is late or cancelled. Your flight has a unique booking reference, which the airline could use as a URI for your trip. For security reasons, your ticket code could be linked to the frequent flyer program and a personal code. If my flight is delayed, being able to check when it is due to leave is very helpful, especially if I am at the same time able to book another flight.

(12)

The bus schedule application uses a Perl script (included with the Ericsson development environment) that reads from a structured text file (an XML file is nothing but a structured text file, anyway). As I mentioned before, there are several ways of identifying the objects, depending on the use cases. You may want to find the next bus in some direction, in which case the object your query applies to is the time. If you want to find a bus in a certain direction, the query applies to the route of the buses (the direction is a property of the route, as it relates to where you are—if you are at the end station of the bus route, the route can have only one direction).

This bus application assumes that you are querying for either the line or the area, both of which are static. It would be possible to query for the next bus, but that would require more computation, determining what time it is and relating that to the time the next bus will pass.

First, let’s look at the simple text file that contains the areas and the bus lines. It is quite possible to express this as an XML file instead.

areas:3 Solna lines:2 511 156 Huddinge lines:2 703 173 Sollentuna lines:1 520

The example shows a very simple file, containing the area and bus lines that serve it (the areas are suburbs of Stockholm, Sweden, by the way).

Following is what the file looks like with the times and route for line 511 (there must be files for lines 156, 703, 173, and 520 too, of course):

directions:2 Akalla-Brommaplan tables:2 Monday-Friday stops:6 Akalla

Kista arb.omr. (Torshamnsg.) Kista (Torsnäsg.)

Kista centrum Rissne

Brommaplan rows:23

(13)

6.10—-6.15 6.24 6.40 25—-30 39 55 40—-46 56 7.14 55—-7.01 7.11 29 7.10—-16 26 44 25—-31 41 8.01 40—-46 56 16 57—-8.03 8.13 33 8.12—-18 28 48 27—-33 43 9.03 42—-47 56 12 15.00 15.08 15.12—15.21 15.39 20 28 32—41 59 40 48 52—16.01 16.21 55 16.03 16.07—16 38 16.10 18 22—31 53 25 33 37—46 17.09 40 48 52—17.01 28 55 17.03 17.07—16 42 17.10 18 22—31 55 25 33 37—45 18.08 40 48 52—18.00 20 55 18.03 18.07—15 33 Saturday, Sunday stops:0 rows:0 Brommaplan-Akalla tables:2 Monday-Friday stops:6 Brommaplan Rissne Kista centrum Kista (Torsnäsg.) Kista arb.omr.(Torshamnsg.) Akalla rows:22 6.00 6.11—6.19—6.33 15 26—34—49 30 43—51—7.06 45 58—7.06—21 7.00 7.15—23—38 15 30—38—55 30 45—53—8.11 45 8.00—8.08—27 8.00 15—23—39 15 30—38—53 30 45—53—9.08 45 58—9.06—21 14.45 15.00 15.09—-15.17 15.15 30 39—-47

(14)

30 45 55—-16.04 45 16.01 16.11—-20 16.00 16 26—-35 15 31 41—-50 30 46 56—-17.05 45 17.01 17.11—-20 17.00 16 25—-33 15 30 39—-47 Saturday, Sunday stops:0

The user interface is structured to allow the user to select a menu choice: Which area the user is in, and for which line he or she wants to see the times, are shown in Figure 5.4.

The WML markup is structured as four different cards: first, a welcoming card (that will automatically be switched over to the next card because it has a timer value set); then a menu card, where you can select between line and area (if you select the “area” choice, the sl_area.pl script is started, but if you select the “line” choice, you automatically go to the next card); a card that lets you select the line you want to take (note that the variable “line_no” is set by the user’s input, and then, when the user accepts, the system moves to the script that retrieves the times for the bus line, which will use the variable value as its parameter); and finally, a terminating card, which will take you back to the original start menu. This sequence is shown in the example that follows.

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

Figure 5.4 The user can select between the areas to find out which lines serve that area

(15)

"http://www.wapforum.org/DTD/wml_1.1.xml"> <wml>

<big> </big><img width="10" hspace="1" src="/cgi-bin/mllib/demo/bus.gif" height="20" vspace="1" align="middle" alt="Bus Timetable"/> Timetable Schedule </card>

<card id="menu" newcontext="true"> <do type="accept"> <go href="$(choice:N)"/> </do> <do type="prev"> <go href="#intro"/> </do> Choose Service <select name="choice"> <option onpick="/cgi-bin/wmllib/demo/sl_area.pl">Area</option> <option onpick="#line">Line</option> </select> </card>

<card id="line" newcontext="true"> <do type="prev"> <go href="#menu"/> </do> <do type="accept"> <go href="/cgi-bin/wmllib/demo/sl_line.pl?SLFile=$line_no"/> </do> Enter line number:

(16)

maxlength="3"/> </card>

Do you wish to search again?

</card> </wml>

This application uses two Perl scripts to retrieve the information from the file and generate the WML that the user will see, presenting the result. The scripts use the WMLlib library of functions that come on the CD to generate the WML elements. It first looks up the available areas in the area file and generates a menu from which the user can choose. Based on the user’s choice, it then generates a list of the lines from which the user can select in that area; when selecting and presenting the line and the line times, the line script is used.

The following example shows what the area script looks like:

#!/usr/local/bin/perl

#************************************************************* # Script creates a WML deck for the SL area service, it # uses "wmllib.pl" library of functions.

# It reads a formatted file to get the area names and line # numbers as well as the number of areas and lines. When # line number is selected, the line service script is called. #

# File: sl_area.pl

# Author: Michelle Kneisel # Date: 1998/11/25

# Updated to wml 1.1 by Olof Bendt # Date: 990706 #************************************************************* require 'wmllib.pl'; require 'config.pl'; require 'slutils.pl'; $deck = &WMLTop;

(17)

%areaName = ("id", "areaChoice"); #card name

#my $body_areaChoice = &Do("accept", &Go("\$(area:N)")); $body_areaChoice .= &Do("prev", &Go($HTML_PATH.

"sl_time.wml#menu"));

$body_areaChoice .= &P("Choose Area:".&Br); %areaSelAtt = ("name", "area");

($name, $areas) = split(/:/, <FILE>, 2); #reads file, gets number for, loop

for ($ar = 0; $ar < $areas; $ar++) { #number of areas

$area[$ar] = <FILE>; chop $area[$ar];

%areaOptAtt = ("onpick", "#area".$ar);

$options .= &Option($area[$ar], \%areaOptAtt); #creates array of cards for lines

%lineName = ("id", "area" . $ar); #$body_lineChoice[$ar] = &Do("accept", &Go("\$(line:N)"));

$body_lineChoice[$ar] .= &Do("prev", &Go($HTML_PATH. "sl_time.wml#menu"));

$body_lineChoice[$ar] .= &P("Choose line:".&Br);

%lineSelAtt = ("name", "line");

($name, $lines) = split(/:/, <FILE>, 2); $lineOptions .= "";

for ($li = 0; $li < $lines; $li) { $line[$ar][$li] = <FILE>; chop $line[$ar][$li];

#creates options that call line service script with appropriate parameters %lineOptAtt = ("onpick", $CGI_PATH."sl_line.pl?SLFile=".$line[$ar][$li]); $lineOptions .= &Option($line[$ar][$li], \%lineOptAtt); } $body_lineChoice[$ar] .= &P(&Select($lineOptions, \%lineSelAtt));

$deckLine .= &Card($body_lineChoice[$ar], \%lineName); #temp 'deck'

}

$body_areaChoice .= &P(&Select($options, \%areaSelAtt)); $deck .= &Card($body_areaChoice, \%areaName);

$deck .= $deckLine; } else {

$deck .= displayDeck("Cannot open file", $HTML_PATH . "sl_time.wml#intro");

(18)

$deck .= &WMLBottom; print $deck;

1;

This example application generates WML from a plain-text file. It could generate HTML as well. The text file is now the source from which original content is generated. The document that is presented to the user is only one of its representations.

The Perl script assumes that the information is structured by being ordered, and the elements are separated by the line breaks. It would work as well if the element separators were XML markup. Remember, there is no central XML registry. Anyone can construct an XML application by placing the DTD on his or her Web site, provided there is a globally unique namespace for the application (which means that you cannot have several different XML appli-cations with the same URI—but if you have a server, and place them in different (logical) directories, you can create as many as you want). If the base format were XML, it would be possible to generate the WML content using an XSLT transformation sheet. You would then have to decide which WML cards should go into the deck before the transformation sheet was written. Whether you choose to use a Perl script or an XSLT transforma-tion does not really matter; what matters is that the presentatransforma-tion is based on a generic representation that is then transformed into the different formats when it is presented to the user. At the current stage of XSLT, it is probably better to write something in PERL, but as commercial-grade XSLT transfor-mation engines become available, you will most likely want to switch to XSLT. It is easier to write a transformation sheet than a Perl script.

Home Town Sports

In the United States, sports results are highly formalized, and sports sites have become big on the Internet. This sporting fascination is not shared in any other place in the world, even where gambling on sports is legal. American players (the focus is almost always on the individual players, not the teams) are surrounded by a number of statistics describing their performance. The statistical information makes them a good example of my earlier thesis: Each player is an object, which has a series of properties that are expressed in statements concerning that player. For instance, the soccer player Ernesto Guttirez may have scored twice during the season (once during the last game), made five assists (two during the last game), been offside eight times (two during the last four games), and so on. He may also be five foot eight inches tall, have brown eyes and curly black hair, sport a mustache, have a wife and five kids, and live in Andover, Massachusetts. All these things assist in describing him, although some may be irrelevant to his performance as a soccer player.

(19)

Now, if we had wanted to describe the last game instead, we would describe all the goals, assists, offsides, and other things that were relevant to the game, down to the movement of the individual players if we were real fanatics. Then, the game becomes the object of the description, and Ernesto Guttirez one of 25 parameters of that object (each team has eleven players, and there are one referee and two linemen as well).

Professional soccer has yet to make it in America (probably because the sport is too much fun to make a serious business), but as an activity for children and as an exercise activity, it has really taken off. Let’s look at a junior league and try to make their information mobile-adapted (this example is entirely fictitious, by the way, and does not relate to any real Massachusetts soccer players). The Junior Girls Soccer League of Massachusetts already has a Web page where the results of the games are reported. The update of the page is done on Mondays, even though the games are normally played on Sunday afternoon. The clerk of the league does not work on Sundays.

Each game is monitored by a secretary (apart from the linemen and referee), who records not only which team scored goals, but also who scored, who assisted, who got a punishment or a warning, and all the other events that relate to the game. The secretary fills in the results on a set of forms, which he or she faxes to the league. Because very few of the secretaries (all volunteers) have faxes at home, they typically do this when they get to work on Monday. Of course, sometimes they forget, and sometimes they are sick. This means that the Web page does not get updated until Tuesday at the earliest because the clerk has to call the secretary when the form is missing and find out where it is. This information delay is a pain for the editor of the local newspaper. The soccer scores are one of the main attractions for his readers, and he wants to include them in his paper—but it is impossible to get them in the Monday edition, and he is sometimes pulling his hair because the clerk at the soccer league is late for the Wednesday edition. It is also a major aggravation for the grandparents of the players, who like to look the game up before they call their grandchildren and commend their game. Or chide them, as the case may be.

Following is an example of the Soccer League Web page:

<!—Created with AOLpress/2.0—>

<TITLE>Junior Girls Soccer League of Massachusetts</TITLE> </HEAD>

<H1 ALIGN=Center>Junior Girls Soccer League of Massachusetts</H1>

(20)

<H2>Result for the games of June 4, 2000</H2> <H2>Springfield Sprockets—Andover Angels</H2> Location: Andover Park

<H3>Goals:</H3> Home 2 Score: 4 Juliet Montague 7 Sandra Conrad Visitors 1 Score: 10 Fiona O'Connel Penalties: None Corners: None <HR>

Now, Let’s imagine the application as mobile.

If we try to analyze who will use this application, we find two groups of users: Alan, the match secretary, who was charged with reporting the goals, who scored, punishments, and other statistics. He is a sports teacher at the local high school, who fell in love with soccer when he was stationed in the Air Force in Europe. Previously, he has done his reporting on a form that is sent in to the soccer league secretary; he also sends a carbon copy to the local newspaper. But sometimes he gets the names of the players wrong (after all, he is past 60 and his hearing took a beating in the Air Force). Of course, this causes an uproar among the parents who saw their kids score on the soccer field, but do not see them reported in the paper.

The other group is headed by Mary, the soccer mom. She checks the Web page Monday night to make sure that the results get in there, and she is the one who wants to read in the paper about Eve and Juliet, her 7- and 11-year-old daughters, scoring; it is her only reward for driving them to practice four times a week. Plus, of course, bragging to her neighbors and sending a copy to her parents in Alaska.

Alan obviously needs an input form for the events during the match: who scores, who is out on punishment, who made the pass, and so on. He also needs another form, to feed in the names and numbers of the players and the team configuration. This form could be done by the team captain the night before the match, of course, but team configurations have a tendency to change, and they can also change during the course of the game.

Mary would like to read the result at the game (to make sure Alan got the names right), and on the Web when she gets home, and she wants her

(21)

parents to be able to read them, too. There is also a third category of users here: the local newspaper reporter, who wants to extract the information automatically and put it on the paper’s Web site and in the next day’s paper. While the results could go into a database, the number of local games is not large enough to justify a database management system, especially not the effort of developing one. Alan has a son who is a Perl hacker, and he puts together a set of forms and scripts so the game’s secretaries can use the Web to input the results, instead of having the clerk do it all.

Today, Alan has a sheaf of paper forms in front of him, which he fills in as the match progresses. There is a form to complete regarding the team configuration (before the match) because that is often not decided until just before the game. The team configuration also changes during the games, so he is often frustrated and has to create a new sheet as substitutions and penalties change the team layout. That team configuration information is not used on the Web page, which reports only the most bare-bone facts. Alan also has a form to record who scored, who assisted, and other statistics (during the match); the intent of this form is to record what happens during the game. This game action infor-mation goes onto the Web page, but who scores, assists, or gets a penalty is reported only by the number of the player. The league clerk then needs both forms, team configuration and game action, to update the Web page. The paper method creates lots of information not used by the clerk on Sunday when he updates the Web site using the forms Alan has given him. Alan must also remember to enter the information himself—he can still forget it, not having a computer at home, and he can still misspell names, and get numbers wrong. The forms have only created less work for the league clerk; they have not solved the problem of reporting from the field.

Because the application to receive the information now exists, Alan can get a WAP phone with a set of forms that allow him to enter the information. Because WAP addresses the scripts using URIs, the information can go into the same forms irrespective of the input method. It also means that the input and the output will be using the same data formats. This data format consis-tency does not matter so much in English text, but in other languages where umlauts are used, it could cause confusion for older Web browsers if the character ä was not represented as ä, for instance. The encoding is probably still UTF-8.

The WAP forms create another problem, however: The team configuration is very difficult to input on a WAP device. For one, 11 players is a lot on a device with only 6 lines of text. Second, it is difficult and takes time to type the names of the players using the keypad of the phone. One solution is to delegate the work to the team captains, who are responsible for the teams anyway; if they are to key in the names and numbers of the players and

(22)

which positions they play before the game, the likelihood of all names getting spelled right is much higher. Alan can then get a form to change the team configuration, if necessary.

One more thing needs to be done: Instead of HTML, the file needs to be in XHTML. While it does not matter to the Perl script that stores the results in the file, using XHTML means the data can be transformed to WML using standard transformation sheets. It also means that it is the elements that structure the information, not the order in the file. If Alan misses something, the transformation will still work, as long as the source file is well formed. Because the results are reported in real time, Mary can then keep track of the progress of the game and make sure Alan corrects any errors. Another

advantage is that the newspaper can retrieve the file and use it as direct input into its printing system, which uses an XML-based application, after trans-forming it using XSLT. This new method will mean that the results can actually get into the Monday newspaper, and the editor is now breathing a big sigh of relief.

The XHTML file is updated with Alan’s input as the match progresses (looking back at the object structure, it is the soccer match that is the object, and the properties of that object are the home and visitor teams, the goals, penalties, corners, and everything else that happens during the game). The application that Alan is using is a set of input fields that post information to a URL—just as it would work if he had been using a Web page to give the same input. The WML code for the page looks like the following example:

"http://www.wapforum.org/DTD/wml_1.1.xml"> <wml>

<card id="menu" newcontext="true"> <do type="accept"> <go href="$(choice:N)"/> </do> Select Option <select name="choice">

<option onpick="#home_goal">Home Goal</option> <option onpick="#visitor_goal">Visitor Goal</option> <option onpick="#home_penalty">Home Penalty</option> <option onpick="#visitor_penalty">Visitor

Penalty</option>

<option onpick="#home_corner">Home Corner</option> <option onpick="#visitor_corner">Visitor

(23)

</select> </card>

<card id="home_goal" newcontext="true"> <do type="prev"> <go href="#menu"/> </do> <do type="accept"> <go href="/cgi-bin/wmllib/demo/home_goal.pl?Scored_by=$scored_by"/> </do> Enter player number:

</card>

<card id="visitor_goal" newcontext="true"> <do type="prev"> <go href="#menu"/> </do> <do type="accept"> <go href="/cgi-bin/wmllib/demo/visitor_goal.pl?Scored_by=$scored_by"/> </do> Enter player number:

</card>

<card id="home_penalty" newcontext="true"> <do type="prev"> <go href="#menu"/> </do> <do type="accept"> <go href="/cgi-bin/wmllib/demo/home_penalty.pl?Scored_by=$scored_by"/> </do> Enter player number:

</card>

(24)

<card id="visitor_penalty" newcontext="true"> <do type="prev"> <go href="#menu"/> </do> <do type="accept"> <go href="/cgi-bin/wmllib/demo/ visitor_penalty.pl?Scored_by=$scored_by"/> </do> Enter player number:

</card>

<card id="home_corner" newcontext="true"> <do type="prev"> <go href="#menu"/> </do> <do type="accept"> <go href="/cgi-bin/wmllib/demo/home_corner.pl?Scored_by=$scored_by"/> </do> Enter player number:

</card>

<card id="visitor_corner" newcontext="true"> <do type="prev"> <go href="#menu"/> </do> <do type="accept"> <go href="/cgi-bin/wmllib/demo/ visitor_corner.pl?Scored_by=$scored_by"/> </do> Enter player number:

</card>

(25)

Back to the menu

</card> </wml>

On a mobile phone, the application would appear as in Figure 5.5.

Obviously, the soccer form was an extremely simple application, but you don’t want it to be too complicated. After all, Alan must input the information while the match is going on (even if there is a short break when one team scores), so you don’t want to make it too complicated, structuring the menus in such a way that the information will not be more than “three clicks and three seconds away,” if you remember the Reuters slogan. Players’ names do not have to be very long to complicate using the telephone keypad, so it is easier to fill them in separately and just give the number of the player who scores.

(26)

As you can see if you are an experienced developer, an alternative solution to using a dedicated XML format is to use a database front end, with variable substitution serving to fill in the data. To do this, you create a series of

templates, which the user calls up by putting in a URI, and then the variables are substituted into the document to change the values. This variable substi-tution solution will also mean that you need to have a concept of session because the names of the players will change with each game. In principle, the information can be stored in one table, with the teams and the statistics for each player with the player number as a key.

Now, looking at the tasks that the user must perform, the variable substitu-tion solusubstitu-tion is also pretty simplistic. In the soccer applicasubstitu-tion, it consists of selecting which option the user wants to choose and keying in the number of the player who scored (or who kicked the penalty). If there had been more statistics, we would probably have wanted to add another level of menus, collecting the events in groups (for instance, penalties, free kicks, and corners in one group) and to create an application that could accept more variables than one.

State Lottery Numbers

Now, let’s look at a simple application—the winning lottery numbers in the state lottery. This is a typical application where everybody wants to know if they are the winner, and they really care about only the highest wins. We might also make it possible to show the result file on a mobile phone. The state lottery mainframes generate an intermediary format for transfor-mation onto the Web and other display formats. This document is in an intentional intermediary format, for demonstration purposes (actually, I have borrowed it from the XSLT specification). A transformation sheet can be used to create an XHTML file, as well as a WML file.

The DTD for this file is very simple:

<!ELEMENT doc (section*)>

<!ELEMENT section (title,(para|note)*)> <!ELEMENT title (#PCDATA|emph)*>

<!ELEMENT para (#PCDATA|emph)*> <!ELEMENT note (#PCDATA|emph)*> <!ELEMENT emph (#PCDATA|emph)*>

And the following document is an XML document that follows that DTD:

<?xml version='1.0'?>

<?xml:stylesheet type="text/xsl" href="wap-style.xsl"?> <!DOCTYPE doc SYSTEM "results.dtd">

(27)

<title>State Lottery Numbers</title>

<para><emph>Draw of June 4, 2000</emph></para> <para><emph>Grand Prize Winner</emph></para> <para>2389104765</para>

<note>Prize money is paid out at the central lottery office only. Unless collected before June 4, 2001, the money defaults back to the treasury </note>

</section> <section>

<title>Junior Grand Prize</title> <para>3490215876</para>

<note>Prize money is paid out at the central lottery office <emph>only</emph>. Unless collected before June 4, 2001, the money defaults back to the treasury. </note>

</section> </doc>

This file is relatively easy to divide in two cards or to display on a Web page. It is not really independent of the presentation formats, however. It often helps to use several tools in parallel to design the XML source and the WML and HTML presentations in parallel. In a larger application, with more pres-entation formats, this would become unsustainable. Then, the method of marking up the objects separately and the use of transformation sheets to generate separate presentations make more sense. The transformation sheet for transforming the previous file to XHTML would look like the following example: <?xml version='1.0'?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns="http://www.w3.org/TR/xhtml1/strict"> <xsl:strip-space elements="results"/> <xsl:template match="results"> <html> <head> <title> <xsl:value-of select="title"/> </title> </head> <body> <xsl:apply-templates/> </body> </html> </xsl:template> <xsl:template match="title"> <h1> <xsl:apply-templates/> </h1> </xsl:template>

(28)

<xsl:template match="para"> <xsl:apply-templates/> </xsl:template> <xsl:template match="note"> NOTE: <xsl:apply-templates/> </xsl:template> <xsl:template match="emph"> <xsl:apply-templates/> </xsl:template> </xsl:stylesheet>

The XHTML page would look like the following:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <head>

<title>State Lottery Numbers</title> </head>

<body>

<h1> State Lottery Numbers</h1> <h2> Draw of June 4, 2000</h2> <h3>Grand Prize</h3>

2389104765

<h3>Junior Grand Prize</h3>

This is the other grand prize winner 3490215876

NOTE: Prize money is paid out at the central lottery office only

NOTE: Unless collected before June 4, 2001, the money defaults back to the treasury

</body> </html>

This example looks OK on a regular HTML browser, nothing fancy, as shown in Figure 5.6.

That code worked for XHTML, but the same file can be transformed into WML, using the following transformation sheet:

<?xml version='1.0'?> <xsl:stylesheet

(29)

xmlns="http://www.w3.org/TR/REC-html40" result-ns="">

<xsl:strip-space elements="results section"/> <xsl:output method="xml" indent="yes"/> <xsl:template match="results"> <wml> <xsl:apply-templates/> </wml> </xsl:template> <xsl:template match="section"> <card> <xsl:apply-templates/> </card> </xsl:template> <xsl:template match="section/title"> <xsl:apply-templates/> </xsl:template>

(30)

<xsl:template match="para"> <xsl:apply-templates/> </xsl:template> <xsl:template match="note"> NOTE: <xsl:apply-templates/> </xsl:template> <xsl:template match="emph"> <xsl:apply-templates/> </xsl:template> </xsl:stylesheet>

The transformation sheet would produce the following WML deck as a result:

"http://www.wapforum.org/DTD/wml_1.1.xml"> <!—WapIDE SDK WML Application Sun Jan 02 21:29:54 Singapore Standard Time 2000—>

State Lottery Numbers

Draw of June 4, 2000

Grand Prize Winner

2389104765

NOTE:Prize money is paid out at the central lottery office only. Unless collected before June 4, 2001, the money defaults back to the treasury.

</card> <card>

Junior Grand Prize

3490215876

(31)

NOTE:Prize money is paid out at the central lottery office only. Unless collected before June 4, 2001, the money defaults back to the treasury.

</card> </wml>

On the screen of the mobile telephone, the WML result would look like Figure 5.7.

Now, as you see, the user has to scroll through the page on his or her mobile. While scrolling may work, it would be far better if you could have divided the document into three cards. The division has to be prepared in some way in the original document, and you have to insert attributes on the elements that can be used to section the file into cards. In practice, these requirements mean that you have to be aware of the output format the document will be transformed into when you design the canonical format.

User interaction is where the object analysis comes in. Look at the objects, and think about how the user would interact with them. Here, the interaction

Figure 5.7 The lottery page simply converted to WML means you have to scroll through

(32)

method would be browsing, and the user interaction would be to flip between the cards. According to the WML specification, we are supposed to put one user interaction on each card. The document in the preceding example could be transformed into either one or two WML cards (one winning number on each). Or, you may need three cards, if you want to put the legal stuff at the end.

In any case, you must have something for the transformation sheet to

transform into WML cards—either something akin to the DIV elements in a HTML file or attributes on the elements. Whichever, the transformation sheet has to contain hooks for them and elements to insert. But I think you understand how to insert elements now.

This chapter shows that to create multiple presentations from the same source file, you have to work directly with the objects the file consists of; otherwise, you will have to insert one set of formatting hints for each new presentation you want to create. Working directly with the XML file where the information is marked up as objects and generating the content using XSLT lets you create both WML and HTML.

This is only the beginning, however. The formatting hints may have to be different for all presentations. But what if we had some general information that we could use in the same way to create a presentation that was adapted to the user? Using metadata to create personalized and contextualized presentations is the topic of the next chapter.