The Case Against Strained Carrots

Suppose one day you go to the store to buy some carrots. But when you get there, you discover that the only carrots your grocery store has are the strained carrots in the baby-food section. Looks like you won't be making the cole slaw, beef stew, or moo-shu pork you had planned.

A similar scenario is unfolding on the World Wide Web: the utility of the information available is being severely limited because organizations are over processing it. Whether they're using custom Java applets, JavaScript, HTML forms and CGI scripts, or content that requires plug-ins to view, the net result is that they are controlling how information is queried, transmitted and presented, not the information consumer. This is analogous to grocery stores only carrying strained carrots.

The analogy here is deep: not only does use of these technologies put severe limits on how you can use the information and on how easy it is to find, but it also unnecessarily discriminates against smaller organizations because only the largest organizations can afford to publish their information this way. In the real baby food industry, only the largest companies can afford the technology required to produce, package, and distribute strained carrots. Likewise, no Internet equivalent of a farmers market or roadside stand can afford the custom development required to make "strained carrots" of their information to make it accessible to Internet users.

Here are a few examples of problems that the Internet would be an excellent vehicle for solving, most of which are solved now by spending lots of time on the telephone. Unfortunately, it's beginning to look like the Internet is not going to be able to support any better solutions to these problems than using phone any time soon because the rapid adoption of HTML forms, Java, and other processing technologies are going to delay the implementation of the necessary infrastructure.

1) You need to ship a crate across the country. Who can do it inexpensively in a reasonable amount of time?

Most of the large shipping companies are hard at work publishing their rates in HTML format and building Java applets and HTML forms with CGI back ends to present the information as they want you to see it. This means that to do comparisons you have to visit each of their sites in turn, wait for all the pretty graphics and Java applets to download, type in the address information manually (again), and then copy down the information the system spits back out so that you can compare it with the information from all the other companies.

Suppose instead you could run an application on your local system that would ask for the source and destination addresses, the weight of the crate, and when you need it picked up and delivered. The application could then query all of the shipping companies that cover your area. The results would come back, and you might discover that Joe's Moving, based three blocks away, happens to be moving a family to your destination city tomorrow, and will move your crate for one quarter the cost of any of the other companies.

The same type of form (minus the "weight" field, of course ;-) could be used to search for the best way to send you via airline to some other city, or to get the best cab, rental car, or mass-transit route information for a local trip.

2) You need a particular kind of spark-plug for your lawn mower. Who has it in stock, and how much will it cost?

Many companies are putting their parts catalogs on the Internet, but only using proprietary data formats and in some cases, proprietary Java front-ends. This makes doing searches like this impossible.

The local hardware might have the part, but what are the odds that they have a WWW site, given the expense that seems to be required to fluff it up with pretty graphics and to build and maintain a custom CGI application to allow querying their inventory database?

3) You want to purchase a new computer. You have the specifications, and now you want to compare pricing and availability from different companies.

There are several computer vendors that have HTML forms for getting quotes on custom computer configurations, but each uses their own proprietary format. Again, searching across companies is impossible, as is automating searches if you do this sort of thing often.

The same type of query application could be used to specify the configuration for a new car, or even a grocery list, which would allow you to compare pricing and availability of the items on your list from all of the local supermarkets with one operation. Why should everyone have to waste time filling out forms with the same information over and over, and learning the layout of each companies WWW site, wading through graphic and Java-applet downloads on each of them?

4) Your native language is Spanish, and you want the prompts in the query forms you use to solve problems #1-3 above to be in Spanish. Or your eyesight is poor, and you want your form arranged a certain way or using a text font of a certain size.

Certainly it's not practical for each company provide a language-specific Java applet or HTML form. But if companies provided access to their information in standard formats, you could customize the application used to query them as you see fit.

How it will work

Four components are needed for these activities to become practical. The first and most important is published standards for information formats for the information providers. Though standards for this type of thing already exist in individual industries and for Electronic Data Interchange (EDI, see http://www.premenos.com/standards/), we need to greatly expand the scope and use of these standards.

While defining a process for designing these standards may seem to be an intractable problem in itself, similar interoperability problems for data interchange between calendar and scheduling applications from different vendors, and an Internet Engineering Task Force has already been formed to solve them (see http://www.imc.org/ietf-calendar/).

The second component is wide availability of translators to convert data from the proprietary data formats used within organizations to these standard formats. There are many such translation tools for EDI, some produced by ISVs and some by the database vendors themselves. Once these off-the-shelf tools become available, even small businesses will be able to make their information available on the Internet without having to invest in the custom programming required to make "strained carrots" first.

The third component is a way of locating the organizations that offer the type of service or product you're looking for. This kind of search can already be done on most of the Internet search services, but some facility for doing the searches automatically from within other applications will be required.

The final component is the applications that information consumers will use to select and narrow down the list of sites to query, display the query form, handle the connections to the query sites, and collate and display the returned information. These kinds of applications should be easy to develop and easy to customize, and are ideal candidates for implementation using MetaCard, Tcl/Tk, Visual Basic for Applications, or other high-level GUI development tools.

These applications must be flexible and reusable, and people will quickly become adept at using particular applications. Advanced users will tweak the interface to present the information exactly how they want it, and will automate those queries they do on a regular basis. If history is any guide, after a short break-in period users will be extremely reluctant to switch to another application or even upgrade unless substantial new features become available.

Contrast this with the architectures such as Java applets and/or HTML forms, where upgrades are frequent and automatic, and the user has no control over how or when the interface is changed. Most users really hate having upgrades crammed down their throats like this, because it frequently requires them to invest time learning a new interface and working around compatibility problems when they can least afford the time it takes to do these things.

What can you do?

If you're developing an corporate Internet policy, or even just a Web site, the place to start is to realize that if you base your system on plug-ins, Java applets, or HTML forms and CGI, that you're building a disposable system that most people won't want to use when standards for information interchange become common. Learn what you can about EDI and IETF standards for data interchange, and support them whenever possible, and press for new standards if no existing standards are applicable.

When (not if) standard information formats become widely used, we will all be able to automate repetitive tasks and manage information on the Internet as easily as we manage information locally using PIMs (Personal Information Managers) and custom applications built with scripting language based development tools.

White Papers | High-Level Tools . Calculator . TOP . Comparisons . Strained Carrots