Making the Right Technology Decision

Perhaps no decision is as critical to the success of a software project as the choice of underlying technology. Never in my experience has that choice been so shrouded in mystery and misunderstanding as it has with the advent of the Web.

Thank you, thank you, thank you a thousand times for your Maximizing Windows article!

Not for the web design wisdom, but as an outstanding example of the UI problems that come from stuffing applications into web browsers. Currently, IMHO [in my humble opinion], web browsers are an appropriate mechanism for application delivery only when an application must be made available to the public (or rather all networked computer users) at large. While the approaching universality of web browsers is unmatched by any other platform, that singular advantage comes with an amazing set of disadvantages.

We have a perception problem out there—that the web is what’s “new” and “better” and “sexy” and “cutting edge,” ad nauseum, and thus all new applications should be web-based. In many cases where an application does not need to be available to the “public” or a large number of users, where the application will be used every day instead of only rarely, the better solution is a cross-platform custom application. (The application should use TCP/IP for communications and be available for download via a web browser, thus taking advantage of the lower-level of universal connectivity.)

So next time I’m talking to a client who needs to provide an application (of at lest moderate complexity) to a handful of users at each of a handful of business partners and who thinks they want a web application, I’ll fall back on your article instead of stammering as I try to figure out how to politely say: “BUT THAT WILL SUCK!”

Scott Ribe

Let's first explore what has gone wrong, then see what we can do to fix it.

Command line vs. GUI

The last great paradigm shift was the initial move from command-line to GUI. The advantages and disadvantages of each back in the early ‘80s were well understood:

		Command Line	Early GUIs
Speed:		Fast	Medium
RAM Memory requirement:		Low	High
Familiarity:		Excellent	Nonexistent
Ease of learning:		Fair	Good
Ease of use:		Good	Good
Safety:		Poor	Excellent
Development effort:		Understood and reasonable	Not understood and complex

(“Safety” refers to the support offered by the application, guiding users away from error and helping them catch and correct those errors that are unavoidable.)

GUIs were only a lot easier to learn than a command line interface. However, if you already knew the command line interface, you didn't need to learn anything to use it. Since the early adopters had already adopted and grown used to command lines, they so little reason to switch over, and GUIs were very slow to catch on. It was only years later, as familiarity with GUIs grew among both users and developers and as computer speed and memory capacity improved, that the balance finally tilted toward GUI. The transition was over only when the command-line interface became the unfamiliar, and, therefore, difficult interface to learn.

Rush to judgment

A quite different cycle is happening with the Web. People have adopted the apparent “new technology,” generic web browsers such as Netscape Communicator and MSIE, upon which they are constructing complex mission-critical applications. They are often doing so with little regard to their comparative weakness:

		Contemporary GUIs	Contemporary Web Browsers
Speed:		High	Slow
RAM Memory requirement:		Low	Low
Familiarity:		Excellent	Good
Ease of learning:		Excellent	Fair
Ease of use:		Good	Poor
Safety:		Excellent	Poor
Development effort:		Understood and reasonable	Not understood and complex

(When I referred to the speed of generic browsers as being slow, I’m talkin’ very, very slow—an order of magnitude slower than a 1978 Apple II or 1978 Commodore PET. That’s because browsers are a throwback to the 1970s timeshare technology, a technology that was swept away by the advent of the high-speed personal computer with its local storage and fast processor.)

Given the above comparison, it would seem almost impossible that people would voluntarily develop applications in a generic browser environment, and, yet, people do because there are compelling reasons to do so, which I will discuss below. But today’s headlong rush toward generic browsers is as often based on misconception, rather than need.


The internet is not the web is not a browser

Much of the current confusion arises out of the conventional wisdom that, somehow, the Internet, the World Wide Web, and a generic browser are the same thing. They are not.

The Internet is the communications medium that happens to support the Web. But it also supports a lot of other things, like email (SMTP), file transferring (FTP) and Remote Procedure Calls (RPC). If the internet were a superhighway, then these various services would be specialized vehicles: the mail truck, the parcel service van, etc.

The Web, in this metaphor, might be the passenger car, for the first time allowing common folk to drive the superhighway that, until that time, had been reserved strictly for specialized tractor-trailers.

And what of the Generic browsers? They are the original Model T Ford, ugly, not particularly easy to use, but cheap and ubiquitous.

So what’s the problem? The Model T Ford was a wonderful car for its day. The problem is what we are trying to do with it. Developer A, in writing a networked game application, has installed enough extra seats for ten passengers. Developer B, in writing an executive calendaring application, has added plush leather to the front seats and torn out the back ones, replacing them with a wet bar and hot tub. Developer C, in writing a mission-critical internal application, has outfitted it with an emergency ladder.

Ever tried to fit ten people into a Model T? Ever tried to go uphill in a Model T carrying a quart of water, let alone 300 gallons? Ever tried to corner a Model T with an 20 foot ladder strapped to the roof? You have a tendency to crash.

More vehicles

Today, we have vehicles on the road that handle all of these specialized needs: Passenger vans that seat ten, limousines sporting hot tubs in the rear (look for the two sets of four back tires), and pickup trucks with ladder racks. We also have luxury sedans, urban assault vehicles (also known as SUVs), campers, and sports cars. These are vehicles designed from the ground up for specific missions, with affordances and controls that make sense for that mission. And all of them go faster than that original Model T Ford.

