| Related sites for http://webword.com/interviews/goodman.html |
| Engelbart\'s_Unfinished_Revolution__Alan_Kay Brief biography, old picture. | | 360virtualworld_com Provides single shot panoramic images for web or CDROM delivery. | | Unican_GmbH Manufactures UNICAN, Ethernet, CAN-BUS cards | | RFC_0970 On Packet Switches with Infinite Storage. J. Nagle. December 1985. | | Dlog_DNC_Systems Program download directly at the control. No DNC terminal required. Direct connection of the machine to the PC. Simple serial connection of up to 8 machines. | | LimeHouse_Software_Solutions Development company using Java as preferred development platform. Primary focus is on building in-house applications, such as intranets and database driven client side solutions. | | Quetzalcoatl Cross compiler for 6502 processors, runs on Linux, Win32; can compile and link programs written in subset of ANSI C, Assembly, 1983 UPL language, or any mix thereof; can output programs for Commodore | | Rocky_Mountain_Cisco_Users_Group Brings skilled network professionals together with their peers to study advanced technologies and emerging trends in voice, video, and data networking. Contains information on the group, upcoming mee | | Oracle/PHP_FAQ Describes how PHP interacts with the Oracle Database. | | Opportunity_Interactive,_Inc_ In-home selling software, management software, and other tools and products for the HVAC industry. | | DomainingBlog_com Provides domaining articles that domainers can comment on. | | Datanumen Tools to repair corrupt files, including ZIP, Word, Excel and Outlook files. Also offer tools for database recovery. | | AdmWin System and network management software for Windows 2000. By Wennstrom Software. | | 57658 Setting the MS-DOS Errorlevel in a Program | | Cinepaint Free open source painting and image retouching program designed to work best with 35mm film and other high resolution high dynamic range images. [Linux/Windows/Mac OS X] | | MegaZot_Web_Services Web design, graphics, application development, hosting, and marketing. | | Schroder,_Kenn_-_Coaching_Sites_That_Work Web design for life, personal, career and business coaches. Includes articles, newsletter, and reports. | | SpeechGym Stuttering therapy software. | | 8_Bit_Designs Comptuers, power supplies, cables and other Commodore hardware. Under new ownership. | | acts_as_conference Annual RoR event. 8-9 February 2008, Holiday Inn Hotel and Suites, Orlando, Florida, USA. |
|
|
Interview: JavaScript and Web Site Usability
WebWord.com > Interviews
> JavaScript and Web Site Usability (20-Oct-98)
If
you want to know when new articles go online,
subscribe to the WebWord.com
Usability Newsletter!
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 [14-Jan-2001
Editor's Note: I can't point to it anymore, it is broken!], 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.
|
|
