Adding Wireless Users To Your Web Serviceby Andrew Grumet (aegrumet@arsdigita.com) Submitted on: 2000-05-01
ArsDigita : ArsDigita Systems Journal : One article
Reaching these users will take more than persuading them to go through
the pain of entering your long URL on their miniaturized keypads. The
central challenge is to build a useful service that is well-suited to
small screens and requires minimal user input. The reward for meeting
these challenges is the opportunity to expand the application space,
providing your users with new types of services previously unavailable
on the Web.
There are a number of standards for development of wireless web
applications, but the momentum in May 2000 is strongly behind
the Wireless Application Protocol (WAP) architecture. This standard
is written and maintained by the WAP Forum (http://www.wapforum.org), an
industry consortium including Phone.com (formerly Unwired Planet),
Nokia, Motorola, Ericsson, and many more. Most Web-enabled cell
phones on the market today support WAP. Alternatives for wireless
application development include the Handheld Device Markup Language, a
predecessor to WAP which is still supported on many cell phones, the
Palm Query Application a.k.a. "Web Clipping" (Palm Pilot
VII), and text-only HTML (Qualcomm pdQ smartphone, NTT DoCoMo i-mode
phone in Japan).
The cell phone connects to your web server through a service
provider's gateway. The gateway translates encoded requests from the
phone to standard HTTP GETs and POSTs, fetches the results, encodes
the results, and returns the results to the phone. Data are passed
between the gateway and cell phone in binary form for compact
transmission, using a WAP-specific set of protocols. The gateway also
manages the relatively unreliable network connection to the phone.
WAP content is delivered in Wireless Markup Language (WML) format.
WML supports a somewhat different set of user interactions than HTML,
and adheres strictly to the XML standard.
To serve WAP devices, the Web server simply needs to return WML with
the appropriate headers and tags:
WML documents are designated by the
The deck in the "Hello, world" example contains just a
single card with a static message. Here is a more elaborate example:
This deck consists of three cards. The first two prompt the user for
input and the third displays the results. Results are passed between
cards using the document-level variables Name and Favorite. Variable
substitution is effected by prefixing variables names with a dollar
sign ($) and enclosing them in parenthesis. Navigation between cards
is handled with
Real development requires a mixture of simulators and phones with
emphasis on the former. The simulators are particularly useful for
exploring navigation and user experience strategies, checking
dynamically generated WML source, refreshing cached pages, and
tracking cookies. Telnet can also come in handy, as exemplified
below.
At the push of a button. The first thing that hits you when working
with WAP phones is the tedium of entering site URLs on numeric
keypads: each letter is entered by pressing the appropriate number key
and then, if necessary, repeating to select one of three or four
letters associated with the key. This point was driven home when an
MIT student asked me to review a WAP page he was working on for the
web applications class I help teach at MIT (http://6916.lcs.mit.edu). The URL
for the page was something akin to
http://lcswww75.lcs.mit.edu/register/wap-login.tcl. Typing this URL on
a Samsung SCH-3500 takes about 85 keystrokes after legally omitting
the "http://", with roughly half of the keystrokes devoted
to "/register/wap-login.tcl" (As an aside, this should teach
you something about the economics of WAP portals.) When I asked the
student why he hadn't provided navigation through a shorter URL, he
said, "Oh, I always used a PC-based simulator so it never occurred to
me."
This situation can be ameliorated by having the top-level index page
try to guess the appropriate document type and redirect the browser
accordingly. Here is the algorithm used for the developer conference site:
At the heart of the conference schedule service lies information about
individual seminars. This information is served dynamically from the
same database tables that are used for the HTML version of the site.
However, the display and user experience constraints are quite
different for desktop web browsers and wireless devices. With long
seminar titles like "Power Development Strategies using Java
Technology, XML, J2EE, and Oracle8i", for example, even a
moderately long list of seminars could make for a great deal of
scrolling on a 12-character wide screen. There are basically two ways
to reduce the need for scrolling. The first approach is to pass all
strings through a function which truncates to an acceptable length,
perhaps truncating preferentially at whitespace. Drill-down
navigation through the conference schedule is handled in this way. A
second approach is to override line-wrapping by using paragraph tags
with the
Building the conference schedule user experience was an exercise in
navigation design: help the user arrive at seminar cards as
efficiently as possible. The conference is a travelling show making
stops in major cities around the world, so we first prompt the user
to choose a city from a short list including the meeting currently in
session and the five upcoming sites. We also present an option to
view a list of all cities including past events. Individual seminars
are organized into a number of themed tracks which run simultaneously
over the course of two days. Having picked a city, the user is given
the choice of locating seminar information by track or by starting
time, followed by a list of tracks or starting times. Upon picking a
particular track or time, the user is presented with a list of
seminars each linking to a card with the seminar name, location, time,
and track.
Since a number of cards can be stacked into one document it is worth
acknowledging that you have some choice in structuring WML documents.
In theory, an entire site could be loaded into a single deck! In
practice, most microbrowsers have document size limit of about
1200-1500 bytes. Furthermore, the publisher may wish to instruct the
browser to selectively not cache some information. Here is the site
structure for wireless users:
As with the conference calendar, the primary task was to put a WAP
front end on existing data. ArsDigita's intranet is, unlike our
software, not open to the public. User login pages were needed to
restrict access. These pages were implemented in a parallel fashion to
the existing HTML pages, calling the same backend scripts but instead
presenting the results in WML. Just like in the ArsDigita Community
System (ACS), cookies are used to identify logged-in users. In my
experience cookies work well provided you do not deviate from the
magic cookie spec (available from http://home.netscape.com/newsref/std/cookie_spec.html).
Notably, avoid using commas, spaces, and semi-colons in the cookie
value. The user's email address on our intranet is also their
username, so to save typing, a default email domain
("@arsdigita.com") is appended if necessary when the user
logs in.
In May 2000, ArsDigita is about 160 people. To look up an individual's
information, I implemented a search tool instead of drill-down
navigation. Searches may be performed on the first few characters of
the user's first name, last name, or email address (by which some of
us are primarily known). The search tool will return a single employee
card if one match was found, a list of employees (linking to employee
cards) if 2-10 matches are found, and a request to narrow the search
if more than ten employees are found.
Thanks to the Web Telephony Application Interface (WTAI) it is a
fairly simple matter to "link to" a phone number, saving the user from
otherwise having to:
The dark side of this scheme: there are a variety of ways to lump
phone number digits depending on what country you happen to live in.
For this reason, the keepers of our Intranet have been content to
store phone numbers as free-form SQL
To summarize, beyond accessibility, the real value of WAP lies in
application frameworks like the WTAI.
In the examples above we created sets of WML pages to serve
essentially the same content as their sister HTML pages, with little
effort or emphasis devoted to consolidation of common tasks like
pulling data out of the database. The maintainable approach is to use
a single procedure to obtain data, and then any of several separate
rendering tools on the server or browser to generate appropriate
markup. This approach is typically what is being described when the
eXtensible Markup Language (XML), XML style sheets (XSL), and the XSL
style sheet tranformation language (XSLT) are invoked. Note that this
approach does not necessarily eliminate the need to maintain parallel
sets of display information: if you add a field to the lone
datasource, you'll still have to update all templates or stylesheets
with directions on where the new field is to appear. Note also that
the need to maintain parallel sets of display information is not
directly tied to the existence of multiple markup languages per
se. A truly impressive service would distinguish among
additional dimensions such as spoken language, bandwidth, and screen
size.
SDK's and WAP-enabled browsers are available from
Web Application Programming tools
Other
|
|