How long do we have to wait for a rush of equally-specialized vehicles for the Web? No time at all. They are as close as the blurred fingers of you programmers.

SuperBrowsers

Generic Browsers are not magic. Their two functions are to communicate over the Internet via HTTP, HTTPS, and other protocols, and to reduce your state-of-the-art computer to a dumb terminal with graphics.

You can do better. And your choices are growing, even though the market remains confused. Today, you can choose among Sun Java, Microsoft’s J++, Visual BASIC or Visual C++ with Internet Explorer extensions, or Internet Explore itself, with ActiveX controls.

Using any one of these platforms, you can develop your own SuperBrowser, a weblication (web application) that is fast, efficient, and capable of hiding from the user much of the onerous latency and sluggishness of today’s network connections.

The generic browser advantage

With all the speed and efficiency of SuperBrowsers, the generic browser will suffice for many, if not most applications. If you want to display information on a website, generic browsers are a natural—it’s the one and only thing they were designed to do. If you have a relatively simple service, particularly one that is used infrequently, the generic browser offers the advantage of zero software installation and an interface powerful enough to handle simple transactions.

On the other hand, if someone will be doing a repetitive activity, such as filling out the same shipping form 100 times a day, it makes little sense to download that same form across the net 100 times, only to upload the entire form again 100 times. Better to download it once and upload only the data entered on the form, a task impossible with today’s crude generic browsers, but a snap with Internet-enabled GUI technology.

Custom SuperBrowsers also offer all the advantages of today’s GUIs: A standardized, comfortable, familiar, and safe environment. A wide variety of objects, such as combo boxes, that greatly increase user productivity. Local storage, accessed anywhere from 1000 to 1 million times faster than over the network.

The uphill battle

If the technology choice is as clear as presented above, why are people pushing generic browsers so hard, even when they will slow people down so much?

First, many customers equate the Internet with either Netscape Communicator or MSIE. Many software salespeople have grown afraid to even mention a more traditional GUI interface to their customers now desperate to be “Internet Enabled.” This objection can be overcome by presenting the proposed software as a SuperBrowser, rather than presenting it as, “you know, like 1984 technology, but it connects to the web.”

Second, GUI technology still lags in scalability, getting lots and lots of people connected really fast. You can’t scale up in the manner of Ebay if you have to send everyone a CDROM that may or may not install properly on the customer’s machine. Nor can you send tech support people out every time there’s the need for an update.

Both the initial installation and the update problems are being attacked. The industry needs to move a lot faster to overcome these problems if we are to be freed of the fetters of today’s crude browsers.

In the meantime, if you can handle the installation problem and solve updating, by all means build SuperBrowsers and get ahead of the curve. If these problems are overwhelming, stick with the tried-and-true Model T. If you’ve got the budget, do both.

The SuperGeneric Browser

Meanwhile, Microsoft is making great strides in improving the generic browser. First, they got rid of the other generic browser from that other company, making it a lot easier for those developers who had been forced to write to the lowest common denominator. Now,. there's really only one denominator.

Second, Dynamic HTML has actually made it possible to write something that looks and feels like a real application. For the first time, something more complex than a simple order form can be built and will run in something approximating real time.

Lots more needs to be done. Microsoft needs to continue with their master plan, knocking out Apple, Sun, and all the other platforms, making Internet Explorer compatible with "all systems" by virtue of there only being one. (They could, alternately, make Internet Explorer fully compatible across all systems, but I think they would rather drink paint.)

Then, they need to add a lot more horsepower under the covers, so that developers can mask a lot of the delays and latency of the net. Finally, they need to give developers access to standard window objects, like the menu bar. Until we can have access to the fundamentals of the GUI, weblications will continue to be a poor stepsister to "the real thing."

The Three Year Lag

As Microsoft works away on Internet Explorer 6.0, millions of people continue to use Netscape 3.0. A lot more who would rather play cards with Netscape than play monopoly with Microsoft have only moved up to Netscape 4.0, where they intend to stick until hell freezes over or Netscape's open-systems "iguana" project sees the light of day, whichever occurs first.

No Netscape browser today supports anything other than the most rudimentary parts of Dynamic HTML, and none will be magically updating itself any time soon. As a result, the majority of us for the majority of projects will continue to turn out software we would have been ashamed to ship in the '70s, because that't the best these ancient lizards will support.

You can, with impunity, use stylesheets right now, regardless of what browser your pages will be seen on. Just make sure (as I failed to last month) that you test on both stylesheet and pre-stylesheet browsers to ensure you haven't produced any invisible text.

You can also push for sending different pages to different browsers, so that users of up-to-date browsers (IE 4.0 & 5.0) will not be penalized because of their less "with-it" cousins. Selling this idea is made far easier by creating a really swift looking page in dynamic HTML, then letting folks see what the experience would be otherwise.

And, should you get nowhere with any of these arguments, look at the bright side: In just a scant three years—less if Microsoft "accidentally" change something in the OS that will make these old browsers break—almost everyone will have 5.0 browsers and you'll be able to return to designing real software.