On their own, Web pages tend to be lifeless and flat unless you add animated images or more bandwidth-intensive content such as Java applets or other content requiring plug-ins to operate (ShockWave and Flash, for example).
Another helpful example is embedding small data collections into a document that scripts can look up without having to do all the server programming for database access. For instance, a small company could put its entire employee directory on a page that has its own search facility built into the script. You can cram a lot of text data into scripts no larger than an average image file, so it's not like the user has to wait forever for the data to be downloaded.
Other examples abound, such as interactive tree-structure tables of contents. More modern scriptable browsers can be scripted to pre-cache images during the page's initial download to make them appear lickety-split when needed for image swapping. I've even written some multi-screen interactive applications that run entirely on the client, and never talk to the server once everything is downloaded.
Scripting can even go further if the page author desires. For example, the author may include a preference screen that lets the user determine the desired background and text color combination. A script can save this information on the client in a well-regulated local file called a cookie. The next time the user comes to the site, scripts in its pages look to the cookie info and render the page in the color combination selected previously. The server is none the wiser, nor does it have to store any visitor-specific information.
Fragmentation of the installed base of browsers will only get worse. By definition, it can never improve unless absolutely everyone on the planet threw away their old browsers and upgraded to the latest gee-whiz versions. But even then, there are plenty of discrepancies between the scriptability of the latest Netscape Navigator and Microsoft Internet Explorer.
The situation makes scripting a challenge, especially for newcomers who may not be aware of the limitations of earlier browsers. A lot of effort in my books and ancillary material goes toward helping scripters know what features work in which browsers and how to either workaround limitations in earlier browsers or raise the compatibility common denominator.
Designing scripts for a Web site requires making some hard decisions about if, when, and how to implement the advantages scripting offers a page to your audience. For public Web sites, I recommend using scripting in an additive way: let sufficient content stand on its own, but let scriptable browser users receive an enhanced experience, preferably with the same HTML document.
The second biggest can of worms is scripting connections between multiple windows. A lot of scripters like to have little windows pop up with navigation bars or some such gizmos. But the object models, especially in the older browser versions, don't make it easy to work with these windows the minute you put a user in front of them--users who can manually close windows or change their stacking order. More recently, a glitch in some uninstall routines for Windows 95 applications can disturb vital parts of the system Registry that Internet Explorer 4 requires for managing multiple windows. A scripter can't work around this problem, because it's not possible to detect the problem in a user's machine. I tend to avoid multiple windows that interact with each other. I think a lot of inexperienced Web surfers can also get confused by them.
It could be argued that XML (eXtensible Markup Language) will obviate the need for scripting, but I don't foresee that happening too soon. XML forces the processing of intelligent documents to occur in a parser, which, for Web content, is yet another piece of software to hang off your browser. I see the two technologies coexisting for a long time to come.
The DHTML book was born out of my own frustration with DHTML documentation from the browser makers and even the W3C standards documents. Each browser's DHTML documents virtually deny the existence of the other, and the W3C presents a "perfect world" that is nowhere near implementation reality.
So, I sat down to blend all of this material into one massive reference that makes it easier to know what feature works with which browser. It turned out to be a much larger project than I anticipated. The main problem was that all of the source documents, including W3C final recommendations, were suspect. I had to try virtually every tag, attribute, style sheet attribute, object model object, property, method, and event handler on at least four browsers spread across two operating system platforms. When things didn't work properly, I had to figure out why and develop workarounds wherever possible.
A pleasant byproduct of the effort is that the HTML reference section is probably the best you can find, even if you're not doing Dynamic HTML. It all had to be covered, and I keep this book at keyboard side constantly.
(This interview was conducted via email by John S. Rhodes)
Now, what should you do?
to the WebWord.com Usability Newsletter
(c)1998 by John S. Rhodes. All rights
Do not reproduce or redistribute any material from this document,
in whole or in part, without explicit written permission from John S. Rhodes.