Technological developments look inevitable only in
hindsight. Many commentators agree that wireless digital devices will be the
next communications revolution. However, they don't necessarily agree what
these devices will look like, what they will be used for, who will use them or
what technology will be used.

Two divergent points of view are: the WAP (Wireless
Application Protocol) approach from the mobile telephone industry, and
the wireless Internet approach from the computer industry. With the
first approach mobile telephone handsets have computing capacity added, to
become wireless data devices. With the second approach hand held computers
have wireless communications added to become multi-function phones. The result
should be convergence, with telephones growing to be computers and computers
shrinking to pocket size. However, the different points of view of the
developers can result in devices with different capabilities. The author of
this document is firmly in the computer industry category and will therefore
argue why the WAP approach will not work and the wireless Internet will.

Often forgotten in debates over technology are the end
users of the technology. In the case of wireless technology a rare "win win"
is possible with techniques for providing access to disabled people also
improving wireless devices. The usability of a hand held device is
particularly important when it is used to control a physical device, such as a
garage door or a robot surveillance aircraft.

WAP is designed to work with most wireless networks such as
CDPD, CDMA, GSM, PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT,
DataTAC, Mobitex.

What operating systems are compatible with
WAP?

WAP is a communications protocol and application environment.
It can be built on any operating system including PalmOS, EPOC,
Windows CE, FLEXOS, OS/9, JavaOS etc. It provides service
interoperability even between different device families.

As currently conceived WAP is unlikely to become the
mainstream technology for wireless Internet applications. The limitations of
current WAP devices require content to be specially designed in the Wireless
Markup Language (WML).

WML is defined using the Extensible Markup Language (XML), which is being promoted
for new web content. This code will actually run on most modern web browsers,
although the formatting may look a little odd on a larger screen than it was
design for:

However, WML is different to the HTML currently used for
most web pages and XHTML as
proposed for new web pages. So while WAP content might work on new web
browsers, old web pages will probably not work on new WAP devices.

WAP has been designed to fit within the limitations of a low speed (9600bps
or slower) dial-up mobile telephone link and a low capacity hand held client
device. The result is a set of specifications which follow Internet standards
as much as possible and meet the limitations set for them.However, the result
is an additional set of standards, different to existing Internet and web
use.

I-mode provides
a different, and more promising approach to a web service on a hand held
device. I-mode uses a proprietary mark-up language based on HTML:

First introduced in Japan in February 1999 by NTT DoCoMo, i-mode is one
of the world's most successful services offering wireless web browsing and
e-mail from mobile phones. Whereas until recently, mobile phones were used
mostly for making and receiving voice calls, i-mode phones allow users also
to use their handsets to access various information services and communicate
via email.

In Japan, i-mode is most popular among young users, 24 to 35 years of
age. The heaviest users of i-mode are women in their late 20s. As of
November 2000, i-mode had an estimated 14.9
million users.

When using i-mode services, you do not pay for the time you are
connected to a website or service, but are charged only according to the
volume of data transmitted. That means that you can stay connected to a
single website for hours without paying anything, as long as no data is
transmitted.

From I-mode
FAQ, WestCyber Corporation, 2000 (no longer on-line)

W3C is working on adapting standard HTML for mobile devices, to provide a
less proprietary approach:

A new class of electronics devices with Internet access capability
called "Information Appliances" was recently born. This Internet access
capability is embedded in devices such as televisions, set top boxes, home
game machines, telephone-based terminals, PDAs, car navigation systems and
cellular phones. These Internet appliances will drive the merger of wireless
and wired Internet world that will eventually create a much larger industry
than today's predominantly wired Internet industry.

However, it may be some years (or never) before a suitable standard for
mobile devices is adopted. An alternative approach by the CSIRO, here on the
ANU campus, is to render the web content in a format to suit the display
device:

Combining XML, ASP and database technology provides a powerful mechanism
for the development of mobile applications. We describe the development of
an application that provides name, rank and phone number information for an
organization. The information is accessible from a web browser or a WAP
browser on a mobile phone. It uses ASP scripting to query a database and
build an XML document satisfying the search criteria. We’ll detect the
browser type then apply an XSLT style sheet to format the information for
display on the detected device. A generic windows scripting component (WSC)
derived from that described by Mike D. Jones in a February 7 2000 Active
Server Developers Journal article is used to query the database and return
the result to an ASP script as an XML document. You can view a working copy
of the application at http://mobile.act.cmis.csiro.au and download the files
to implement the application

