Original was at: http://www.sun.com/styleguide/
Copyright by Rick Levine and Sun Microsystems

This is a single-page compendium of all the pages in the Sun Guide to Web Style. It's a bit easier to print than stepping through the individual pages of the guide. It may also be more convenient for people on slow Internet connections to load this page, and do all their waiting at once, rather than parceling it out.

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.

Intro
Quick Reference
Purposes
Audience
Links
Page Length
Graphics
Image Maps
Navigation
Security
Quality
Netiquette
Content
Selling
Language
Java
Further Reading
TECHNOTE Index
TECHNOTE 2
rick.levine

Comments or suggestions?
© 1995 Sun Microsystems, Inc.
Rick Levine

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 note about examples
Acknowledgements/Colophon

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

The leading arrow, , is also a link. The arrow changes color and the symbol changes to a pointer to indicate which section is currently being viewed:
Welcome

A possible point of confusion is that the text name of a topic is also a link, leading to the page of detailed guidelines for that topic.
Graphics

This link has been included to allow people to navigate directly to a page of guidelines, rather than dealing with all the table nonsense.

A second peculiar graphic element, , follows guideline summaries in the right-hand column of this page, as well as on the Quick Reference page.

• Include alternate text for each image.

This will take a reader to another page with a more detailed explanation of a guideline.

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.

A note about examples

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.

Here is a particularly vivid example of this technique. (current)

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.

Acknowledgements/Colophon

Many people helped in compiling and reviewing this document.


Special thanks go to:

• Gary Adams
• Marney Beard
• Karen Bedard
• Tim Crean
• Kay Diller
• Meghan Ede
• Martin Hardee
• Judy Lindberg
• Carl Linde
• Frank Ludolph
• Jakob Nielsen
• Laurie Roshak
• John Tang
• Debra Winters
• and all the members of the SunSoft Human-Computer Interaction group.

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.

Purposes

• Are you providing a user interface to a service?
  
• Are you trying to sell products or services?
  
• Are you presenting information to an interested audience?
  
• Are you providing a collection of links?
  
• State your intent clearly when you start, and keep it in mind as your product evolves.
  

• What is the bandwidth of their internet connection?
  
• Early in your design process, try to define your audience.
  
• Who will be using your pages?
  
• Answer the question "what problem is my reader trying to solve?"
  
• Weigh the advantages and disadvantages of using a browser-specific technique carefully, and try to make your documents usable and valuable to the broadest number of readers.
  

Links

• Write about your subject as if there were no links in the text.
  
• Choose meaningful words or phrases for links.
  
• Choose an appropriate length for the link text.
  
• Create context for a link.
  
• Choose your links so they support your sentence and concept structure.
  
• Try to match the link text that someone clicks on with the title of the resulting page.
  
• Highlight text that is different.
  
• Don't change text link colors!
  

Page Length

• For presentations that must grab people's attention to be successful, don't make the page longer than the window.
  
• Some content must be presented in one screen because the user cannot tell if there's more to be seen below the edge of the window.
  
• If you need to present short, clearly segmented chunks of information, you should try to keep your pages short so people won't miss things that fall off the end of the page.
  
• If your pages present text that people will want to read at length, it's all right to use longer, scrolling pages.
  
• As a general rule of thumb, try to make the majority of your pages no longer than one-and-a-half screenfuls of text, and you will probably not get into too much trouble.
  
• For printing or saving, provide a separate link to a complete document.
  
• Use shorter pages to make your web more maintainable.
  

Graphics

• Use graphics critical to the information content of your page.
  
• Limit large images used solely for visual appeal.
  
• Keep the total size of all images used on a page to less than 30K.
  
• Use available technology tricks to minimize content access time.
  
• Avoid message-critical JPEG images if you want the largest possible audience.
  
• Warn the audience if a link leads to a large graphic.
  
• Minimize the number of colors being used in a single image.
  
• If you're going to use many images close together on a page, consider combining them into a single image.
  
• Include alternate text for each image.
  
• Use images with transparent backgrounds to better integrate your images.
  
