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 least mention it together with the direction.
|
|||||
|
`The resource provides information' again talks about
structure, not contents. Many phrases with `provides' are better
expressed using other verbs; e.g.
Sometimes, `provide' is just a fancy word for `give'.
|
|||||
|
The author has dutifully replaced the `click' in `click
here' with a `select' - but failed to consider that one selects
something, not somewhere.
|
|||||
|
Almost as bad as `click here,' but at least the
uninspired writer does not assume a bitmapped client program.
|
|||||
|
An overused buzzword. With its allusion to "waves" it may have
its place - but you just can't surf a net.
|
|||||
|
If you start a sentence with Here, This, or
There, you usually end up talking about the document rather than the
subject.
|
|||||
|
Do not use `view' when you mean `read'.
|
|||||
|
Much as one cannot point a browser, one cannot view a
server, either; only a document, page, or screen.
|
|||||
|
Avoid worn-out phrases like this one unless
you're writing a parody.
|
|||||
|
can be hyphenated either as `World-Wide Web' or `World Wide Web'
(but try to be consistent within one document). It is a world-wide
(hence the name) network of documents, software, and protocols that
connect them. Consequently, it does not make sense to speak of `this'
or `my' or `our' WWW; the part controlled by a single human or company
can only be a document, subtree, web, or site.
And one addition to the list, which is not in Jutta's document:
|
|||||
|
The nature of web documents is to be fairly fluid
and easily updatable. Either you have enough done that you think your
pages are useful to people, in which case you need not apologize for
them, or you aren't ready to show them to the world, and shouldn't be
making them public. It's acceptable to talk about the work that will
be done to your pages in the (hopefully) near future, as long as
you're going to do it.
|
|||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
Java holds much promise for
the creation of performant, interactive, portable, network-aware
applications. This sections summarizes some of what Java offers from an application
perspective, and some of situations in which Java-based
applets are showing up. Because we're just beginning to get experience with
real-world uses of Java, this is only a tentative beginning for
practical stylistic guidelines for using Java.
|
||||||
|
From a viewer's perspective, three major attractions of Java applets are:
If the problem you're trying to solve requires these, you have an candidate for a Java-based solution,.
|
|||||
|---|---|---|---|---|---|---|
|
If you've seen a Java applet running, more than likely it was used
for simple ornamentation. It beeped when your mouse pointer ran over it,
it jumped when the page started, or it flashed until you left for another
destination. Little ornamentation widgets are easy to learn on, but in many
cases they contribute no information content to a presentation. When they
do, most of those cases could be handled by non-animated techniques.
By all means learn Java, and experiment with ornamentation, but then go on to more
substantial uses.
|
|||||
|
Using an interactive computer-based simulation to teach people how a process
works is a time-honored technique. The PLATO system, starting in the 1960's,
had some fine examples, ranging from fractional distillation experiments
to paramedic ambulance exercises. Java's promise of platform portability
may make the development and distribution of such simulations much easier.
Here's a very effective usage of a Java animation, from Starwave's Family Planet site. It's a series of step-by-step instructions for creating a simple animation flip-book. It ends with a demo of a professional animator's flip-book, done with Java. (The applet is on the fourth page of the sequence.) The site only gives you the Java page if you have a Java capable browser, with no script executed. They use Netscape frame syntax to provide two versions of the document, the frame one having a Java applet and the non-frame version without. If your browser can intpret Netscape frame syntax, they assume you can view a Java applet, which, for the short-term is a mostly valid assumption.
|
|||||
|
Web browsers will evolve over time. If the problem you're trying to solve
can't wait for better input range-checking, smarter image map targets,
or more intelligent list selectors, you can build the needed widgets in Java.
Eventually, the browsers will catch up, we hope. A more likely area for
Java-based innovation are those elements of user interface that are highly
domain-dependent, and won't be solved by the mainstream
vendors.
|
|||||
|
Anyone out there still remember Moria? Let's see some decent Java-based
games!
|
|||||
|
Until mainstream network bandwidth finally catches up with interactive needs, Java
developers need to carefully understand the balance between the time a
person has to wait for an applet to download and the perceived value
received from that applet. If I load something once at the beginning of a session
and use it for the rest of my workday, the time I spend waiting for a download
doesn't feel so bad. However, if I spend four minutes waiting for an animation
that takes 5 seconds to run, only appears once, and contributes no
information content, I'll probably press "stop" the next time you try to
give me one of those.
Of course, using another means to deliver applet libraries, such as more traditional diskette or CD-ROM distribution, can circumvent the pitfalls of web-based delivery.
|
|||||
This is a guide to some of the sources I've found interesting or useful. The list isn't exhaustive or definitive, and reflects my personal biases. If you have other favorites that might fit in this collection, please drop me a note.
Style Guidance
Criticism
Human-Computer Interaction
Writing
Other References
Style Guide for online hypertext
The original, but still very useful, reference from
Tim Berners-Lee.
WWW Style Manual
The Yale Medical School's web style guide. Nicely illustrated, with only a small tendency to
get long-winded. The organization breaks things down into small doses that can make
navigation mildly annoying. It's geared towards "academic" documents more than
business or presentation styles.
Top 10 Ways to Make Your WWW Service a Flop
What not to do. A comprehensive map of the path to failure, compiled by
Dr. T.
Matthew Ciolek at the
Australian National University.
An HTML 2.0 Pattern Language
This is a formative attempt at a pattern language for web documents, authored
by Robert Orenstein.
It's an interesting start, and raises some issues about whether this field
is actually rich enough to have real patterns. Pattern language is a discipline
that came out of the work of architect Christopher Alexander. It uses
generalizations ("patterns") about achitectural practice
to simplify the architectural process and provide possible solution elements
for complex architectural problems.
HTML for Fun and Profit (Sun Microsystems Press)
This is a practical introduction to setting up a web site and creating your
first web pages. Mary Morris has created a comprehensive guide to getting started
on the web. Look for
Web Page Design: A Different Multimedia, by Mary Morris and
Randy Hinrichs, coming in early 1996.
Why is the Web So Boring?
An essay by
Stovin Hayter, postulating that the quality of the interactive
experience is what makes a web page compelling.
HyperContent, HyperJunk
By Jorn Barger.
Lots of examples to illustrate his points. Includes pointers to successful ASCII
image maps, a concept that I find fascinating.
Why I Like the Web
A thoughtful discussion
of why the web is good for a visual artist, by
Kristen Ankiewicz. She also presents guidance on how to do image intensive presentations
responsibly, and gives a plausible counter to my suggestion that the 256-color
audience is the most important target.
If You Can Read This, You Ain't Using Netscape
Some thoughts on browser-specific implementation by
Marcus Freericks.
It might be hard to see what he's so upset about.
Usability Inspection Methods (Wiley)
Edited by Jakob Nielsen
and Robert Mack, this is a practical catalog of techniques for
ensuring that people can actually use your web pages the way you want them to. It's slanted
towards more traditional user interface development tasks, but almost all of
the methods described have a place in evaluating web pages.
Designing Visual Interfaces: Communication Oriented Techniques
(Sun Microsystems Press)
Written by Darrell Sano and Kevin Mullet, this is a thoroughly illustrated text
on communicating via visual interfaces. The authors fill a long-vacant gap in the
user interface design literature, solidly establishing a case for visual design as
a critical discipline for user interface developers.
What is good hypertext writing?
Jutta Degener has created a thoughtful,
succinct introduction to writing and publishing hypertext documents. The current
technical nature of the process of creating web pages seduces us into concentrating on
form at the expense of content.
HTML is no TML
More from Jutta Degener, pointing out the typographical failings of HTML. Ripe grounds for
the "don't worry about typography, trust the HTML rocket scientists and fix the browser" crowd.
The Deluxe Transitive Vampire:
The Ultimate Handbook of Grammar for the Innocent, the Eager, and the Doomed (Pantheon)
Intimate Apparel: A dictionary of the Senses (Times Books)
The New Well-Tempered Sentence:
A Punctuation Handbook for the Innocent, the Eager, and the Doomed (Ticknor & Fields)
These wonderful books on language by Karen Elizabeth Gordon may cause Strunk and White
to twirl a bit, but they're rich, entertaining and highly readable.
The Elements of Style
The original, by William Strunk, Jr. On-line version courtesy of
Project Bartleby at
Columbia.
Quality, Guidelines & Standards for Internet Inf. Resources
Also from ANU, this is a compendium of
quality-related material for information resources. It's fairly comprehensive,
and is kept up-to-date.
As We May Think
This essay by Vannevar Bush was published in the July 1945 issue of the Atlantic
Monthly. Section
6 and onward detail his "memex," an information storage and retrieval device, and
the basics of hypertext.
hypertext and literary things
A large, well-maintained collection of links on hypertext by
Kia Mennie. Subjects
range from academic essays to fiction to technical references. (The pages are being
moved to the above location, and may be in temporary disrepair.)
Writing HTML - a tutorial for creating WWW pages
This is a solid, fairly comprehensive on-line tutorial for learning the
basics of HTML. Created by Alan Levine
at the Maricopa Center for Learning &
Instruction, Maricopa County Community College District, Arizona.
Poynton's Color Technology Page
Charles Poyton maintains
a detailed FAQ list on color and color perception in computer graphics.
This is an excellent, detailed resource to help understand the subtleties
of computer displays and gamma correction. Also worth examination are his
comments on
typography and design, and his book
A Technical Introduction to Digital Video (Wiley).
As I encounter technical or how-to questions which might be interesting to some of our readers, but aren't purely style or design issues, I will add TECHNOTE pages offering solutions to those questions. If you have a question which might be appropriate for this section, or if you'd like to write a brief tutorial on a favorite technical issue, drop me a note.
Graphics: Transparent Backgrounds for Images
Normal Background
Only .gif images can have transparent backgrounds. The GIF89a file format allows one color in the color map to be set to transparent. This can be done by using an image manipulation application which supports the feature. (Add note to tutorial here...)
Using a transparent background can give the appearance of a non-rectangular image.
Normal Background
Transparent Background
This technique is commonly used on graphical bullets for lists.
Here's a portion of a Sun navigation header that we caught with this problem, shown with its transparent background turned off:
Also, remember this possibility when someone complains about your transparent images not being transparent! Quitting and then restarting the browser will usually cure the problem.
There is a 8-pixel transparent margin added to the left side of the image to add some space between the two images. A margin has been added below to move the text in the image up, putting the header letters in the image at the same level as other header graphics having letters with descenders in the text.
To view the examples on this page, choose the "dither" option from the "General preferences" color dialog in the UNIX or PC versions of Netscape Navigator. (On Macintosh computers, dithering cannot be turned off.) In addition, the information is only relevant to computers which have 8-bit (256 color) or less-color-capable display hardware.
Here are two examples. The colors in the first bar should appear as "pure" colors. When viewed on computers with 8-bit (256-color) display hardware, each of the colors in the second bar should be rendered as a mix of two other colors.
Dithered colors
In Netscape Navigator 2.0, these color swatches may not be dithered if the "automatic" color policy is selected in preferences on UNIX and PC platforms. Set it to "dithered" to see the difference.
Netscape Navigator 2.0 allows a person to set a color policy in their application preferences. The default setting is "automatic." In this mode, the browser will use an algorithm to decide if colors should be dithered, or if "close" colors should be substituted. In addition, the software may load a custom color table for a particular image, if that image is the only one on a page. (As far as I can tell, Netscape Navigator will not dither colors in background images.)
Dithering can reduce the quality and legibility of an image. To avoid dithering, authors can create images which use the colors specified in the browser's built-in default color table. If this is done, the colors will be rendered without dithering.
The only problem with this approach is that versions Netscape Navigator running on PC/Macintosh platforms use a different default color table than do some UNIX versions of the software. Compounding the problem is that the differing color tables have very few color values in common. If color dithering will be a large page quality issue for your documents, you must either choose the color table which will be used by the majority of your audience, or use server-side automation and scripting to provide a platform-specific image to your audience, based on the version of their browser.
The next two sections provide images which use the complete default color tables from the PC/Macintosh and UNIX versions of Netscape Navigator 2.0.
This image shows the 6x6x6 color "cube" used by PC and Macintosh versions of Netscape
Navigator on 8-bit (256 color) display hardware.
The colors in the table use RGB values of hex 00, 33, 66, 99, cc and ff. The decimal values for Photoshop and other applications are 0, 51, 102, 153, 204, and 255. To use the color table from this image, save the image to a file on your computer, open it in an image editor, such as PhotoShop, and either save the color table to a file for re-use, or otherwise create images with the same color table.
On many 8-bit (256 color) UNIX platforms, the colors in this table will be
dithered.
This image shows the 5x5x5 color "cube" used by some UNIX versions of Netscape
Navigator on 8-bit (256 color) display hardware.
The colors in the table use RGB values of hex 00, 40, 80, bf, and ff. The decimal values for Photoshop and other applications are 0, 64, 128, 191 and 255. To use the color table from this image, save the image to a file on your computer, open it in an image editor, such as PhotoShop, and either save the color table to a file for re-use, or otherwise create images with the same color table.
On many 8-bit (256 color) PC and Macintosh platforms, the colors in this table
will be dithered.
|
Rick Levine |
|
I'm a member of the Human Computer Interaction
Most of the work I do for Sun has something to do
I've been with Sun for almost 10 years. Before that,
(303) 530-6665 voice rick.levine@Sun.COM - 12/8/95 |
Administration Policy on Bosnia
Change in Eastern Europe
European Union
Blueberry
Oatmeal
Sesame
