Wireless Web: The final frontier?
Today's bonus word is wireless. If you add this word to the mix of a Web
project, it suddenly becomes hot! Say "wireless" and watch venture capitalists sit up
and take notice of your ecommerce plan. It's no longer boring old ecommerce, it's
m-commerce -- m as in mobile. In some cases, it seems people are
practically drunk on the potential for wireless.
Will there be a hype hangover like those that followed the initial excitement over
Java and XML? Probably so. Here's my simple remedy to avoid the worst effects:
Watch Star Trek.
Huh? How can watching a Star Trek episode help forestall wireless hype
hangover? Well, it's simple: Star Trek shows people interacting with data in
environments beyond their desks in a logical way. Sure it's science fiction, but it's
plausible.
On these shows, people tend to use information systems in one of three ways. First,
they sit at a console, just like a person sitting at a computer at work or at home here
on present-day Earth. They interact by means of keyboard and voice, browsing and
manipulating large volumes of on-screen data in formats ranging from text to voice to
video.
The second way Star Trek personnel access information is by walking around
with a tablet or similar device and entering information as they work. This is no
different from today's mobile worker using a laptop, handheld, or palmtop while in the
field.
Lastly, when stuck on a planet or away from their stations, crew members on Star
Trek utilize their communicators to talk to a computer and ask it for information.
This shows how the wireless Web will really work.
By the Star Trek standard, today's wireless Web really doesn't work very
well. Just try shoving a Web page onto a three-line, 12-character display with no
graphics. It's not exactly the functional equivalent of a Starfleet communicator badge.
Yet this is the minimal configuration for a Wireless Application Protocol data-capable
phone as defined by the specification set by the WAP
Forum. Even when using a large-screen device like a
wireless Web is only slightly more exciting than Gopher was in 1992.
Get used to it -- the wireless Web is different. First and foremost, the WAP
protocol had to be designed to deal with the problematic nature of cellular links. In
addition, due to the different interfaces and capabilities of wireless browsing
devices, developers had to create special markup languages such as
From a Web designer's perspective, the good thing about wireless Web languages is
that they are very similar to HTML and are consequently relatively easy to learn.
However, with these languages, the rules are strictly enforced, so you have to be
careful.
Some have gone so far as to suggest that there is no need to learn anything new --
that you can just use HTML as is. In fact, numerous firms, including
servers to convert Web content from HTML to wireless device languages like WML or HDML.
This approach sounds nice in theory, but in practice it requires that the HTML be
well formed. This is, to say the least,
to be the case. The translation server strategy also requires a huge leap of faith
regarding the content's volume. Do you really need to see all the information from a
page or do you just want an important bit of data?
Remember Star Trek! The computer doesn't read page after page of content.
So here's a question for the translation server approach: how is the service going to
know what portion of a document to extract for a phone user requesting a particular
page? If you say "artificial intelligence," you need to do your homework; since the
space of all Web documents is infinite, doing this job properly means inventing
generalized AI. If you pull that off, forget the wireless Web -- you're going to be
richer than Bill Gates.
Well, if AI isn't practical, what about using special tags that tell the server what
it should deliver? That solution only works with specially altered pages. So we're back
to a high-effort scenario. The wireless Web will entail changes to existing sites,
since it is unlikely that one site, no matter how it is coded, will fit all
environments.
The real point of this whole thought experiment is that bringing the Web outside is
going to require developers to carefully consider the environment of
consumption, including such factors as noise, glare, lack of decent input
capability, intermittent connection problems, and so on.
Next time I'll analyze the recent browser releases. Are they really standards
oriented, or do they mask the same set of problems with a new release number?