The WAP approach of building a new set of standards for
hand held devices goes against the Internet approach of adding new
capabilities while retaining backward compatability. More capable hand held
web terminals with larger screens, more processing capacity and continuous
Internet access are becoming available. These can be pocket size devices,
similar to today's PDAs, and no much bigger than a mobile telephone. As these
devices increase in capability they will be able to use standard Internet
protocols and will not require special WAP services.

However, hand held devices will be inherently limited by their small screen
size, limited keyboard and lower bandwidth connection, than fixed units.
Serendipitously, accessibility features designed for the disabled can be used
to overcome some of these limitations.

Web accessibility guidelines have been developed to
assist designers to make web sites which can be used by the greatest range of
people. The most respected guidelines are those from the World Wide Web Consortium. Last year I used those guidelines to assess accessibility for the
blind to the SOCOG Sydney Olympic Web site, in a case
before the Human Rights and Equal Opportunity Commission.

There is a common misconception that accessibility
issues are exclusively to do with a small section of the community who have
physical disabilities. However, as the W3C guidelines make clear, they can
provide benefits to the wider community:

For those unfamiliar with accessibility issues pertaining to Web page
design, consider that many users may be operating in contexts very different
from your own:

They may not be able to see, hear, move, or may not be able to
process some types of information easily or at all.

They may have difficulty reading or comprehending text.

They may not have or be able to use a keyboard or mouse.

They may have a text-only screen, a small screen, or a slow
Internet connection.

They may not speak or understand fluently the language in which
the document is written.

They may be in a situation where their eyes, ears, or hands are
busy or interfered with (e.g., driving to work, working in a loud
environment, etc.).

They may have an early version of a browser, a different browser
entirely, a voice browser, or a different operating system.

Content developers must consider these different situations during
page design. While there are several situations to consider, each accessible
design choice generally benefits several disability groups at once and the
Web community as a whole. For example, by using style sheets to control font styles and
eliminating the FONT element, HTML authors will have more control over their
pages, make those pages more accessible to people with low vision, and by
sharing the style sheets, will often shorten page download times for all
users.

These issues are particularly relevant to wireless
mobile devices. A hand held device may be used in a situation where it is
difficult to see or hear, where the user's hands are needed for other tasks or
where they are distracted. These devices tend to have small screens, limited
graphics, limited keyboards and pointing devices. The wireless connection
makes the connection slow and the device may have a less capable browser. In
effect the user of the handheld device suffers a temporary disability which
can be overcome by applying the guidelines.

Two examples of use
of wireless devices in motion

... Gus' Cafe was
opened by Augustin "Gus" Petersilka, advicate of the outdoor Viennese cafe.
... Well after Gus' time the cafe has changed from
using pencils and note paper for taking orders and now has wireless PDAs.
The staff were a bit busy taking orders to stop and explain the system to
me, but it appears to use standard Palm III personal digital assistants
(PDAs) for taking the orders.

... visit Philippe Quéau Director of Information Society
Division UNESCO. This was a good excuse to try the Eurostar train
through the Channel Tunnel from London to Paris .... Mobiles don't work during Channel Tunnel transit (20
minutes) and in shorter tunnels en-route (mostly in the UK). I noticed that
phones do work in the London Underground. As soon as we existed the tunnel
in France, I received a message on the phone from SFR welcoming me to their
mobile service, which is a nice touch. I uploaded the first draft of
this web site, using an GSM infrared interface. This was only just done when
the battery went flat in my computer...
From London to Paris By Eurostar, 19
October 2000

Accessibility features can be added most easily when web content is
created. Conversion of content later is much more
difficult. It is attempted with devices such as Web to WAP gateways, designed
to allow web content to be converted into a limited form for display on a WAP
device.

There are already accessibility features built into
the web. The simplest example is alternative text for images. The HTML
image command (IMG) includes an optional alternate text
(ALT) tag.This
allows a text caption to be entered, which is displayed when the image can not
be. This option is available in just about every web authoring tool and is
supported by just about every web browser. It is just a matter of the web
author typing in the captions when adding images.