• Don't use graphics referenced from another site.
  
• Use graphical bullets for a purpose, not becuase they look "neat."
  
• Use graphical divider bars sparingly.
  
• Use a small set of bullets or accent graphics repeatedly, rather than using a large number only once each.
  
• Take care with background images.
  
• Understand the pitfalls of changing the default text color for a page.
  
• Preview your images on several hardware and browser combinations.
  

Image Maps

• Clearly delineate the click-able regions in an image map.
  
• If possible, make the clickable regions in an image map look like "buttons."
  
• Explain image-map ambiguities.
  
• Provide alternate text links elsewhere on the page for image-map destinations.
  

Navigation

• If you must use graphic navigation buttons, use "redundant" text labels as well.
  
• Supply alternate text for graphic navigation buttons.
  
• If appropriate, add a brief table of contents at the top of the page.
  
• Put a title header on each page.
  
• Choose the HTML title to reflect the textual page title.
  
• Choose a title that accurately summarizes the content of the page.
  
• Provide a search service.
  
• Include document and chapter headings on long, multi-part documents.
  
• Consider duplicating navigational headers at the bottom of your pages.
  
• Avoid "return to" or "back" buttons and links.
  
• Avoid using a palette of graphic navigation buttons.
  

Security

• Don't publish "registered" information!
  
• Think twice about publishing "need to know" sorts of documents.
  
• Keep "company proprietary" information behind your firewall.
  
• Beware of robots.
  

Quality

• Test every link.
  
• Verify your HTML syntax and construction.
  
• Keep your pages up-to-date.
  
• Check your spelling.
  
• Write well!
  
• Write for all browsers, not just Netscape or HotJava.
  
• Don't use a "blink" feature.
  
• Date your pages.
  
• Put a link leading to a comment mechanism on every page.
  
• Respond to people who comment on your pages.
  
• Be careful using document format HTML "converters."
  

Netiquette

• Don't insult or flame people.
  
• Don't publish copyrighted material without the permission of the owner.
  
• Take care in using trademarks.
  
• Don't publish links to someone else's pages unless you know that they want that exposure.
  
• Give people constructive feedback on the documents you read.
  
• Give back to the Net.
  
• Strive for elegance and clarity.
  

Content

• Put as much content towards the top of a hierarchy as is possible.
  
• Provide useful content on each page seen by your audience.
  
• Provide value that gets people to add your offering to their bookmark list.
  
• Pare down your text.
  
• Provide "context" links to satisfy a range audience needs.
  
• Provide clues to the dynamic nature of your content.
  
• Don't assume that all your readers will use the same browser features and defaults as you do.
  

Selling

• Minimize the effort required to learn about your product.
  
• Optimize around shorter pages.
  
• Provide an easy way to get more information.
  
• Provide a path to make a purchase.
  
• Think twice about offering links to competitors' sites.
  

Language

• available
  
• back
  
• Check it out!
  
• click
  
• cool
  
• current
  
• describes
  
• documents
  
• Here is ...
  
• home
  
• hot
  
• hotlink
  
• hotlist of cool sites/links
  
• InterNet
  
• Internet
  
• link to
  
• list
  
• Mosaic page
  
• neat
  
• "Browser"-enhanced
  
• next
  
• note
  
• offered
  
• one-stop shop
  
• point your browser at ...
  
• press this button
  
• previous
  
• provides
  
• select here
  
• select this link
  
• surf
  
• There is..., This is ...
  
• view
  
• view this server
  
• viewing pleasure, for your
  
• WWW
  
• under construction
  

Java

• Interactivity, portability and network data access:
  
• Ornamentation.
  
• Process simulation.
  
• Browser user interface enhancement.
  
• Multi-player, distributed games.
  
