A walk through cyberspace

How Jini could transform the Web

Web pages are great. I get a lot of information from Web pages, and I use them to deliver articles and other information to readers. Nevertheless, I have always had a nagging feeling that a significant portion of the Web is missing. In this article, I'll explain what I find lacking in the current World Wide Web and suggest a way that Jini technology could help supply the missing functionality.

The document metaphor

Web pages serve as an electronic form of what people have used for a long time to transmit information: paper documents. In the real world, paper documents come in many shapes and sizes. But whether you are looking at a book, a magazine, a grocery list, a modern yellow sticky, or an ancient scroll, the document is likely to be composed primarily of text and graphics. Similarly, although Web pages can sport interactive applets and flashy animations, most Web pages, like their paper counterparts, are composed primarily of text and graphics. Because people use Web pages in many of the same ways they use paper documents, Web pages evoke a document metaphor on the network.

Web pages are extremely well suited for delivering information to people electronically. Because people are used to getting information from documents in the real world, they understand the document metaphor of Web pages.

One kind of information that Web pages are particularly adept at transmitting to people is links to resources. If you click on a hyperlink, the browser loads the referenced page. People quickly learn to use hyperlinks, in part because "point and click" is easy to understand, but also because hyperlinks bear a strong resemblance to references in paper documents. Hyperlinks and Web browsers merely automate the delivery of such external resources.

Another role a Web page can play is that of a form. For example, to subscribe to my newsletter, you can go to a Subscribe page at Artima.com that contains a small text box and a button. You type your e-mail address in the box and click the button. The browser sends your e-mail address back to the Web server, which hands it to a CGI Perl script. The Perl script adds your e-mail address to my mailing list, generates a Web page that says you were successfully added, and hands the Web page back to the Web server. The Web server forwards the Web page to the browser, which displays it for you. This response page informs you that you are now on my list and, just in case you ever change your mind, gives a link to the Unsubscribe page.

Filling in forms on Web pages is reminiscent of filling in forms on paper. The process I go through to subscribe to a print magazine, for example, is similar to the process visitors to my Web site must go through to subscribe to my newsletter. Magazines often include a subscription card that contains a form. To subscribe, I fill in my name, address, credit card number, and so on. Then I mail the card to the magazine. Because people are well versed in filling out paper forms, filling in text boxes on Web pages is a natural and easy-to-understand way for people to submit text-based information to the network.

The three fundamental aspects of the document metaphor -- page units filled primarily with text and graphics, hyperlinks to external resources, and forms to fill in and submit -- are very familiar to users. Interacting with Web pages feels natural to people.

Web pages and services

Another way to think of Web pages, besides thinking of them as documents, is as services. By service I mean anything that gathers information of some perceived value or distributes it to other entities. Thus, Web pages provide services to people.

A basic Web page of information offers an information service. If I need a recipe for pumpkin pie or the weather forecast for Annapolis, Md., I can probably find Web pages that provide this information.

A Web page that links to other resources on the network offers a resource organization service. If I need links to Jini resources, for example, I can visit any of several Web pages created for that purpose. By browsing these Jini resource organizer pages, I can decide which Jini resources to order from the network with just a click.

A Web page that is full of text boxes and buttons offers a form service. Whereas information and resource organization services enable me to extract information from the network, form services enable me to submit information.

These three kinds of services are usually combined in single Web pages. Most information service pages include links to other resources, which means they also offer resource organization services. Most form service pages include information service text that, at the very least, explains how to use the form service.

These capabilities of Web pages have generated a massive proliferation of higher-level services, all of which conform to the document metaphor. I can buy and sell stocks through Web pages. I can send and receive e-mail, auction off my old bicycle, do my Christmas shopping, organize my daily schedules, and get maps and directions.

So what's the problem? What could possibly be missing from this World Wide Web, which overflows with information and services? My complaint is that the document metaphor of Web pages constrains many higher-level services, especially those that require a lot of interactivity.

Pounding round pegs into square holes

When I'm traveling, I often read my e-mail through Yahoo! e-mail, an elaborate service offered through Web pages. But when I'm home, I use Netscape mail, which offers the same service but without the Web page document metaphor. Eudora also offers the same service without the metaphor. Why don't these desktop incarnations of the e-mail service use the document metaphor? My feeling is that the Web page document metaphor is not the most natural user interface for many services, including e-mail. Yahoo! e-mail uses the document metaphor because it has no choice but to use Web pages to deliver services over the Internet.

My sense is that many round services are being pounded into square Web pages, just so they can be delivered across the network. A toaster service need not be elaborate to hit up against the constraints of the document metaphor. For example, imagine that you want to control your toaster's dark-light setting. A toaster is a very simple appliance, and a remote dark-light setting is a very simple service that the toaster offers, but even this simple service would be clunky to deliver via a Web page. It could of course be done, with a form that looked something like this:

