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 href="http://www.w3.org/TR/NOTE-Submission-HDML-spec.html">HDML or href="http://www.wapforum.org/what/technical.htm">WML.
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
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 href="http://www.spyglass.com">Spyglass, have proposed using special translation
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, href="http://mithras.itworld.com/articles/columns/net-powell-0301.html">not very likely
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
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?