The Artima Developer Community
Sponsored Link

Object versus Document, Part III
by Bill Venners
First Published in JavaWorld, November 2000

<<  Page 3 of 8  >>


Disadvantages of an Object-Based User Experience

I'll start with the disadvantages of objects compared to documents from a user's perspective, then look at the advantages.

Disadvantage 1: Java Isn't For the Faint of Heart

One of the main disadvantages of the object approach, in my opinion, is that HTML is a lot easier to write than Java. The release of Mosaic, the first browser to support graphics in Webpages, unleashed an explosion in Webpage creation. I wouldn't expect that the release of a Cyberspace client, such as a browser plug-in that understands objects and places, would unleash a similar explosion in the creation of object-based services. I believe one significant hindrance to the growth of a Web of objects is simply that writing an object-based service is harder than writing a Webpage-based service.

Object-oriented programming is a difficult and time-consuming skill to learn, much more so than learning HTML. Moreover, you need to learn a lot about Java and Jini before you can write your first Jini service, but you can create a simple Webpage after learning just a few HTML tags. In addition, even for experienced Java programmers, writing a Jini service and its associated service UIs can be quite tricky. Programmers need to understand the unique demands of network-mobile objects and how best to separate the user interface (encapsulated in the service UI objects) from functionality (encapsulated in the service object). Programmers used to writing desktop applications are likely to mix user interface code with functionality code. Such programmers will need to adjust their mindsets when writing object-based network services to separating the functionality from the user interface. And finally, programmers need to understand how to divide an individual service into constituent object parts, each of which is delivered separately across the network. The division of services into many Webpages is more commonly understood. Programmers accustomed to designing monolithic applications will need to acquire a new mindset when designing object-based network-delivered services.

On the other hand, few people nowadays write HTML by hand. Most people use HTML editors. I believe the same will ultimately be true of object-based services. As tools that help people create object-based services become more prevalent and powerful, the ability to create those services will become accessible to more people.

Disadvantage 2: Download time

Another potential disadvantage of objects compared to documents, from the user's perspective, is download time. One of the early complaints about Java applets was that they took too long to download when compared to Webpages. Network-delivered Jini services could easily inspire similar complaints.

Of course, the type of the file being downloaded does not affect download time. Java class files do not inherently fly across networks more slowly than HTML files. The download time of a Java applet, Jini service, or Webpage depends upon the number of socket connections that must be made, the speed of the network traffic, and the total number of bytes transferred. The dirty little secret of Webpage-based services is that they actually take a long time to download; this isn't immediately obvious, however, because download time is spread out and users are trained to wait a few seconds for each individual page.

Yahoo, for example, is a rather huge network-delivered service, but when I point my browser to, its homepage pops up in about 4.5 seconds over my 56K modem. When I click on "Mail," I have to wait a few more seconds for the main Yahoo Mail page to show up. When I type in my name and password and press the submit button, I have to wait a few more seconds for the next page to show up. If I spend twenty minutes going through my email, I may end up spending three or four of those minutes waiting for pages to download across the network. But I don't notice it, because the wait time is spread out.

One key to addressing user frustrations with network latency, therefore, is simply to spread the wait times out. If a user has to wait more than 15 seconds or so in any wait session, he or she will get antsy. Of course, as bandwidth increases, service providers will be able to send more data down the pipe within that 15-second window. But no matter where bandwidth goes, service providers will always have to worry about download time. The key to disseminating wait time required by object-based network-delivered services is to chop the service up into multiple objects. Each object needs to be svelte enough to fly across the network in an amount of time deemed reasonable to users.

In addition, users will need to be kept informed during downloads and given appropriate expectations about object-based network-delivered software. Just as current browsers indicate that a Webpage is being retrieved with animations and status messages, users will need to be kept apprised if an object is downloading a constituent object. And just as users have been trained to wait for each Webpage, users will need to be trained to wait for each object.

Finally, the clients through which users access object-based network-delivered services will need to be smart about caching. Just as current browsers keep a local cache of Webpages, Cyberspace clients will need to make use of local or nearby file caches. By using smart caching strategies, clients can help keep users from becoming frustrated by wait times caused by limited network bandwidth and nonzero latency.

Thus, service providers can help keep download time low by partitioning their services into multiple objects, each of which can be delivered individually across the network in an acceptable amount of time to users. In addition, service providers in their service UIs can make sure users are aware that they are waiting for something to come across the network. Clients can help keep users happy by employing various caching strategies. Programmers of the new computer described earlier will need to recognize the importance of dealing with the unique characteristics of the network -- nonzero latency, limited bandwidth, and partial failure -- and allow these characteristics to inform their software and user-interface designs.

<<  Page 3 of 8  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use