Simply designed web pages will display well on a hand held device. The text can be enlarged for reading on a small screen,
images can be omitted or selectively downloaded as required. However, this
assumes the designer is familiar with accessibility issues and is willing to
apply them, sacrificing some design options in the process. Also this approach
becomes much more difficult for maintaining multi-format multimedia
documents. Tools which implement accessibility features and allow
components of a multimedia document to be kept in step would greatly simplify
the process.

These consist of hundreds of separate files
containing redundant copies of the same basic information. The ddocuments are
created using different tools and making consistent changes to all versions of
the content is a complex and error prone process. It would be feasible to build all of the required functions
into one package using open source software and web
based standards to provide:

Authoring: Document creation and
editing functions equivalent to a word processor, presentation package and
web authoring tool. The one "document" could be edited using multiple
different views, to display as a printed document for typesetting, a
"slide show" for live presentation with speaker's notes, a web page for
on-screen viewing, audio accompanied graphics and video. Opening the
presentation function with an existing WP document would automatically
generate a default presentation using
the heading and graphics from the WP
document.

Editing: Consistency between
information elements of the document would be retained during editing.
Correcting the spelling of a word in a slide also would also change the
word in the print version, in a script and mark the point in the audio and
video renderings which would require re-recording. Replacing a word with
an abbreviation in a presentation side would creates a new version of the
information element alongside the full word in the print
version.

Rendering: Versions of the document
would be rendered to suit the capabilities of the display device and user.
Layout "hints" would be used to redesign layouts dynamically to suit
screen size. A large web screen could have multiple frames with graphics,
while a small PDA screen has one page of text with links. Inherent
accessibility would be provided by selecting suitable representations of
the information elements. As an example subtitles for audio and video
renderings would be automatically generated from the text of the document.
Audio captions would be rendered for the text and graphics automatically
from the audio version.

Display: Client and server software
cooperate to send information at a rate which suits the communications
link and user. A slow wireless link would take advantage of accessibility
features, (such as text captions for graphics and video) to provide a low
bandwidth option.

To demonstrate the technique of a multi-format document, this document has
been designed to be a rendered for individual reading or for live audience
presentation as "slides". By default the document is
viewed as a conventional web page. To view as a presentation
slides, set your web browser to use the
accompanying style sheet "http://www.tomw.net.au/2001/slide.css". This instructes the browser to omit sections of the
document marked with the class definition "optional" and leave a large margin
before titles marked "newslide". Set your browser to use a large font size to
suit the audience. For an index to slides use the frames version of the
document: http://www.tomw.net.au/2001/wislds.html

This technique could be further developed as a
student project to add a presentation mode to W3C's open source Amaya web editor/browser, to provide similar functionality to
W3C's Slidemaker
Tool.

While usually thought of for presenting the equivalent of
static document, or pre-recorded video, it should be remembered that a web
interface can be used for a more active control of a physical device. As an
example a Pocket C3I
device is proposed. This would provide a wireless hand held terminal for
controlling a robot aircraft and displaying surveillance information
transmitted from the aircraft.

An alternative is smaller, lower cost and more rapidly deployable UAVs,
such as the Australian made Aerosonde. While
these have beenproposed for surveillanceand might provide more flexibility for small scale use,
its designer still envisages a portable shelter would be needed for control
and at least a lap-top computer for sensor processing.

In place of the one or two truck
transported shelters needed for a UAV, it is suggested that a wireless PDA
could be used to control the aircraft and display sensor information, via
ordinary web pages using the technology discussed above. Multi-format Document Standards would allow the same interface to be used for displaying
training and maintenance information for the UAV, as well as to control and
display imagery from the aircraft. Server/Browser Protocols for Available Bandwidth would allow a low bandwidth link to transmit sensor
information from the aircraft to the hand-held device. Automatic Web Page Layout would allow the interface to be adjusted to suit the
available display device, with more information displayed on a larger screen,
but still have usable on a smaller hand-held device.

As well as control of a UAV, the same hand held
device could be used for video conferences and multimedia presentations. These
are commonly used for military and
civilian command and control, but are limited by bandwidth and cost
considerations from portable pocket size equipment.

A presentation version of this document is available: For
an example of the multi-format technique proposed in this document, set your
web browser to use the accompanying style sheet "http://www.tomw.net.au/2001/slide.css". This will omit
sections of the document marked with the class definition "optional" and leave
a large margin before titles marked "newslide". Set the browser is set to use
a large font size and select the frames version of the document, for a
slide-show type of presentation: http://www.tomw.net.au/2001/wislds.html