Too rich or too thin

YOU HAVE TO pity anyone forced to use a text terminal. Green screens are as outrÈ as rotary phones: flat, static, unaesthetic, unexpressive.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Yet it's easy to forget that in many applications, green screens are the norm. The huge, modern hospital near me uses them, so does Burger King. Ditto for the city police, the phone company, travel agencies, and Internet providers. Apple's sleek new Xserve rack server has a serial port so you can boot, install, and manage it from an ANSI terminal. Screen shots showing off exquisitely artistic Unix/Linux window manager themes always include two terminal emulator windows.

If you tell me the green screen is emblematic of an IT ghetto, I'd counter that 80-by-25 text terminals are the Toyota Tercel of computing -- basic and boring, but also unbreakable, clean, cheap, and predictable. There isn't yet a pervasive GUI that meets all those criteria.

When rich-client proponents compare the Web browser to the green screen, it's meant to be pejorative. But the people building and deploying enterprise applications find deeper meaning in that analogy; the enlightened among us abandoned text long ago.

Now the rich-client missionaries, hailing from Microsoft, Macromedia, and Groove, among others, tell us it's time for the next great human/computer interface paradigm shift. The browser is for surfing; for anything serious, such as a portal or a collaborative application, HTML is as backward as a green screen.

I agree. As with terminal text, standardized dynamic HTML -- excluding Java, ActiveX controls, and helper applications -- is limited in its expression, its aesthetics, and its responsiveness. Yet, also similar to text, HTML goes virtually everywhere. It requires no special server and no special client; you can send it over a modem, shoot it through a network, and save it to disk. And if it suits you, you can whip up a surprisingly rich document or input form using Emacs or Notepad.

A browser cannot format and place information with the speed and precision of a rich client. Incompatibilities exist between implementations, but the list of problems is shrinking quickly, and tools are popping up to help smooth out the kinks. Things have progressed to the point where Sun, which has a rich-client case to make with Java/Swing, is promoting Mozilla as the application front-end of choice for its desktops. Apple, which has at least three GUI APIs to sell -- classic Mac, OS X, and Java -- believes the browser plays a critical role in information delivery.

Universal accessibility is a critical design component for all enterprise applications. Information tailored for a particular version of a vendor's rich client code will be faster, prettier, and more dynamic; but users, partners, and customers are always cut out of the loop, and costs rise.

Until barriers of cost and universality are eliminated, it looks like the browser and its feisty green screen ancestor will stay around.