It works, but the settings would feel more natural on a slide control, which HTML doesn't offer. Of course, I could include a Java applet in the Web page:

For some reason, your browser will not let you view this way cool Java applet

Now I've got my slider but I'm still not happy. Why not? Because my toaster's slide control is sitting in the middle of a Web page. I can live with it, but it feels clunky.

Pages and places

In the real world, when I want to interact with my toaster, I don't go to the bookshelf, grab a book, open it to the toaster page, and move a knob embedded in the page. Rather, I go to my kitchen, a "place," and interact directly with my toaster, an "object."

The way I interact with my toaster in real life is how I'd like to be able to interact with the toaster service on the network. In fact, I'd prefer to interact in a similar way with any kind of service that doesn't mesh well with the document metaphor. I'd like to go to places on the network and interact directly with objects.

What is a "place"? A place is simply one kind of object that provides a resource organization service. An example of a place would be a chunk of network-delivered software that looks like the Macintosh Finder, a collection of network resources that can be viewed as a list, with or without details, with small icons or large icons, and so on. When I double-click on an icon, the place asks the browser to grab that resource. The requested resource could be a Web page, an object, or another place.

I believe that a space metaphor -- in which people go to places on the Net and interact with objects -- would be an intuitive way to use the network that augments the current dominant document metaphor. People should be familiar with space, after all, because that's where they live.

To me, the term Web doesn't necessarily imply a set of interlinked pages on the network, but rather a set of interlinked resources. Pages are currently the dominant resource unit on the Web, but places and objects could also conceivably participate on the Web as well. A Web of places, each of which contains links to objects, documents, and other places, yields a space metaphor that is more deserving of the term cyberspace than the current dominant metaphor used to navigate the Web. Although many people call the current Web "cyberspace," it is really more like a "cyberdocument."

Documents and desktops

The other constraint of the document metaphor, aside from its forcing everything onto pages, is the limited accessibility of those pages. Granted, one of the original prime selling points of Web pages was their platform independence. Unlike a lot of other things in 1994, Web pages didn't run just on Windows. You could look at a Web page on Windows, OS/2, a Macintosh, Solaris, Linux, IRIX, and many other platforms. Web pages have a high degree of portability, which nevertheless has its limits.

Most Web pages, for example, don't look very good on a 13-inch television screen viewed from a horizontal position at a distance of 12 feet. The text is too small, and if you increase the size of the text, you can view only a small portion of the page at a time. Similarly, Web pages don't work very well on small displays. Viewing a Web page on a palm device is like trying to read a white paper from a yellow sticky. What's more, Web pages are not interesting to talk to if you call them up on the phone. It is difficult to interact with Web pages if you have a speech-only access device, or if you are temporarily using your eyes for other tasks, such as driving a car.

Web pages are best viewed about two feet away from a high-resolution screen, and they're best operated with a mouse for clicking on links and a keyboard for typing into forms. In other words, Web pages are best suited for desktop computers.

In the future, more devices in our environment will be embedded with microprocessors and connected to networks. This holds the promise that we'll be able to access a wealth of information and services from the network at any time and any place. The document metaphor of Web pages is ill suited for the emerging hardware environment. In contrast, one of the advantages of an objects-in-places metaphor is that objects can be defined such that you can access their services in many ways from many kinds of network portal devices.

What does this have to do with Jini?

As this is a Jini-oriented column, you may be wondering what an objects-in-places metaphor for the Web has to do with Jini. At the second Jini Community Summit, which took place October 17-20 in Annapolis, Md., venture capitalist Ted Schein gave a talk titled "Succeeding with a New Technology." Schein outlined several guidelines for entrepreneurs seeking venture capital. One of his guidelines for those planning to do something with Java was "Know why you are using Java." Given that he was one of the founders of the Java Fund, Schein said applicants are often surprised when he asks "Why Java?" But, he said, Java should be used to solve only problems that it is well equipped to address.

In the case of cyberspace, Java and Jini are well equipped to help solve the technical challenges presented by an objects-in-places metaphor. Java enables the network mobility of code and objects. Jini moves the point of agreement between the parties of a distributed system from network protocols to object interfaces and provides a clean separation of functionality from the user interface.

Java applets

In my book, Inside the Java 2.0 Virtual Machine (McGraw-Hill, 1999), I spend the first four chapters explaining how Java's architecture enables the network mobility of code and objects. In short, Java enables network mobility through the portability of the Java Platform, the homogeneous execution environment of the Java Virtual Machine and Java API, and the security capabilities built in to the platform. I consider network mobility to be the main point of Java's architecture. As Bill Joy said at the first Jini Community Summit, "We built the JVM to let objects move around."

Related:
1 2 3 4 Page 1
Page 1 of 4