Title: WebWord--Goodman
URL: http://www.webword.com/interviews/goodman.html
----------------------------------

WebWord.com : Interviews : JavaScript and Web Site Usability (20-Oct-98)

JavaScript and Web Site Usability
An Interview with JavaScript Guru, Mr. Danny Goodman

The Basics

What is JavaScript?

JavaScript is a general-purpose programming language designed to let programmers of all skill levels control the behavior of software objects. The language is used most widely today in Web browsers whose software objects tend to represent a variety of HTML elements in a document and the document itself. But the language can be--and is--used with other kinds of objects in other environments. For example, Adobe Acrobat Forms uses JavaScript as its underlying scripting language to glue together objects that are unique to the forms generated by Adobe Acrobat. Therefore, it is important to distinguish JavaScript, the language, from the objects it can communicate with in any particular environment. When used for Web documents, the scripts go directly inside the HTML documents and are downloaded to the browser with the rest of the HTML tags and content.

How is JavaScript different from Java?

JavaScript was developed by Brendan Eich of Netscape; Java was developed at Sun Microsystems. While the two languages share some common syntax, they were developed independently of each other and for different audiences. Java is a full-fledged programming language tailored for network computing; it includes hundreds of its own objects, including objects for creating user interfaces that appear in Java applets (in Web browsers) or standalone Java applications. In contrast, JavaScript relies on whatever environment it's operating in for the user interface, such as a Web document's form elements.

JavaScript was initially called LiveScript at Netscape while it was under development. A licensing deal between Netscape and Sun at the last minute let Netscape plug the "Java" name into the name of its scripting language. Programmers use entirely different tools for Java and JavaScript. It is also not uncommon for a programmer of one language to be ignorant of the other. The two languages don't rely on each other and are intended for different purposes. In some ways, the "Java" name on JavaScript has confused the world's understanding of the differences between the two. On the other hand, JavaScript is much easier to learn than Java and can offer a gentle introduction for newcomers who want to graduate to Java and the kinds of applications you can develop with it.

How can JavaScript make a Web site easier to use? That is, are there certain JavaScript techniques that make it easier for people to use a Web site?

JavaScript's greatest potential gift to a Web site is that scripts can make the page more immediately interactive, that is, interactive without having to submit every little thing to the server for a server program to re-render the page and send it back to the client. For example, consider a top-level navigation panel that has, say, six primary image map links into subsections of the Web site. With only a little bit of scripting, each map area can be instructed to pop up a more detailed list of links to the contents within a subsection whenever the user rolls the cursor atop a map area. With the help of that popup list of links, the user with a scriptable browser can bypass one intermediate menu page. The user without a scriptable browser (or who has disabled JavaScript) will have to drill down through a more traditional and time-consuming path to the desired content.

Usability Questions and Concerns

How can JavaScript be used to improve the "look and feel" of a Web site? By the same token, how can JavaScript be used to improve the user interface?

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).

Embedding JavaScript into an HTML page can bring the page to life in any number of ways. Perhaps the most visible features built into pages recently with the help of JavaScript are the so-called image rollovers: roll the cursor atop a graphic image and its appearance changes to a highlighted version as a feedback mechanism to let you know precisely what you're about to click on. But there are less visible yet more powerful enhancements to pages that JavaScript offers.

Interactive forms validation is an extremely useful application of JavaScript. While a user is entering data into form fields, scripts can examine the validity of the data--did the user type any letters into a phone number field?, for instance. Without scripting, the user has to submit the form and let a server program (CGI) check the field entry and then report back to the user. This is usually done in a batch mode (the entire form at once), and the extra transactions take a lot of time and server processing power. Interactive validation scripts can check each form field immediately after the user has entered the data, while the information is fresh in the mind.

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.

How can JavaScript be used to personalize or tailor a Web site to fit
individual users?

JavaScript allows a Web page to perform "if-then" kinds of decisions based on browser version, operating system, user input, and, in more recent browsers, details about the screen size in which the browser is running. While a server CGI program can make some of those same kinds of decisions, not everyone has access to or the expertise to create CGI programs. For example, an experienced CGI programmer can examine information about the browser whenever a request for a page is made; thus a server so equipped might serve up one page for Navigator users and a different page for Internet Explorer users. Beyond browser and operating system version, a CGI program can't know more about the environment. But a JavaScript-enhanced page can instruct the browser to render only certain content based on the browser, operating system, and even the screen size.

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.

Are you concerned that older browsers don't support JavaScript and thus exclude a set of Web users?

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.

Tips, Techniques, Resources, and Beyond

What and where are the best JavaScript resources on the Web?

The Web has several FAQ areas on JavaScript. The best place to start is something called the meta-FAQ, which provides a high-level overview of the JavaScript help available on the Net. As for fact-filled FAQs, I recommend one maintained by Martin Webb and a mini-FAQ that I maintain.