• Weigh the trade-off between load time and value delivered.
  

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	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.
Are you providing a user interface to a service?	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.
Are you trying to sell products or services?	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)
Are you presenting information to an interested audience?	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.
Are you providing a collection of links?	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.
State your intent clearly when you start, and keep it in mind as your product evolves.	Some of the design decisions you will make when creating your web documents have very different answers depending on your intent.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
Early in your design process, try to define your audience.	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.
Who will be using your pages?	Employees of your company? Customers? People familiar with your subject matter? People just learning the things you will be discussing? The amount of prior knowledge your audience has of your chosen subject matter will dictate how much background information you need to provide, and extent to which you must clearly define and explain your terminology.
Answer the question "what problem is my reader trying to solve?"	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.
Weigh the advantages and disadvantages of using a browser-specific technique carefully, and try to make your documents usable and valuable to the broadest number of readers.	Netscape? Text-only? Might be anything? On PCs workstations? 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 effectively present your information. 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.
What is the bandwidth of their internet connection?	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	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.
Write about your subject as if there were no links in the text.	Don't refer to the mechanism of the web, and don't attempt to guide or instruct your reader. Hairong Li of the Missouri School of Journalism maintains The Internet Advertising Resource Guide, a wide-ranging collection of web commerce references. is much preferable to either: Click here to go to The Internet Advertising Resource Guide. or: Hairong Li of the Missouri School of Journalism has a home page. (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.)
Choose meaningful words or phrases for links.	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.
Choose an appropriate length for the link text.	A single word may be too small a target, and may not be meaningful. Using an entire sentence for a link may prove difficult to read, especially if the text extends over multiple lines.
Create context for a link.	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.
Choose your links so they support your sentence and concept structure.	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: Hairong Li of the Missouri School of Journalism maintains The Internet Advertising Resource Guide, a wide-ranging collection of web commerce references. Again, this is a better passage: Hairong Li of the Missouri School of Journalism maintains The Internet Advertising Resource Guide, a wide-ranging collection of web commerce references.
Try to match the link text that someone clicks on with the title of the resulting page.	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.
Highlight text that is different.	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 Architects Application summaries for Masons Application summaries for Excavators Application summaries for Interior Decorators as opposed to: Application summaries for Engineers Application summaries for Architects Application summaries for Masons Application summaries for Excavators Application summaries for Interior Decorators An even better solution may be to eliminate the redundant prefix text!
Don't change text link colors!	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
For presentations that must grab people's attention to be successful, don't make the page longer than the window.	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.
Some content must be presented in one screen because the user cannot tell if there's more to be seen 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 you need to present short, clearly segmented chunks of information, you should try to keep your pages short so people won't miss things that fall off the end of the page.	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.
If your pages present text that people will want to read at length, it's all right to use longer, scrolling pages.	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.
As a general rule of thumb, try to make the majority of your pages no longer than one-and-a-half screenfuls of text, and you will probably not get into too much trouble.	If you have doubts, ask for feedback from members of your intended audience.
For printing or saving, provide a separate link to a complete document.	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.
Use shorter pages to make your web more maintainable.	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!)

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	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 efective 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.
Use graphics critical to the information content of your page.	28 December 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 efective 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.
Limit large images used solely for visual appeal.	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.
Keep the total size of all images used on a page to less than 30K.	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.
Use available technology tricks to minimize content access time.	28 December There are several available techniques to minimize download times for images: Supply interlaced GIF files in your pages to allow images to load in multiple passes (i.e., the "window shade" or multi-layer effect.) Here are two images, one interlaced and one not. Press your browser's "reload" button to see the difference. If your browser supports interlaced images, the picture on the left will load in a series of passes, each one adding more detail. The image on the right will appear in successive horizontal bands. The left (interlaced) image shows more of the image sooner, with less detail in the early passes. Put HEIGHT and WIDTH pixel dimension tags in an image reference will allow some browsers to display all text on a page faster, by avoiding requests back to the server for each image to get dimensions. Specify both low- and high-resolution JPEG files to enable smart browsers to paint an entire page for your reader and then go back and fill in high-quality images after the page has loaded. This technique is worthwhile on large images, especially those over 100K.
Avoid message-critical JPEG images if you want the largest possible audience.	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.
Warn the audience if a link leads to a large graphic.	28 December 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.
Minimize the number of colors being used in a single image.	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.
If you're going to use many images close together on a page, consider combining them into a single image.	28 December 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.
Include alternate text for each image.	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.
Use images with transparent backgrounds to better integrate your images.	28 December 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 Examples of transparent vs. normal backgrounds, Browser low-memory behavior and Adjusting image placement with transparent borders.
Don't use graphics referenced from another site.	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.
Use graphical bullets for a purpose, not becuase they look "neat."	28 December 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: highlight items in a list, pointing out special status Purposes Audience Links Page Length Graphics Image Maps Navigation On the front page of this styleguide, a single yellow arrow is used to indicate the topic overview currently being displayed. categorize list items, allowing the reader to sort them more easily Administration Policy on Bosnia Yugoslavia after the Cold War The Changing Face of NATO Change in Eastern Europe 1995: The Year in Review United Nations Funding by Member European Union NATO Mission Log A Brief History of the Baltic States This example of colored bullets is modeled after the search result lists from some installations of the Architext search software. reinforce the visual language or thematic content of a page Use bullet colors which borrow from other graphical elements on a page. If there is a distinctive shape or geometric theme which figures strongly in the page, don't choose bullet shapes which fight that theme. Here is a whimsical example from a page explaining the weekly free bagel policy at Sun's Boulder site: Blueberry Oatmeal Sesame
Use graphical divider bars sparingly.	28 December 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.
Use a small set of bullets or accent graphics repeatedly, rather than using a large number only once each.	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.
Take care with background images.	22 December 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.
Understand the pitfalls of changing the default text color for a page.	21 December 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.
Preview your images on several hardware and browser combinations.	28 December 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 a Macontosh. 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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	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: images add sex-appeal, image maps can provide a valuable means to navigate a site, and that having an image map is probably your justification for using a glamorous, not-especially-content-critical image in the first place, follow these guidelines:
Clearly delineate the click-able regions in an image map.	The navigation bar at the top of many of Sun's web pages have clearly defined rectangular regions.
If possible, make the clickable regions in an image map look like "buttons."	Also in our header bars, the home and search "buttons" look like buttons. We've seen that people will be more apt to identify images as being "clickable" if the live areas really do 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)
Explain image-map ambiguities.	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.
Provide alternate text links elsewhere on the page for image-map destinations.	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
Include document and chapter headings on long, multi-part documents.	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.
Consider duplicating navigational headers at the bottom of your pages.	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
Avoid "return to" or "back" buttons and links.	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.
Avoid using a palette of graphic navigation buttons.	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.
If you must use graphic navigation buttons, use "redundant" text labels as well.	That way it will be easier for people to decode your symbols.
Supply alternate text for graphic navigation buttons.	Even if you do so for no other images, supply text labels for any graphical navigation buttons.
If appropriate, add a brief table of contents at the top of the page.	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.
Put a title header on each page.	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.
Choose the HTML title to reflect the textual page title.	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.
Choose a title that accurately summarizes the content of the page.	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.
Provide a search service.	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	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.
Don't publish "registered" information!	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."
Think twice about publishing "need to know" sorts of documents.	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!
Keep "company proprietary" information behind your firewall.	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.
Beware of robots.	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
Test every link.	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.
Verify your HTML syntax and construction.	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.
Keep your pages up-to-date.	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.
Check your spelling.	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.
Write well!	Edit your documents or get someone to edit them for you.
Write for all browsers, not just Netscape or HotJava.	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.
Don't use a "blink" feature.	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. Blinking 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.
Date your pages.	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.)
Put a link leading to a comment mechanism on every page.	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.
Respond to people who comment on your pages.	Pay attention to their feedback, respond to it, act on it, and thank them for taking their time to help you.
Be careful using document format HTML "converters."	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	A few things that your mother probably told you, but bear repeating.
Don't insult or flame people.	Only post things in good taste. No chain letters, derisive comments or inflammatory remarks.
Don't publish copyrighted material without the permission of the owner.	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.
Take care in using trademarks.	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.
Don't publish links to someone else's pages unless you know that they want that exposure.	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.
Give people constructive feedback on the documents you read.	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.
Give back to the Net.	Try to publish documents that provide value to a broader audience than your 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.
Strive for elegance and clarity.	Publish things that solve peoples' problems.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
Put as much content towards the top of a hierarchy as is possible.	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.
Provide useful content on each page seen by your audience.	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.
Provide value that gets people to add your offering to their bookmark list.	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.
Pare down your text.	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.
Provide "context" links to satisfy a range audience needs.	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.
Provide clues to the dynamic nature of your content.	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.
Don't assume that all your readers will use the same browser features and defaults as you do.	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	If you're trying to sell a product:
Minimize the effort required to learn about your 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.
Optimize around shorter pages.	Don't make people scroll or unnecessarily use their browser controls.
Provide an easy way to get more information.	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.
Provide a path to make a purchase.	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.
Think twice about offering links to competitors' sites.	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	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.)
available	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.
back	Which way leads `back' depends on the direction your visitor came from. Describe the subject of the page instead, or use absolute directions.
Check it out!	A meaningless buzz-phrase that often camouflages the speaker's lack of enthusiasm for whatever it is that you're supposed to visit.
click	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.)
cool	An overused buzzword. Try to describe why, not just that, you like it.
current	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.
describes	`The resource describes fact' talks about structure, not contents.
documents	`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., The rings on this tree stump document the forest fire of 1804, as well as the sequence of very dry summers in the 1960s. 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.
Here is ...	If you start a sentence with `here is' or `here are', you usually end up talking about the document rather than the subject.
home	Similar to `back'. Which way leads `home' depends on the your visitor. Describe the subject of the page instead.
hot	Another overused buzzword. It started out as meaning `frequently used' or at least `recently used', and now says the same as `cool'.
hotlink	Should be a frequently used or popular link, not just a link. If the word `link' alone isn't spectacular enough, use `hyperlink'.
hotlist of cool sites/links	At least pretend that you have been around long enough to tire of this pun.
InterNet	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.
Internet	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.
link to	means to edit a document to include an anchor or other reference to another document; it does not mean "follow a link".
list	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 page	"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.
neat	Almost as overused as `hot' and `cool'. Try to describe why, not just that, you like it.
"Browser"-enhanced	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.
next	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.
note	If you ask your readers to `note' something, they should have a chance to arrive at your conclusion by examining your evidence themselves. Note how the white spots in the upper half of the photograph mirror the house's outside illumination. UFOlogists believe that these camera lens reflections are in fact UFOs flying in formation over the capitol. Do not use `note' when the information you give is not factual Note that this is a load of bunk. or not related to the evidence. Note that the other three UFO sightings of that week turned out to be a weather balloon, a prank, and yet another camera reflection. Do not use `note' as a prefix for explanations of how to read a diagram, either. Note that, in the diagram on the next page, the little circles represent bright lights; the triangles represent the `UFOs'. Almost any sentence that uses `note' can be reworded to avoid it; simply state the fact the reader should be aware of.
offered	Redundant in a way similar to available.
one-stop shop	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.
point your browser at ...	One cannot point programs at sites. I don't even want to think about the metaphor that would allow this.
press this button	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).
previous	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.
provides	`The resource provides information' again talks about structure, not contents. Many phrases with `provides' are better expressed using other verbs; e.g. provides a history -> recounts provides a list -> lists provides a description -> describes provides an overview -> surveys, introduces Sometimes, `provide' is just a fancy word for `give'.
select here	The author has dutifully replaced the `click' in `click here' with a `select' - but failed to consider that one selects something, not somewhere.
select this link	Almost as bad as `click here,' but at least the uninspired writer does not assume a bitmapped client program.
surf	An overused buzzword. With its allusion to "waves" it may have its place - but you just can't surf a net.
There is..., This is ...	If you start a sentence with Here, This, or There, you usually end up talking about the document rather than the subject.
view	Do not use `view' when you mean `read'.
view this server	Much as one cannot point a browser, one cannot view a server, either; only a document, page, or screen.
viewing pleasure, for your	Avoid worn-out phrases like this one unless you're writing a parody.
WWW	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:
under construction	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.

	Purposes Audience Links Page Length Graphics Image Maps Navigation Security Quality Netiquette Content Selling Language Java
	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.
