[ Deprecated 2015-11-06 ]

Website Guidelines

A Word to the Fore

This is, unabashedly, an advocacy piece, which explains the principles that guided the design of the LNS web site. Many readers will find the recommendations in the rest of this document excessively restrictive, or even flat out wrong. While I would like authors of "official" content for the LNS web server to at least consider the principles and suggestions in this document, ultimately we need good documentation far more than we need a well designed and consistent web site. Given a choice between documents that ignore every suggestion I have and no documents at all, I'll take the documents.

This rant is also out-of-date. It ignores many interesting developments over the last several years, and is wrong (or at least excessively strict) in several places. The general principle, however, still holds: focus on how the web site will be used.

Why we write web pages

The two most important questions that must be answered before creating a web page are

1. What is the purpose of this page?
2. What is the audience--who will be looking at this page?

The design of the web page (or site) ought to flow from the answers to those questions.

The reasons for most sites

These days, the most commonly visited web sites are commercial, meaning they are engaged in commerce--either trying to sell something themselves, or placing advertisements for others. The target audience for such sites is potential buyers, of the site's products or their advertisers' products. The goal of such sites is to attract or distract the eye to whatever it is they are selling, and they are generally willing to alienate the few visitors with older or off-brand browsers (they probably weren't going to buy anything anyway) if it will allow them to enhance the "impact" of their site.

The reasons for our site

The primary purpose of www.lns.cornell.edu is to make information available--research results, paper drafts, documentation, CLEO and CESR online status, and so on. The primary audiences are

• LNS personnel
• Outside physicists
• Anyone wishing to learn about what we do here

Of course, these considerations only apply to the official content of our web server--your personal pages may have entirely different goals.

Design implications

Since our goal is to make the information on our web server readily accessible and easily read, it follows that we should strive for a design that minimizes distractions and maximizes clarity and legibility. We cannot afford to casually discard any part of our audience, so we should aim to make our web pages compatible with as broad a range of browsers as practical--very little of the content of our web site will interest anyone with an attention span under several minutes, so flashy graphics and fancy page design are not going to help us much anyway.

Backgrounds, colors, fonts

Our general assumption ought to be that the reader has configured her web browser to suit her tastes and eyesight, and anything we do to override those settings will only diminish the legibility of the document. Hence, we should not overide the users preferences without good reason. Specifically:

• Don't force your preferences on your readers by setting the background color of your pages. If you like white (or whatever color) backgrounds, set your own browser to default to your favorite color scheme and give your readers the same freedom to choose.
• If you must set a background color for some reason, you*must* also set the text, link, vlink and alink colors. Otherwise, an infelicitous combination of user preferences and document settings could make the page unreadable (for example, if the the user preferences are set to white text on a black background, and the document background color is set to white, the result is white text on a white background).
• Avoid distracting background patterns--they add nothing to the document content, and detract from document legibility. Better yet, avoid any background that isn't predominantly transparent. Best, avoid background patterns entirely.
• Likewise avoid gratuitous font changes, especially global size or face changes. Also avoid color changes unless you have also set the background color.

There is a right way to accomplish all these sorts of embellishments--style sheets that can be overridden by user preferences. Unfortunately, style sheets are not widely implemented yet.

Tables

Tables used to "layout" a page tend to be fragile--the carefully tuned layouts they produce are easily broken by differences between browsers, or even font changes. They also usually detract from legibility, often scroll unatractively, and resize poorly. In general, tables ought to be reserved for tabular material.

Frames

Frames are a typical "Netscapism"--they do address a real problem of page navigation, but the solution is so poorly considered that it is often worse than the original problem, and as a result many people find navigating pages that use frames frustrating.

The chief problem with frames is that the design makes very restrictive assumptions about how the viewer will navigate the site. To illustrate: one of my favorite features of Mosaic or Netscape on Unix is that a middle-mouse-click on a link opens a new browser window to follow the selected link (also available as a right-mouse-menu item in Windows). This is a great feature for reading a help page while filling in a form, comparing several pages, or keeping a top-level page open while exploring the links under it. It also interacts very poorly with most pages that use frames, as the sub-pages usually assume the presence of the surrounding frame. Worse, they may use targets in the sub-pages with the result that following a link in a window causes the contents of some other window to change. In effect, incautious use of frames can make other very useful navigational aid (e.g. multiple windows) frustratingly useless.

Frames also break bookmarking--since there is no single URL that specifies a frame, any URL you bookmark is unlikely to recover the current configuration of pages. You can't look at the URL bar of a framed page and see where you are. You can't send the URL to a friend. And the back button and the reload buttons work in surprising and unpleasant ways.

If you feel you must use frames, provide a no-frames alternative. Make the alternative accessible from browsers that support frames, so the viewer has the choice regardless of the browser being used, and make sure the noframes alternative is fully functional.

The Evil of animated GIFs

Most animated GIFs are designed to distract the viewers' attention, contrary to the principles of our site design; hence, animated GIFs ought to be avoided unless they increase the content of the page, not just its flashiness.

In a networked environment, where the browser may be on a different machine than the display (if the display is an X-terminal, for example), every pixel change may have to be transmitted over the network. Animated GIFs, little scrolling javascript banners, and similar endlessly changing decorations can consume a surpisingly large amount of shared network bandwidth and CPU time. Therefore, looping animated GIFs, javascript banners, etc. should be avoided at all costs.

Java, Javascript, ActiveX

Since some people use browsers that do not support these, and many that do normally have them disabled for very good security reasons, pages should not depend on Java, JavaScript or ActiveX controls without good reason. Use of Java for good purpose is encouraged, JaveScript and ActiveX are best avoided.

Why we don't offer page counters

Page visit counters are the ultimate in useless widgets--they don't offer the reader any information that he is interested in, so all counters do for the viewer is slow down page loading. The only person who is really interested in the visit count is the author of the page, who already knows what the contents are, and hence shouldn't need to visit the page just to view the count.

Page counters are also unreliable--if the counter is embedded as an image, it won't be loaded if image loading is turned off, and counters can't account for the effects of caches and filters. If you want to know how many times a page has been visited, look on our web server statistics page; the counts there are more accurate than the average counter, and they don't slow down the viewer with useless clutter.

Site Design

A well designed site ought to have a consistent appearance, that immediately communicates to the viewer what site he is viewing, where in that site he is, and where he can go from the current page. Page authors, especially authors of public pages, should seriously consider adopting the style of the rest of our site. I would be happy to consider suggestions for redesigning our entire site, but there ought to be some consistency of design, appearance, and navigational features across the entire site that identifies it as a site, not just a random agglomeration of unrelated pages. Until someone presents me with a better design, the de-facto style of our site is that defined by the top level pages.

Writing Good HTML

The Web depends on interoperability, and standards are what make interoperability among heterogeneous systems possible--conformance to standards is why different systems can talk to each over the net, and why different browsers can render the same web pages. Browsers are written so that standard HTML will render in a predictable and legible fashion, but non-standard HTML may glitch unpredictably in different browsers. Writing standard HTML makes it more likely that your pages will look decent in any browser, and that they will continue to do so for a long time to come.

Standard HTML can also in be processed by SGML tools in various useful ways--in particular, the Harvest search engine we use will more effectively index your pages if they are standard HTML.

Use the locally available tools or the W3C validation service to check your pages. You should also:

• Sign all pages, including means of identifying and contacting the author
• Date stamp pages so readers know when a page last changed