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 NeoPoint 1000 or a Nokia 7110, you'll find that the 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 HDML or 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 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 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, 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 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?