For interactive help with specific problems, nothing beats the primary JavaScript Usenet newsgroup, comp.lang.javascript. Depending on my work backlog, I answer questions posted there from time to time. Netscape and Microsoft also have vendor-specific developer discussion groups as well as detailed documentation for the scripting and object model implementations.

What are the problems associated with using JavaScript, and are there JavaScript techniques that you discourage?

Browser version incompatibility is the biggest problem. It requires knowing how each scriptable browser version implements its object model. You see, the incompatibility rarely has to do with the core JavaScript language (although there have been improvements to the language over time); the bulk of incompatibility issues have to do with the object models that each browser version implements. For example, scripters who started out with Navigator 3 implemented the image rollover because it looked cool. But they were dismayed to find out that the image object wasn't scriptable in Internet Explorer 3 or Navigator 2. While there are easy workarounds to make this feature work on newer browsers without disturbing older ones, it was a painful learning experience for many.

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.

Taking a developer’s perspective, do you think that that JavaScript is easy to learn and use?

One of the reasons JavaScript has the word "script" in it is that as a programming language, the vocabulary of the core language is compact compared to full-fledged programming languages. If you already program in Java or C, you actually have to unlearn some concepts that had been beaten into you. For example, JavaScript is a loosely typed language, which means that a variable doesn't care if it's holding a string, a number, or a reference to an object; the same variable can even change what type of data it holds while a script runs.

The other part of JavaScript implementation in browsers that makes it easier to learn is that most of the objects you script are pre-defined for the author, and they largely represent physical things you can see on a page: a text box, an image, and so on. It's easier to say, "OK, these are the things I'm working with and I'll use scripting to make them do such and such," instead of having to dream up the user interface, conceive of and code objects, and handle the interaction between objects and users. With scripting, you tend to write a _lot_ less code.

What Web sites do you feel use JavaScript most effectively (i.e., best-in-class examples)? The worst?

The best sites are the ones that use JavaScript so transparently, that I'm not aware that there is any scripting on the page. The worst sites are those that try to impress me with how much scripting is on the page.

Why do you think your JavaScript Bible (3rd Edition) has been so successful?

I've been writing about these kinds of accessible scripting languages since the mid-1980's so I have developed an instinctive feel for what experienced programmers and complete newbies must know to use a technology like JavaScript. I'm up to my elbows in JavaScript every day, so I experience the same pain of incompatibility and security restrictions that my readers do. I get a lot of e-mail from readers who say that I understand what real-life scripting is all about. I'm really just trying to help readers avoid all the problems I suffered through while encouraging them to expand their powers through JavaScript.

Why don't you use JavaScript on your Web site?

That's a wonderful compliment. While I don't have any JavaScript on my home page, there is a fair amount of JavaScript working behind the scenes in many areas of my Web site. For example, in all of the Support Center regions for my books, scripts highlight items that are new since your last visit, no matter how many times I may have modified the pages. There is no JavaScript on my home page, because the design does not yet require any value that JavaScript could add. That may change in the future, but the point is to use JavaScript to enhance the experience without the user's knowledge, without getting in the way of content.

What is the future of JavaScript?

The core language is filling out nicely with the versions implemented in Navigator 4 and Internet Explorer 4. There will certainly be some additions to the core language, but all parties are on board to filter them through the ECMA standards body. If a new kind of software is under development that has as one of its features a scripting language, it would be foolish to design a brand new language just for that purpose. It would be better to do what Adobe has done: implement JavaScript as the scripting language, and let the product's object model differentiate itself from competition.

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.

Please briefly tell us about your new book, Dynamic HTML: The Definitive Reference.

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.

Please feel free to share with us any final comments, concerns, or important advice.

I believe the biggest problem facing newcomers to JavaScript is following the gospel according to one browser maker or the other. If you are designing pages that must be viewed by all types of browsers, it's best not to get too deeply in your design and scripting without knowing what's possible in numerous browser versions. This is very tough to do because it steepens the learning curve. But you'll waste a lot of time if build a grandiose scripted page on one browser and only then try it out on others. The earlier you can determine the common denominator of scriptability for your audience, the quicker you'll have something to deploy to the widest audience.

Thank you Mr. Goodman for your excellent answers and outstanding advice.

(This interview was conducted via email by John S. Rhodes)

Now, what should you do?

If you want usability news, tips, and tricks, or if you want to know when new interviews go online, subscribe to the WebWord.com Usability Newsletter!

Recommend this JavaScript interview to a friend
Read another popular interview: Web Marketing Research
Feel free to create a link to this interview, but please do not copy or redistribute it in any form without my permission.

Subscribe to the WebWord.com Usability Newsletter
Receive the best free usability newsletter on the Internet.

Contact John S. Rhodes, the WebWord.com Editor and Webmaster

URL: http://www.WebWord.com/interviews/goodman.html

(c)1998 by John S. Rhodes. All rights reserved.
Do not reproduce or redistribute any material from this document,
in whole or in part, without explicit written permission from John S. Rhodes.

----------------------------------
Converted By:
http://pilot.screwdriver.net

<ž>