This page is very large, more than 150K. It also pulls in about 200K of images. With a 14.4 modem, it will take at least 5 minutes to load.
Comments or suggestions?
This is a cookbook for helping people create better web pages. The guidelines presented here represent the opinions and preferences of a small group of people within Sun who have created some web pages, and have looked at many more. We've drawn from our own observations, opinions and judgements about what makes web pages better or worse, as well as extrapolating from the existing body of usability and user interface design literature.
Take everything here with a proverbial "grain of salt." You may strongly agree with some of the suggestions, and others may provoke vehement dissent. I welcome your comments, positive or otherwise. If you discover particularly illustrative examples for any of the guidelines here, drop me a note. I'll try to use them in future revisions.
Table-aware browsers: peculiar symbol alert
A guide for the perplexed.
The form of this style guide is a tad experimental. The index file points to a script that will re-direct the viewer to either a version with or without tables, depending on the type of browser they're using. I'm breaking one of our rules, which is to avoid browser-dependent code, but the <TABLE> construct has the potential to greatly improve information presentation. Hopefully, there is enough extra value for our readers to justify the extra constraint. In any case, use a version of Netscape from release 1.1 onwards to see our peculiar design, and let me know what you think.
In the table version of this guide, I'm trying to present as much information on the front page as I can, to minimize page links that might cause our audience to lose their context in the document. There are two graphics that represent special links, and may need some explanation. (In which case, many will argue, the experiment fails.)
The guidelines presented in this document are organized into topics,
which are listed in the left-hand column of this page. Each topic
is followed by link symbol,
,
which, when clicked, will present an overview of a topic,
in context, on this page.
Welcome
,
is also a link. The arrow changes color and the symbol changes to a pointer
to indicate which section is currently being viewed:
Welcome 
Graphics
A second peculiar graphic element,
,
follows guideline summaries in the
right-hand column of this page, as well as on the Quick Reference page.
If reading this long-winded explanation is actually required to understand this page design, I'm probably headed back to the drawing board, but thanks for reading it, and please do comment.
The examples of good and bad practice used in this document are taken either from web pages created by people at Sun, or from publicly available pages on the Internet. The problem with citing web pages is that they change too much. What may be a sterling example of a particular technique today may be swept away by the site's authors as they try to keep their site fresh and innovative. (We've discovered that the rate of change is even faster when you point to a page as an example of bad design practice :-)
In an effort to work around this fluidity, many of the examples cited here will point to excerpted elements from the referenced web site, which are cached on this server. When this occurs, we'll offer a link, near the citation, to the source site.
This "live" link will point to the current page on the referenced site, so people can see the up-to-date version of our example.
In addition, the cached example will be no more than a single page of the referenced site. When a reader tries to follow a link that leads beyond the example page, they'll get a polite note explaining that they're looking at a cached example, and they'll be offered a link to the live version of that example.
Many people helped in compiling and reviewing this document.
Special thanks go to:
They (and other people I'm sure I've forgotten) provided welcome guidance, support, criticism and ideas. All errors and inaccuracies are my responsibility alone.
The Sun Guide to Web Style is generated from a slightly formatted text file by a perl script, which creates versions for both table-aware and non-table-aware browsers. Graphics work was done on a Macintosh Duo, and perl development alternated between the Duo running MacPerl and my Sun workstation.
|
|
|
|||||
|
|
||||||
|
|
||||||
|
Early in the process of creating your web pages, you should spend some
time articulating the goals for your documents. Web pages can be
categorized by purpose. Being responsible to a specific purpose can
dictate certain design choices.
|
||||||
|
HTML browsers can be used with some facility to create form-based user
interfaces (FUIs!) that allow people to choose products to buy, configure
computers or search for information, to name only a few uses. Web
pages that present these kinds of user interfaces must be easily
understood with a minimum of study and documentation. Well done, they
can be easily scanned and the expected actions inferred from the
layout and controls. Pages tend to be short, uncluttered, and easily
navigable.
This is a bookstore interface that allows people to search an inventory list and place orders on-line.
|
|||||
|---|---|---|---|---|---|---|
|
Information presentation on the web has many guises. If you're
selling something, you need to present things very succinctly,
especially if you're trying to "hook" a person who may be a reluctant
reader. Everything that you do in your design that forces a person to
search, navigate or otherwise use their browser's controls will reduce
your chances of getting them to read to the end of your pitch. Lots
of detail and presenting many branches (which may work well for other
types of web information) can confuse and frustrate your audience.
This graphical product presentation is easy to scan, and allows easy recognition and evaluation of potential products. (It's also a product line well-suited to this presentation, being hard goods that photograph well, rather than less visually differentiated goods, or worse, services.) (current)
|
|||||
|
Sometimes, you can assume that many of your readers will arrive at
your page because they need and want the information you're
presenting. You can use longer pages, present more detail, and worry
less about "channel-switching" behavior on the part of your audience.
There's a tension between the amount of "packaging" that you do to
your content and your audience's desire to get the information they
need as efficiently as possible. What might be a good format for a
product advertisement could fail dismally when presenting product
documentation because of the frustration incurred when people are
forced to navigate and visualize a web of short segments, and are
given tantalizing but incomplete glimpses of the answers they need.
Much of HotWired's presentation approach uses longer pages, and narrower columns. This column by George Lin is also notable for its use of marginal notes, and a very readable table-based layout that starts to resemble more familiar, paper-based page design.
|
|||||
|
Many of the web pages you will see are lists of references to other
things. This is the easiest kind of web page to create, as
it requires the least amount of original content. Many of the pages
in our personal "hotlists" are such lists, collections providing
references to bits of information that we find useful. The most
successful of these are those lists that annotate and categorize the
items they present, providing value beyond a rote recitation of
pointers.
This list, Quality, Guidelines & Standards for Internet Information Resources from the Australian National University, is an excellent resource because of its authors have qualified and evaluated many of the resources listed.
|
|||||
|
Some of the design decisions you will make when creating your web
documents have very different answers depending on your intent.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
The more specifically you can catalogue the needs of the people reading your
web pages, the better you'll be able to meet those needs.
|
|||||
|---|---|---|---|---|---|---|
|
|
|||||
|
If your documents will be read by your customers, familiarize yourself
with the particular segments of your customer base that will find your
information useful, and the problems that they will be attempting to
solve as they read your pages. Even if your pages are destined only for
use within your company, you should try to do a similar categorization
of the potential readers of your pages.
|
|||||
|
Understand the consequences of optimizing for a particular web browser. Usually, you should not make assumptions about how someone will be viewing your web pages. You should try to accommodate people with a wide range of viewing capabilities, from those with text-only browsers on slow links, to true techno-dweebs with fast, 24-bit color displays served by high-bandwidth direct network connections. There are some cases where you may need to use the features of a particular browser to present your information well. However, these cases are much rarer than you might think. In this style guide, I've fallen prey to the appeal of Netscape's <TABLE> construct. On the front page of the document, the side-by-side layout makes for arguably better information presentation. However, using the fancy formatting toys came with a price: I had to create a version that doesn't use the Netscape extensions, as there are and will continue to be many people in our audience who use other browsers.
|
|||||
|
Generally, the slower the link over which your reader will be
retrieving your web pages, the more important it is that you maximize
"value" and usable content, and minimize document size and load time.
Most of the differences between design for web-based media and design for
more common computer and traditional media design revolve around
perceived performance, and the ways in which the performance unpredictability
of internet connections will affect your audience's perception of your
product quality.
The degree to which you use graphics, the size of your images and overall pages, and the way in which you partition your information will be perceived differently depending on the speed and quality of a reader's internet connection.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
The presence and placement of links affects the utility of your pages.
Links provide connections to other content, organizational markers and
a means to define terms and provide references. Links can support or
detract from your presentation.
|
||||||
|
Don't refer to the mechanism of the web, and don't attempt to guide or
instruct your reader.
is much preferable to either:
(Web-based user interfaces to services or procedural tasks do need to provide guidance and instruction for users of the interface. Decide which you are about, providing content or procedural guidance, and design appropriately.)
|
|||||
|---|---|---|---|---|---|---|
|
Your reader should be able to scan the text of your links and learn
something about their destination without much reference to the
surrounding text. "Telegraphic" links, those that use cryptic or
obscure language, force the reader to follow the link
before they're sure the information at the other end is worth
reading. If it's not what they want, their time is wasted and they
often have to back up to continue.
|
|||||
|
A single word may be too small a target, and may not be
meaningful.
|
||||||
|
Write surrounding text so as to help people understand what the link
does. Help your reader understand where links lead, and what sections
contain. They're paying a time penalty for every link they follow.
Help them understand what value they will receive if they traverse a
link. Be critical of each link: if your surrounding text does not
accurately predict the destination, examine that text or, more
fundamentally, the reason for having the link.
|
|||||
|
Adding a link to text does emphasize the word or phrase containing the
link, and can actively make the text more difficult to read. This
example hides the useful destination of the link, the Internet
Advertising Resource Guide:
Again, this is a better passage:
|
|||||
|
It's an impossible task to make the text displayed in a link match
the title of the destination page. It also makes for maintenance headaches
as the titles of documents change. Try to choose link text that has
a conceptual similarity to the title and headers of the destination
document.
|
|||||
|
When using lists of links with similar text, use links to
highlight those words or phrases that are different, rather
than highlighting the entire phrase:
Application summaries for Engineers
Application summaries for Engineers
|
||||||
|
The convention that's evolved among creators and users of web browsers
is that links that have not yet been followed use a brighter
or higher luminance color than those that have already been traversed.
(For many browsers, they're shown
in shades of purple or blue) When you change the link colors, you
can easily reverse this brightness mapping, or worse, choose colors
that read at the same level of brightness. Don't do it.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
Like the fold in a newspaper, the bottom edge of the browser window
will stop some people from reading further. If the page is only as
long as the default browser window, your reader will see all that you
present in a glance, and won't have to guess about what's below the
edge of the window.
|
|||||
|---|---|---|---|---|---|---|
|
This screen from a prototype interface for SunSoft's
DriverExpress
service has buttons at the bottom that will never be used as they are
hidden below the edge of the window.
|
|||||
|
If the content you present is in the form of short, loosely connected
blocks, you must depend more heavily on layout and typography to
organize your presentation. Keeping pages short will reduce the
possibility that a block will be "orphaned" beyond the bottom edge of
the browser window.
|
|||||
|
Scrolling the browser window allows a reader to advance in the text
with less loss of mental "context" than does following a link. This
advantage lasts up to about four screenfuls of text. After that,
there is a tendency for people to lose their context, and get
frustrated with the mechanism of scrolling, and their inability to
keep track of what's elsewhere on the page.
Karl Signell's Reading a Web Page is an example of a page intended to be read, rather than glanced at. The content obviously continues beyond the window. There is a rhythm established for a reader by your text, typography and layout. Retrieving a new page by clicking on a link introduces a delay that will break that rhythm. This unavoidable pause of a few to many seconds is something that you must take into account when deciding how long a page should be.
|
|||||
|
If you have doubts, ask for feedback from members of your intended
audience.
|
|||||
|
If you have long documents that people will want to print or save in
one operation, provide a link to a complete, print- or save-able
document, rather than trying to cram lots of content into one page.
|
|||||
|
If you're going to be changing your documents frequently, it's usually
easier to swap several short files than change the middle segments of
longer ones. (And if you break something, your whole web isn't out of
commission!)
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
Images can add a lot to the visual appeal and information
content of a page. For some subjects and some readers, images may be the sole most
effective means to communicate your message.
Well-used graphics can crystallize a presentation for a reader, providing a critical catalyst for understanding. Used poorly, images can confuse your audience, distract from your message, and render mute a critical message.
|
||||||
|
Provide images that help explain or demonstrate your subject. Each
image you include in a page will increase the time it takes to load that page.
When you include an image, be certain that it's essential to the presentation.
"Essential" can go far beyond images that present information, such as maps, charts
or documentary photographs. An image may be an important navigational aid or locator,
or may be the most effective means to organize page layout, or help set readers'
expectations about a site. Review your images with a critical eye
and delete the nonessential ones as quickly as you strike fluffy text paragraphs.
|
|||||
|---|---|---|---|---|---|---|
|
Sites that use
full-page graphics with image maps as the top-level "welcome page" for
the site are fairly common. Some are well done, but many are using a
top-level image map because it seems to be something that "everyone"
does. Your readers will put up with this technique if it's used
very sparingly. Once on the top level might be appealing, appearing
on two levels will raise eyebrows and three or more levels will
frustrate people. If the top-level image isn't an image map used for
a navigational visualization of the site, or a critical
content-related image, consider eliminating it, or making it much
smaller.
|
|||||
|
If a single image is critical to the information being presented, it's
alright to be larger, but consider using a thumbnail of the image and
linking to the full-size copy. If the image won't survive being scaled
down to thumbnail size, try using a small portion of the image for the
thumbnail.
|
|||||
|
There are several available techniques to minimize download times for images:
|
|||||
|
Some browsers do not support JPEG images, and those that do may not
present them in-line. This can change the impact of your presentation.
Unless you know the browser usage patterns of your audience, opt for
fewer JPEG images.
|
|||||
|
Adding text to a link citing the size and format of the linked-to file allows people to
decide if they want to take the time to retrieve the file. This is especially kind
in situations where you have created the expectation that graphics in a series are a
certain size, and you
betray that expectation with an image that is much larger. In all cases, you need to
ask yourself if an image you're offering is worth the download time. If it is, and
your audience agrees, they'll suffer the wait.
|
|||||
|
There are some creators of web pages who have 24-bit, full-color
displays, and maintain that their content just doesn't look as good on
more pedestrian 8-bit, 256-color hardware. This may be true, but the
majority of your audience doesn't have fancy hardware. Design your
pages so that they look good on 256-color screens. 50 colors is
reasonable limit. Try to use the same color map/table for all your images,
especially those that appear on a single page.
 :
Netscape Color Tables
|
|||||
|
Loading each image requires a new connection between the user's
browser and a web server. For users on
low-bandwidth connections, or those connecting to overloaded servers,
one large image may load faster than
several smaller ones, because of the elimination of multiple
browser/server connections.
Users on higher-bandwidth connections going to fast servers may benefit
from having multiple smaller images, as some browsers will make multiple
simultaneous connections to a server to retrieve images.
Understand your audience and their typical bandwidth and browser usage,
and choose appropriately.
|
|||||
|
Use the <...ALT="description"...> parameter in your source to specify
the text to be seen by people with text-only browsers, or those who
choose to turn off image display while they're browsing. (It will
also help visually impaired folks using screen-reading software.) The
text description should be succinct and summarize the content or
purpose of the image.
|
|||||
|
By setting the background area of a .GIF image to "transparent," you allow the
background color of the browser page to to show through. This can add to the
visual appeal of a page, yielding a more finished, integrated look. In addition,
this is the only way to get non-rectangular images in your page.
:
Transparent Backgrounds for Images
|
|||||
|
Using a graphic file by reference from a site on a different network
can cause delays in loading a page. In
addition, if an image file cannot be loaded, or the user hits their
"stop" button after they get the text, but before the images download,
the browser will use a canned "default" image.
This "default" image may be larger than your graphic, especially for small
bullets and accent graphics, thus
doing interesting and usually detrimental things to your layout. Make sure
all your graphics are accessible to the server delivering your pages.
|
|||||
|
Graphical bullets can reinforce page layout and cohesiveness, and can add
information to a list or clarify its contents. Poorly employed, they can
make your page layout look haphazard and unprofessional.
Use graphical bullets to:
|
|||||
|
An image file used as a divider can add a very effective accent to a
page, while only adding slightly to page load time. However, they are
slower than the built-in horizontal rule function defined in HTML.
An effective use of a separator may be to highlight out-of-context or
parenthetical content, or to denote the periodic appearance of a
particular kind of content. Using too many horizontal rules can break up
the sequntial flow of a page. If there are many horizontal rules on a
multi-screen page, each segment of the page can begin to look like the others,
possibly confusing a reader trying to navigate the document.
Use bars with smaller image file sizes rather than larger, and use a small set repeatedly, rather than a large number only once each, to maximize use of the browser image cache.
|
|||||
|
Because many HTML browsers cache images as they are loaded, you can
achieve fairly fast download times if the images you require are
mostly loaded from the image cache rather than being downloaded
repeatedly. Using many unique images, or identical images with differing names,
negates this advantage, as well as having a potentially disunifying
effect on your document.
|
|||||
|
If you must use background images, keep them very small (to minimize
download time,) and use the lowest
resolution JPEG format. If you're fond of creating your backgrounds on a
computer with a high-color display, make sure you try living with them
on an 8-bit tube. Text/ground combinations legible on a 16- or 24-bit screen are sometimes
unreadable on a 256-color system. Keep backgrounds pale and muted, to
avoid interfering with text. Better yet, unless you're comfortable that the
core audience for your site either has the bandwidth to load large images quickly,
or doesn't mind waiting, consider not using a background image.
A valid rebuttal to this approach is the observation that backgrounds can provide a strong thematic design element for a page. Boldly colored backgrounds can support legible text, if the designer takes care to choose properly contrasting text and ground colors. Another option is to use a large background image, and place text over quieter areas in the image. Yet a third approach is to put the text in the background image, as in this example from ISS digital contractors. (current) There is no "right" answer to this debate, merely choices more or less appropriate for a given audience.
|
|||||
|
Explicitly setting the text color on a web page comes with some
interesting human costs.
Are you sure that people with varying forms of color-blindness can
still read your message? Is the text readable on the background you've
chosen? Is the text still readable if your audience shuts off backgrounds
and opts for the browser default? Computer displays provide much poorer
fidelity than do paper-based media. The (hopefully short-term) problem
with treating a browser page like a magazine page is that a page on a
computer display is a much cruder presentation. The designer's options for
using
subtle nuances of color and type to improve the readability of a design are
severely curtailed when working with 256-color, medium resolution computer
displays.
|
|||||
|
Because of differences in low-level rendering sotware, and the gamma values
for monitors typically used with some hardware, the same image can appear
lighter or darker on different platforms. Faces which look good on a
UNIX platform can block in completely, losing much detail, on some Macintosh
screens. Images created to look good on Macintosh screens may appear washed-out
on VGA displays or UNIX workstations.
Examine your images on at least two
systems: a Macintosh with a built-in display and a PC running Windows 3.1.
Try to get to a monochrome UNIX X-terminal as well, especially if corporate users
figure substantially in your audience.
Two places to look for more information about gamma and creating images for various computer displays are Poynton's Color Technology Page and Making Good Cross Platform And WWW Pictures.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
In today's web browser implementations, image maps, the clickable
graphics used on web pages, present a rather poor user interface.
Unless the image itself has well-delineated "active" regions, there is
no clear indication of where a user should click. Having clicked,
there is no feedback to indicate that a user's click has been
recognized by the browser. (Java-capable browsers may fix both these
problems in the future.) The only sure cure with current browsers is
to not use image maps! Having said this, and recognizing that:
follow these guidelines:
|
||||||
|
The navigation bars at the top of many of Sun's web pages have clearly
defined rectangular regions.
|
|||||
|---|---|---|---|---|---|---|
|
Also in our header bars, the home and search "buttons" look like buttons.
This example from USA TODAY'S public on-line site is an excellent illustration of both of the last two guidelines. (current)
|
|||||
|
If there is any ambiguity about where to click on an image map, or
what the destination of the links will be, describe the actions
required and the effects of following the link to your audience.
|
|||||
|
This helps the people using text-only browsers, those who choose to
browse with their images turned off, and those of us who might not be
able to figure out what your image is supposed to do. If there are
a large number of image-map destinations, and including links to all
of them force using short link descriptions, you might be better off
moving the list to another page.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
If yours is an essentially hierarchical document having chapters or
other predictable sections, consider adding a heading on each page
that links back to beginning of the document. Also, for pages within
each chapter or section, add a secondary header that takes readers
back to the beginning of that chapter.
|
|||||
|---|---|---|---|---|---|---|
|
If your pages are consistently longer than one-and-a-half
screens, it may be valuable to repeat any navigational links at the bottom
of a page as well as putting them at the top, to help readers navigate
without forcing them to always scroll to the top of your pages. If repeating
the same navigational aid would look awkward, try a simplified version,
offering only essential destinations
|
|||||
|
You have no way to predict whence someone came. Describe the
destination of the link in absolute terms, rather than using implied
destinations. "Previous" and "next" assume that people can predict
your structure, and that they can quickly return if the destination
wasn't what they expected. Neither of these assumptions is likely to be true.
Your document structure will probably be foreign to many of your
readers, and many of them will be running over low-bandwidth
connections. A phrase that describes where your link leads such as
"Ahead to Chapter 5: Quality" is better than an unadorned "Next."
Better (and only slightly more difficult to design) is to use a
navigation scheme that employs concrete navigation links connecting a
small number of topics.
|
|||||
|
Most people will not be spending enough time looking at your pages to
learn the meaning of the buttons. In addition, people will be
creating links to your pages from other pages with dissimilar
navigation landmarks. Icon palettes work in large, widely used,
closed systems, and are often combined with other, textual navigation
hints.
|
|||||
|
That way it will be easier for people to decode your symbols.
|
|||||
|
Even if you do so for no other images, supply text labels for any
graphical navigation buttons.
|
|||||
|
If the page is long, with several distinct sections that are
not visible from the first screenful, add a short list of the
sections. On a long page or a web of related pages, this serves two
purposes. First-time readers get a sense of what to expect from a
section. Returning readers can tell more quickly if a page contains
what they need, and navigate more rapidly to the destination they
want.
|
|||||
|
It doesn't need to be large and bold, as long as it's recognizable as
a title, separate from the rest of the page content.
|
|||||
|
The title that appears in the header of the browser window should
match the HTML page title. Try to have a unique title for each page.
On pages that are essentially similar to their peers,
such as the possibly machine-generated pages in catalog offerings,
unique titles can be a reader's navigational lifeline.
|
|||||
|
You'll frustrate your audience if you try to use the title as a "bait
and switch" tactic to get them to read your page. Meaningful titles save
your readers time when they are included in hotlist or search result lists.
Your pages will be scanned by programs to extract titles, addresses, link text,
and other data for indexing purposes.
|
|||||
|
For sizable document webs, or even smaller webs with non-obvious
structure, provide a search service if that will improve
retrieval and accessibility.
Clearly state the scope of the collection being searched.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
Any established security and proprietary information policies
that your company follows probably apply to web documents.
If you aren't sure what those
are, ask someone, preferably before you publish anything.
|
||||||
|
If the information you're writing is proprietary enough to rate
numbered copies, why are you bringing it anywhere near a computer
network? There might be supposedly secure mechanisms for distributing
such documents, some might actually be secure. But are you or
your company using one? In many cases the answer is "no."
|
|||||
|---|---|---|---|---|---|---|
|
Many companies have a policy that allows publishing of limited
distribution documents if you use adequate file
permission security or http passwords to limit and control access.
Unfortunately, using file permissions with web documents requires
being able to reliably authenticate the person requesting the
document, which is very often not the case with web browsers.
Until you have a server deployed that
supports secure transactions, you should probably avoid posting
limited distribution information. If you do decide to post,
follow the Standard for Robot Exclusion, below. In any case, you
probably do not want a link from the company home page to your
information!
|
|||||
|
Make sure you have a firewall or other internal/external security
mechanism before you post things that need to be seen only
by employees of your company.
|
|||||
|
There are web robots that regularly search and index many of the
publicly available web servers.
They provide the data pools that make web search services work.
If you do not want this to happen to particular documents on your
public server, follow the
suggestions in
A Standard for Robot Exclusion, and set up or ask your
system administrator to set up a /robots.txt file.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
If people hit dead ends, they get frustrated. People make a very
direct connection between the perceived fit-and-finish of your pages
and the perceived reliability of the information. If they get lots of
errors and cannot follow your links, they will not stick around to
read your pages.
|
|||||
|---|---|---|---|---|---|---|
|
Until there are reliable WYSIWYG tools for creating HTML pages, use a
utility to check your formatting. Yahoo provides a
good starting point for finding tools.
|
|||||
|
Check regularly for external links that don't connect. To preserve
your sanity, if you're maintaining a sizable web, explore using an
automated mechanism to do your link checking. MOMspider is a
publicly available example of such a tool.
|
|||||
|
If you're fortunate enough to be creating HTML pages in an editor with
a spell-checker, please use it. Otherwise, dump the text to someplace where you can check
it for errors.
|
|||||
|
Edit your documents or get someone to edit them for you.
|
|||||
|
If you are creating pages that must be interpreted with a particular
browser to be useful to your audience, be very certain that your
audience is using the browser you expect. Don't use special features
gratuitously. People usually value content over overtly clever format and flash.
|
|||||
|
Human physiology has us wired to treat motion as a high-priority
visual stimulus. People notice change or motion more readily than
color or size. text on a page will draw a
reader's eye, away from all other text or image content. There are very
few visual problems which must be solved with blinking.
There may be some situations where you want to distract people, or highlight a single element in a layout at the expense of all the others. Using blink is a bit campy, but might be appropriate if used very, very sparingly. The best use of blinking text that I've seen is to highlight error conditions in an otherwise complex, colorful and static display. Try looking at an HTML source file in the Netscape 2.0 built-in source browser, after first removing the trailing double-quote after an HREF.
|
|||||
|
By supplying the date of a page's last revision, you provide an
indicator of currency for the information you are publishing.
Ideally, especially in a large document, you should date pages
individually, rather than having the same date on the bottom of every
page. Because of the likelihood of international access to web sites,
use a date format that positively identifies the month, such as "2-APR-95"
or "April 2, 1995". (Both "2-4-95" or "4-2-95" are legitimate references to the second of April,
in different parts of the world.)
|
|||||
|
Use either a mailto: link or a link to another mail comment form.
Make it easy for your audience to comment on your documents.
Encourage them to do so.
|
|||||
|
Pay attention to their feedback, respond to it, act on it, and thank
them for taking their time to help you.
|
|||||
|
There are many
HTML conversion programs available that can help you to convert from a
particular word-processor or electronic publishing format to
HTML. Very often, however, the way the source
document is organized is unsuited to hypertext presentation. In addition,
the intrinsic document structure imposed by the limitations
of the word-processor or e-pubs package will translate into
stilted web documents. Evaluate your results not by how successfully
the conversion processing went, but by the effectiveness of the end-product
as a web document.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
A few things that your mother probably told you, but bear repeating.
|
||||||
|
Only post things in good taste. No chain letters, derisive comments
or inflammatory remarks.
|
|||||
|---|---|---|---|---|---|---|
|
Get explicit, written permission to reproduce copyrighted material.
If you're going to be giving your content to someone else to maintain,
Make sure the permissions get handed over with the documents. Brad
Templeton's
Ten Big Myths about copyright explained is a must read.
|
|||||
|
Do not reproduce trademarks or trademarked logos if there is a
possibility of someone attributing your product to the owner
of the trademark or logo.
|
|||||
|
While many documents you will encounter are meant to
be re- used and linked-to, some aren't. Unless it's very obvious that
the author of the document in question is creating a public resource,
ask for permission before creating a link.
|
|||||
|
Sadly, the mail links that appear on the bottom of many documents are
rarely used. It might say "webmaster" on the link, but every document
you see (yes, even the script-generated stuff) was conceived and
executed by a person. Send mail. Tell them what you liked and
disliked. Be a mensch.
|
|||||
|
Try to publish documents that provide value to a broader audience
than just your design center. As a distribution medium, the web
can provide a channel for specialized content that would be
an economic impossibility in other media. However, many sites that claim
to cater to very specific audiences have information with a much broader
appeal, or information which, if only slightly enhanced or re-organized,
would be useful to a much larger constituency. Once you've defined your
target audience, and created the perfect site for their needs, try to
find low-effort changes that might enlarge the group of readers who
will find your information useful.
|
|||||
|
Publish things that solve peoples' problems.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
When creating a web offering that lends itself to a hierarchical style
of organization, it's fairly easy to arrive at a presentation that
requires a person to navigate several thinly populated "menu" or
"index" pages before they get to real information. It is beneficial
to "flatten" your hierarchy, providing more information sooner. In
addition, try to avoid value-free intermediate pages.
|
|||||
|---|---|---|---|---|---|---|
|
Given that at least two levels of hierarchy are probably unavoidable
(a top level index, and second-level content pages,) try to provide
valuable content on your top-level page.
|
|||||
|
One measure of success for web pages is getting people to put your
page on their "hotlist" or list of bookmarks. The richer your pages are
in needed information, the more likely people will be to return to
them.
|
|||||
|
One of the more interesting results from our usability tests is that
people sometimes don't like to read web pages. They will skip over
text that they consider non-essential. They don't like to scroll.
Often, your audience will
skim your text, only reading the text of the hypertext links before they
choose their next destination. It's not clear how much this behavior is linked
to the basic crude legibility of computer displays, or the extent to
which the behavior is tied to personal browsing style or situational context.
However, the pages that seem be the most successful are those that use a "bursty" style. Short, factual, well-written, prose with interesting links seems to attract the biggest audience.
|
|||||
|
Often, you can't predict how knowledgable your audience will be
of your subject matter. Provide links to information that can help
a less knowledgeable person bring themselves up to the level of your
presentation.
|
|||||
|
Much information you'll see on the web is static. It changes seldom,
if at all, after it's written. Some however is intended to be updated
over time, possibly frequently. Give you users clues about that information
will be updated, especially if you're mixing static and dynamic data.
|
|||||
|
Visually impaired users may have selected much larger fonts.
Many users will turn off backgrounds, and color and font over-rides.
Browsers differ in how they implement rendering of white-space.
Some browers will give end users far greater control over the use
of colors, fonts, spacing and other presentation attributes.
A classic abuse of headers is to use <H5> or <H6> to mean "smaller font," which
is not what the HTML specification defines or what some browsers implement.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
If you're trying to sell a product:
|
||||||
|
Put answers to the obvious questions people will ask close at hand,
either on one page, or under well-labeled links. A focused
presentation will allow people to get the information they need
efficiently.
|
|||||
|---|---|---|---|---|---|---|
|
Don't make people scroll or unnecessarily use their browser controls.
|
|||||
|
If your product is complex enough that you cannot provide all the
information someone needs in one presentation (and most of ours are
that complex,) make it easy for them to get more information. Provide
links to more resources, and a mail link with a fill-in form that
allows them to state the questions to which they need answers.
|
|||||
|
If you're going to talk about a product your company sells,
explain how to order one.
You can point to somewhere else, but make very sure that the
destination is the place with succinct, accurate information on how to
order the product you were describing. If your business depends on selling
things, talking about a product without providing the opportunity to
make a sale is bad.
|
|||||
|
When someone follows a link to another site, they may not come back.
If you link to a sub-page of a competitor's site that has their
(supposedly inferior) competitive offering, you're begging them to
customize that page to effectively counter your pitch. (And they will
find out about it.) You may have good reasons for linking to competitors,
but make sure they're good ones.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
Jutta Degener
has written
Dangerous Words, cataloging
some of the most common traps that a writer of web documents may
encounter. I've reproduced her list here, with permission.
(Jutta's
What is Good Hypertext Writing is an excellent, succinct
introduction to writing for hypertext. I am maintaining a
local
mirror of that document
of that document, if the original proves difficult to retrieve.)
|
||||||
|
Almost always redundant. If the things you are linking to
weren't available, you couldn't link to them in the first place. Some
of the style guides in the related material section recommend
replacing every occurrence of `Click here to go to X.' by
`Information on X is available.' The main effect of that change is
that it shows you've read one of those style guides.
|
||||||
|
Which way leads `back' depends on the direction your visitor came
from. Describe the subject of the page instead, or use absolute
directions.
|
|||||
|
A meaningless buzz-phrase that often camouflages the
speaker's lack of enthusiasm for whatever it is that you're supposed
to visit.
|
|||||
|
Some of your readers will not be able to click; use `select
this' instead of `click here', if you must. (Better, avoid talking
about the document in the first place; write about the subject
instead.)
|
|||||
|
An overused buzzword. Try to describe why, not just that, you
like it.
|
|||||
|
Often redundant. Used correctly, it refers to the current
instance of a periodical event (`the current issue'); do not use it to
refer to a document that is merely growing or being maintained (`the
current comp.lang.c FAQ' or `the current list of pizza toppings'). As
a general rule, if you don't offer back issues of the event, you don't
need to point out that what you do offer is the current version.
If you are using `current' to stress that the information you provide may become invalid in the future (`Currently, the internet is acquiring a million new users per month',) replace it with an explicit date or source of the information (`As of September 1994, ...'). Like a program that is written as a one-time hack and then stays around, your text might stick around much longer than you anticipate.
|
|||||
|
`The resource describes fact' talks about structure, not
contents.
|
|||||
|
`The resource documents information' again talks about
structure, not contents. `Documents' sounds good if the verb's
subject is not usually considered a source of information; e.g.,
If the resource is implicitly a document (such as a file, a list, or a hypertext page), the `documents' is just redundant and boring; stop writing about the form, start writing about the contents.
|
|||||
|
If you start a sentence with `here is' or `here are', you
usually end up talking about the document rather than the subject.
|
|||||
|
Similar to `back'. Which way leads `home' depends on the your
visitor. Describe the subject of the page instead.
|
|||||
|
Another overused buzzword. It started out as meaning `frequently
used' or at least `recently used', and now says the same as `cool'.
|
|||||
|
Should be a frequently used or popular link, not just a link.
If the word `link' alone isn't spectacular enough, use `hyperlink'.
|
|||||
|
At least pretend that you have been around
long enough to tire of this pun.
|
|||||
|
is spelled "Internet". Big I, small n. Avoid the
StoodlyCaps mannerism in general; unlike identifiers in most
programming languages, English text easily accommodates white-space
characters and hyphens.
|
|||||
|
A (globally unique) set of interconnected smaller networks
that transfer packets or, on a slightly higher level of abstraction,
streams of data between applications on hosts. The World Wide Web is
one of many Internet applications; others are email, chat systems,
large parts of USENET, and user interface systems like X/Windows and
News. Since "Internet" sounds cooler than "World Wide Web," one often
sees the two terms confused. Nevertheless, an URL is not an "Internet
address", and "surfing the Internet," if one would actually do that,
would be a boring affair that involved a lot of packet header
decoding.
|
|||||
|
means to edit a document to include an anchor or other
reference to another document; it does not mean "follow a link".
|
|||||
|
If you describe the format that you present your information in
(`Here is a list of things ...'), you could and should be talking
about the contents instead.
|
|||||
|
"Mosaic" is only one of many possible programs people use
to read documents available on the World Wide Web. The documents
themselves are "HTML documents" or "hypertext documents" or -pages.
Describing the medium with the name of one particular browser makes as
much sense as calling a highway a Ford path.
|
|||||
|
Almost as overused as `hot' and `cool'. Try to describe why, not
just that, you like it.
|
|||||
|
Don't do it. If you do it, don't talk about it. If
you talk about it, don't assume that markup geared towards a
particular commercial vendor is an advantage.
|
|||||
|
One of the relative directions that make sense only in text that
shouldn't be hypertext in the first place. If the next page has a
title, at least mention it together with the direction.
|
|||||
|
If you ask your readers to `note' something, they should have a
chance to arrive at your conclusion by examining your evidence
themselves.
Do not use `note' when the information you give is not factual
or not related to the evidence.
Do not use `note' as a prefix for explanations of how to read a diagram, either.
Almost any sentence that uses `note' can be reworded to avoid it; simply state the fact the reader should be aware of.
|
|||||
|
Redundant in a way similar to available.
|
|||||
|
Often used as "Your one-stop shop for X on the World
Wide Web." Promises that I won't need to go anywhere else, and most
often the first sign that I should.
|
|||||
|
One cannot point programs at sites. I don't even want to think about
the metaphor that would allow this.
|
||||||
|
Like `click here', only worse; the writer is so
infatuated with the cheesy 3-D looks of the new form -- in my case,
badly aligned buttons that jerk across the page when I scroll it --
that he or she believes the user will actually press the button rather
than click on it (or select it).
|
|||||
|
One of the relative directions that make sense only in text that shouldn't be hypertext in the first place. If the previous page has a title, at leas | |||||
Administration Policy on Bosnia
Change in Eastern Europe
European Union
Blueberry
Oatmeal
Sesame