Interactivity, portability and network data access:	From a viewer's perspective, three major attractions of Java applets are: Interactivity. Applets loaded into a web browser can present a much more satisfying interactive experience, without the long pauses and timing uncertainties that other, HTML-based, web applications exhibit. Portability. I can use the same applet on any computer platform, as long as I have access to a web browser that offers Java support. Access to network data. The same local/wide-area data pipeline that makes other web applications so fascinating applies to Java. If the problem you're trying to solve requires these, you have an candidate for a Java-based solution,.
Ornamentation.	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.
Process simulation.	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.
Browser user interface enhancement.	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.
Multi-player, distributed games.	Anyone out there still remember Moria? Let's see some decent Java-based games!
Weigh the trade-off between load time and value delivered.	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 a 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 Guidance


Gareth's style guide
Gareth Rees is a PhD student at Cambridge University. He also has an exposition and history of tree-structured fiction and a nice bibliography of SciFi criticism.

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 (SunSoft 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.

Criticism


Why the Web sucks
A self-professed "rant" by CJ Silverio. Among the conclusions are that content is what makes a web document useful, and that good content takes work to create.

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.

Human-Computer Interaction


Tog on interface (Addison-Wesley)
This anecdotal collection of essays by Bruce Tognazzini on user interface design can give even a hardened "we don't need no stinking user interface design" engineer a moment or two of thought on usability and user-centered design.

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 (SunSoft 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.

Writing


Politics and the English Language
George Orwell on writing, ca 1946. Pertinent if you believe, as I do, that the quality of writing on a web page directly effects the perceived quality of the page. Living up to his six basic rules is a challenge:
• Never use a metaphor, simile or other figure of speech which you are used to seeing in print.
• Never use a long word where a short one will do.
• If it is possible to cut a word out, always cut it out.
• Never use the passive where you can use the active.
• Never use a foreign phrase, a scientific word or a jargon word if you can think of an everyday English equivalent.
• Break any of these rules sooner than say anything outright barbarous.

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.

Other References


The Visual Display of Quantitative Information and
Envisioning Information (Graphics Press)
Edward Tufte's landmark works on the graphic presentation of information. Tufte is a convincing proponent of creating information-rich visuals, and he backs up his theories with beautiful examples.

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.

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
• Examples of transparent vs. normal backgrounds,
• Browser low-memory behavior and
• Adjusting image placement with transparent borders.

Graphics: Transparent Backgrounds for Images

• What are transparent images?
• Low memory can make backgrounds reappear
• Adjusting image placement with transparent margins

What are transparent images?

Here is the banner from the top of this page, with and without the background set to transparent:
Transparent Background



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.

Low memory can make backgrounds reappear

Some browsers, when they run out of memory, will turn off transparent backgrounds on images. Some graphic artists use bright "marker" colors as they work, to aid in selecting regions. If these colors aren't eliminated in the final image, and instead are set to "transparent," the image will usually look fine, but they may surprise your audience when their browser runs out of memory. Use a neutral background color, so the problem won't be too glaring when it's encountered.

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.

Adjusting image placement with transparent margins

The transparent region around an image can be used to adjust the placement of an image on the page. Here is the banner at the top of this page, with the transparent backgound on the "TECHNOTE" graphic turned off:

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.

	Rick Levine
	I'm a member of the Human Computer Interaction group in SunSoft. My part of the group is based in Mountain View, California and my office is in Boulder, Colorado. Most of the work I do for Sun has something to do with the design and creation of user interface software: managing groups or projects, doing architectural and design work, or sometimes, as in the case of the web style guide, implementing a solution. Much of my work over the past two years has involved web site design and implementation. I've been with Sun for almost 10 years. Before that, I worked for NCR and Control Data, and in the dim, distant past before that, I was up to my ears in film, video and videodisk production. (303) 530-6665 voice (303) 530-0649 fax rick.levine@Sun.COM - 12/8/95