| Related sites for http://webword.com/interviews/goodman.html |
| Morville,_Peter__Virtual_Documents__The_Challenges_of_Chunking Advice for determining a level of granularity in breaking up documents for online viewing. | | Navigation_101 A simple, understandable navigation scheme is a critical aspect of site design and has a direct effect on the bottom line. | | Nielsen_Norman_Group Reports and columns on usability and human interface design by Jakob Nielsen, Don Norman, and Bruce 'Tog' Tognazzini. | | Norman,_Don__Human_Centred_Design Don Norman discusses the approach to usability when building his own website. This includes links to related content by Jakob Nielsen. | | Pointafter_com_-_20_Do\'s_and_Don\'ts_of_Web_Usability Tips from George Prociuk. | | Principia_Hypertextica__Introduction A mathematics educator's view of web design. Encourages speed, accessibility, validity, and navigability. Discusses difficulties of math typesetting on the web. | | Publish_com_-_Flash_and_Usability Guidelines for usable Flash, By Ilise Benun. | | Readability_Of_Websites_With_Various_Foreground/Background_Color_Combinations,_Font_Types_And_Word_Styles 1997 psychology research project by Alyson L. Hill at Stephen F. Austin State University. Participants scanned simulated websites for a target word; readability was inferred from reaction | | Roger_C__Parker_-_Eleven_Common_Web_Page_Design_Frustrations_and_How_To_Cure_Them How to keep web page design from interfering with communication to visitors. | | Rosenfeld,_Lou__Is_Less_Really_More? When it comes to the usability factor of tables of contents, is less really more? | | Rosenfeld,_Lou__Yahoo!_is_Dead__Long_Live_Yahoo! Discussion on the inevitable collapse of Yahoo directory due to its size and complexity. He Predicts mini-yahoo sites within corporate intranets. | | Schaffer,_Eric__How_to_Develop_a_Corporate_Intranet_Standard_--_PDF_File From the consultants of Human Factors International (www.humanfactors.com). Requires Acrobat Reader. | | Schaffer,_Eric__How_to_Develop_an_Effective_GUI_Standard_--_PDF_file From the consultants of Human Factors International (www.humanfactors.com). Requires Acrobat Reader. | | Schroeder,_Will__Testing_Web_Sites_with_Eye-Tracking Describes an experiment carried out to monitor the eye movements of visitors to a prototype web site. | | Scottberkun_com Expert columns on web usability, interaction and web design. | | ShoreWalker Covers every area of good site design as well as what not to do. Steers you away from hype and towards more practical, user-friendly Web design. Based in Australia. | | Some_Simple_Techniques_In_Making_Your_Website_Accessible Tutorial by Andrew Pae, Technical Coordinator at the ADAPTS Office at Georgia Tech. General design principles plus resources for additional information. | | Something_4_Nothing_Web_Pages Tips for building pages which are visually pleasing, and yet still download quickly and make information easy to access. From Webdeveloper.com. | | Spool,_Jared__Hard_Evidence_from_Research Spool uncovers the lessons his research has taught him about how best to design a site so that users don't end up thwarted | | Spool,_Jared__Web_Graphic_Design_Is_Not_What_You_Think,_A_Usability__Perspective "The number one activity on the Web is information retrieval." In part of his tutorial, Spool explained his findings on graphic design and users' success. | | Starling_Access_Services Interesting definition of Accessible Web Design. For use by "anyone, any web browsing technology and any site". | | STC_SIG_-_Usability Forum to share information, resources and experiences on issues related to the usability and user-centered design. It is the home of the Usability Special Interest Group of the Society for Technic | | Stevesdomain_net Focuses on furthering the education of web related topics, including web design and navigation tips, advice and techniques. | | Szuc,_Daniel__Usability_in_Hong_Kong Interview detailing the approach to web usability in Hong Kong. | | Theory A weekly column by Adam Baker that discusses web usability, interface, and interaction design. Includes previous columns for review. | | 100_Things_to_Do_to_Make_a_Better_Site List of several (actually, eight) ways to make a more user-friendly site. Also has other reader comments on the same topic. | | Tognazzini,_Bruce__First_Principles Bruce Tognazzini discusses basic prinicples of usability for both traditional applications and web services. | | Universal_Usability Includes an online version of the book "Access by Design: A Guide to Universal Usability for Web Designers" by Sarah Horton, along with links to other useful resources. | | Usability_Engineering "Designing for Ease Use", Article written by Corporate Solutions Consulting (UK)on usability engineering. | | Usability_First Diamond Bullet Design offers their experience and knowledge on website and software usability. | | Usability_Matters From the Usability Matters Group at the Linköping University in Sweden. Their goal is to make computer systems more usable. The 1995 essay "Perspectives on Usability" by Jonas Löwgren is available f | | Usability_Must_Die Examines what's wrong with the usability movement, with some humour, and experiences from the coal face of software design. | | Usability_Professionals\'_Association The UPA's purpose is to promote usability concepts and techniques worldwide. | | Usability_gov Provided by the National Cancer Institute. Includes information and resources on making web sites and other user interfaces more useful, usable, and accessible. News and current publications and addit | | Usable_Web Collection of links and accompanying information about human factors, user interface issues, and usable design specific to the World Wide Web. | | Usable_Webs Information on basic web usability principles, including hints on helping search engines find your site. Web usability assessments and content development are available. | | Usefo_com Web design resources, Usableword newsletter, and web usability guidelines to make web sites faster, more educational, and usable. | | Useit_com Jakob Nielsen shares his thoughts on usability. | | User_Interface_Design_-_Software_Design_Smorgasbord A comprehensive resource page on UI Design, maintained by Craig Marion, the webmaster of Chester County Internet Services. | | Various__WebWord_Interviews_with_the_Experts Site includes usability articles written by John S. Rhodes. This page is a good starting point. |
|
|
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 developers 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.
|
|