The point has probably been well made by now that HTML is not a very good vehicle for providing specific information about layout and presentation. There are no mechanisms for an author to specify how she wants specific elements rendered, or to control aspects of page layout. While one of the strengths of HTML is this very independence from presentation details, it has become clear that some form of presentation control is needed.
Stylesheets are the answer to this problem. It provides the other half of the equation, the half that is currently not provided by HTML. While HTML provides information about content, stylesheets will provide information about how to render specific elements.
Unfortunately, while several mechanisms for providing stylesheets are under development, there is no clear standard at the time of this writing. We cannot tell you what stylesheet mechanism(s) will become standard, but we can tell you about the current contenders. Keep your hopes up, though: because of the importance of stylesheets, it is highly likely that a usable standard will emerge within the next year.
In these proposals, the stylesheets contain information about how elements should be rendered, whether this is font information, justification information, etc. At the time of this writing, the syntax for these stylesheets has not yet been fully designed.
The Arena browser is currently the only browser which supports a stylesheet mechanism, and that mechanism is currently only very limited and very experimental. The mechanism involves "cascading style sheets," which means that the several different style sheets, each with a different order of importance, are combined in order of importance to create a presentation style. The reader can specify her own preferences for rendering, as can document authors, and these preferences are merged to produce the final document.
DSSSL is the Document Style Semantics and Specification Language, which has emerged from the SGML community as a potential stylesheet mechanism. Because it is complex, work is being done to create "DSSSL Lite," a modified subset of DSSSL which can be easily implemented by client programmers, and easily used by HTML authors.
While stylesheets are not currently useable, there are alternatives in existing specifications, which can be used with existing browsers. While the HTML 3.0 enhancements below are not yet widely propagated, it is likely that they will be soon; and the Netscape enhancements are already available (and are likely to be integrated into the evolving HTML 3.0 specification).
While HTML 3.0 does include the STYLE element for
supporting whatever mechanism is eventually deployed for stylesheets,
HTML 3.0 also provides some new elements for greater control over
presentation. These elements include BANNER, BIG,
SMALL, TABLE, MATH, and
TAB.
The BANNER element provides a means for a banner
of HTML that will always remain on the screen. This might be a
copyright notice, a toolbar, or any other content which should
always be available.
The BIG and SMALL elements allow for
rendering text as bigger or smaller, as compared to the default
text size.
The TABLE and MATH elements provide
for a more sophisticated means of layout. The TABLE
element allows the author to specify a spreadsheet-style arrangement,
with cells that can contain text, images, and even input elements
for FORMs. The MATH element allows for
the description and rendering of complex mathematical formulae.
The TAB element allows the author to specify tab
stops within the document.
In addition, some entities have been added, such as
"&emspace;", to provide finer control over spacing.
For more information about these additional elements and entities, see the HTML 3.0 specification.
(This section is really no longer very Netscape-specific, since many other browsers have implemented parts of Netscape's functionality in the so-called "browser wars". Since I can't keep up with them all, and since the point of this whole discussion is that there are still some browsers that don't do everything, I won't bother to enumerate them all here.)
The Netscape approach cannot be called a "style sheet,"
per se. Rather, as of the 1.1 release of Netscape Navigator, Netscape
has provided several "enhanced" elements to help control
presentation. These elements include FONT, BASEFONT,
IMG, and BODY.
The FONT and BASEFONT elements allow
changing the size of font within a document. The IMG
element, on the other hand, has been enhanced to provide text
flow around images in documents.
The BODY element now allows control over the background.
The author is allowed to provide a background color or image for
their document. In addition, the author can specify different
colors for hypertext links, in case the default colors do not
have sufficient contrast to the new background color.
If you would like more information, Netscape Communications has provided documentation of their HTML extensions online (both for the Netscape HTML 2.0 extensions and the Netscape HTML 3.0 extensions).
Note: Be careful when changing colors for hypertext links. Most browsers take the approach of using a bright color (such as bright blue), which has high contrast to the default page background, for links which have not yet been followed; and of using a dull color (such as dark blue), which has less contrast to the default page background, for links which have already been followed. Readers have become used to this high-contrast/low-contrast visual cue, and changing the link colors can confuse readers.
The best approach is to, first, not change the link colors unless you have to. With most background colors, the defaults should still be fine. If you do need to change the link colors, use a color that is bright, and high-contrast to the background color, for links to pages which have not yet been visited. Use a duller version of that same color for links that have already been followed.
Given the proliferation of Netscape's frames, it seems appropriate to at least add in a paragraph or so commenting on proper usage. Frames allow you to break the browser's window into separate subwindows, with different documents in different windows. This provides even greater control for the author in terms of what the end document actually looks like (and, granted, can be used to very good effect), but, as with all things, must be used with care.
Some gotchas with frames include:
In general, the gotchas revolve around the fact that more control is removed from the reader in a medium where the reader expects to have a good deal of control. This doesn't mean don't use frames; it means that you must carefully analyze why you are using them, and make sure that their use is justified.
Another note: there is a NOFRAME element which can be used to give alternate text for those browsers which do not support frames; use it.
More on this subject as I become more familiar with frames.
A quick plug: Chapter 5 of Web Weaving discusses many of the issues you should take into account in planning and administering your Web (in fact, the entire book revolves around the subject in great detail). Here we will also address that subject, considering the architecture of your infostructure.
When organizing your infostructure, there are several important issues to consider. These issues include:
Presenting a clear ordering of information by subject (table of contents), or some other form of reasonable entry into the infostructure. Some useful forms are:
The reader needs to be able to find what they are looking for, and a good overview that allows the reader to quickly find a particular topic or document is invaluable.
Only making a document as long as it needs to be. If a document can be logically decomposed into more then one file, do so, but only decompose a document if the narrative branches from the linear structure of the current document. An example of this is breaking a book-length work up into chapters, and further breaking those chapters up into sections. Because of the length of time involved in retrieving documents, making the document available in readable chunks means that the reader can use the information without becoming overwhelmed in loading times and a correspondingly large amounts of information presented a single, huge, scrolling document.
Correspondingly, make sure a document is richly cross-referenced, so that if reader wants to ask, "Why?", she can. If you can split up supplementary information into separate documents, do so. This allows the reader to follow a main flow of narrative, but still able to look up evidence and additional related stories and information as necessary. But don't put in so many links that the reader gets lost trying to follow them all.
Providing a clear, consistent navigation structure. You should always be able to easily to navigate to all documents which immediately relate, but you should also always be able to get any other document in the infostructure with a minimum of fuss. Always provide access to the original table of contents, or its equivalent. This is especially important for when others create links to documents in your Web, but do not necessarily create links to your main entry points; readers can find themselves in the middle of what is obviously a larger document, but without any means of finding additional information. See Main Roads and Scenic Paths, below.
Anyone working with HTML for any length of time will soon realize that the markup language is composed of containers, which label content. It should be obvious, then, that your web should be primarily about this content, whatever it may be.
That's not to say that content only lies between HTML tags: content is also found in other media types, of course, and, depending upon the type of information you provide, sounds or images may be more important to both you and your readers than other types of media.
Web sites, however, should be driven by content, not by vanity or the need or desire to make a buck. Whatever your background, you have real "content" -- information, discussion, narrative, ideas -- to publish on the Web. People will visit your site to find this content. Provide it. Focus your site around it.
The largest threat to the Web is that as it becomes insanely popular, instead of becoming a world-wide information repository, as its founders and proponents have hoped, it becomes a large intertwined mass of self-referential sites unwittingly involved in meta-discussions on the nature of the Web: home pages which say little more than "This is my home page" (or "our home page", in the case of the corporate or organizational "presence"), with a collection of links which (virtually) point to the same collections of sites as the last page you visited did.
As readers attempt to sail the seas of your infostructure, it is important that you provide useful ways for them to move around in your infostructure. Many readers complain about the proliferation of links in documents, providing so many choices that it becomes impossible to decide where to go next. The blessings of hypertext -- leaving control in the hands of the reader -- can also be a curse, as the original thrust of the narrative becomes awash in side tracks and dead ends.
A means of approaching this problem is to use the metaphor of "main roads" and "scenic paths." This means categorizing the kinds of links you include into two major groups: those which are recommended next destinations, and those which lead off into explanatory side-trails and divergences. As an example, a main path through a hypertext version of a book would be a linear progression from first chapter to the last. A side trail, on the other hand, would be a reference from (for example) Chapter 6's description of CGI functionality in various HTTP servers to Chapter 8's extended discussion of CGI scripting.
This is not to say that there is a single main path through a document -- there can be several (just as there are several ways to read a book, including as a linear narrative, and as a random-access reference). And side trails include references outside of the immediate document, such as bibliographic references. In addition, side trails can become main paths if the trail leads to another document instead of self-contained explanation.
The point, however, is that a document (in the extended sense of several HTML pages collected and interlinked) should contain at least one or more author-defined main paths through the text, in order to provide a guidepost for those exploring the information. These main paths should take the form of "next" and "previous" anchors, links back to the table of contents and index from any point within the document, and pointers to alternate main paths which are available (where appropriate).
Although hypertext is based on notions of non-linear text, readers do make it linear as they read through it. And it doesn't hurt to provide at least one sensible linear pathway through the document for readers who aren't interested in wandering around in hyperspace.
Consistency is what brings your site together so that it feels like a cohesive whole -- it can unite otherwise disparate topics or content areas, and it can be used to give your site a distinctive feel in comparison to other sites, or a sense of personality. Consistency also lends to the maintenance of a site -- if you have a certain way of doing things site-wide, it becomes much easier to make significant site-wide changes without putting a great deal of time into it. You can achieve site-wide consistency a number of ways:
A standard site-wide graphical banner or text-based header can be used to easily identify the site or sponsoring organization. Your header doesn't necessarily need to be static across the site; you can easily share dimensions and a primary graphic element across banners while making each one relate specifically to the content at hand.
Footers can be used in the same way; a standard method to sign documents and/or a standard text-based or graphical menu bar can easily pull a site together, not only as a design element, but also as an easy way to always navigate to the table of contents or index of a site.
Server-side includes, supported by most HTTP servers, can simplify some of this work, allowing you to create generic headers and footers which can be modified once and included in all of your documents.
A unifying theme for graphic elements throughout the site easily pulls it together into a whole. A shared motif, such as bubbles, sign posts, or a corporate logo, works, as does a site-wide color scheme or page backgrounds. You can rely on sizing and positioning of graphic elements or textual elements, as well, to achieve a unified feel.
Beyond images and design elements, sites come together because of personality and style. A consistent feel or attitude for a site, conveyed across textual and graphic elements, can not only make each piece feel as if it's part of a larger whole, it can also attract readers who share the same attitude or outlook (or are fascinated by yours). The best sites on the Web aren't necessarily the most polished, but those that pull readers back again and again not only because of informational content but also because of the voice with which that content is presented.
For documents which should have a personality all their own, such as user home pages, you can still pull all these different personalities and outlooks together by presenting a common theme or launching point. All the users of a particular Internet service provider, for example, have something in common by the sheer fact of their being there -- and by the mere fact of providing a top page view to user-maintained areas, the service provider has begun to form a community around which a commonality can develop.
Although Universal Resource Names, or URNs, are being developed in order to provide a naming system similar to the domain naming system for URLs, at this point it remains desirable to use URLs as if they refer to the same resource persistently through time.
As a content provider, you can help provide those who make links which point to your site by developing a file structure which will allow you to manage content as it grows and develops.
If your Web space is based on a hierarchical filing system, you can avoid major reorganization of that file system by
An example might be an organization which has just created a new
division, Foobar. Currently, there's little information to publish
about Foobar on the Web: Foobar has a mission statement and little
else. Though it might logically follow to create a file, "foobar.html",
to hold the mission statement, and to store it in the same directory
as your main organization's web, it might be wiser to create a
subdirectory named foobar which could then contain
foobar.html and other files, as Foobar expands. This
way, links don't have to be changed or redirected down the road
when Foobar adds additional files and perhaps chooses to design
and administer its own web space. If part of Foobar's mission
statement is to spin off into its own organization, you might
even create a directory on the same level as the parent organization's,
to signify within the URL path the relative autonomy of the division
and its future direction.
Another way to manage URLs is to only publicize a few well-known entry points to your Web: for example, the top view, or table of contents page, and perhaps an index page, or a FAQ page.
When URLs do change, it's important that you not only provide links from the old URLs to the new ones (or redirect the URLs to the new ones), but you also make an attempt to notify those that have links into your Web space, through general announcements or by contacting directly those who have well-known links to your documents (such as Yahoo or Lycos).
Your web space should not only be consistent with itself internally, it should make references between the site and the outside world appear seamless.
A good case in point is the corporate site which has made its product information available via the Web, but, under the link for Ordering Information, only provides an 800 number in order to purchase the advertised commodity. Or the home page for a band which doesn't provide any audio clips of the band's songs, but just a thumbnail image of the cover art from their most recent album, available through some obscure indie label. Or the online newspaper which provides news coverage, but doesn't push the envelope and provide a real way to participate in the political process.
Seamlessness is about bridging the gap between the world you create within your web and the world outside it. Often, this means not carrying over from traditional broadcast media restrictions or limitations that fail to make sense in interactive media.
A site-wide strategy to organize information is never easy to invent, but vitally important to your site's success as a place where information is retrieved and used, versus simply being an area in which content is stored.
Of course, there's no single recipe or structuring mechanism which you can apply to all types of content to give you a well-designed web site. That comes from thinking about the nature of your site and your content, and the logical divisions that your content can be organized around. However, finding an existing metaphor which you can work within while also pushing the boundaries of can be an effective way to plan for the organization of a site.
There are many obvious metaphors upon which to base a web site: thinking of your content as being organized like a book, building, or branching tree.
Books lend themselves easily to the Web: and, in fact, many books have been "ported" to the Web, for better and for worse. Books have tables of contents and indices, for quickly locating information; parts, chapters, sections, and sub-sections, for organizing content; and footnotes, endnotes, and bibliographies, for displaying links to other content. Collections of books become "libraries", complete with card catalogs and help desks.
However, books also have pages which display content statically, while computer displays have a single, dynamic screen. A book metaphor quickly falls apart when applied to the Web on a page level: you could choose to consider a single HTML document a "page", causing you to break up content into arbitrarily small and hard to manage, difficult to navigate pieces; or you could think of whatever text and graphics being currently displayed on a screen as a "page", which could easily drown the user in a sea of text without the benefit of traditional navigational tools such as page breaks and numbering of pages. The screen is not a page.
Sites can also be managed as being housed in a building, a collection of buildings, or along some other spatial metaphor. The information you hope to store and manage is divided for the user along content areas, which is housed in different "buildings", which can then be further subdivided into "rooms". Obviously, this can be effective for some types of content, such as a large corporate site with many divisions, or a museum or gallery: basically, any information which can be mapped into a spatial plane consistently lends itself to this sort of view.
At the same time, a spatial metaphor in a largely text-driven medium, as the Web is today, is often hard to pull off convincingly. VRML (Virtual Reality Modeling Language) and other such developments will allow for the creation of virtual spaces; even then, the connecting points between rooms or buildings -- hallways and walkways -- need to be considered thoughtfully. It's also the case that, at many sites, the metaphor is dropped too quickly: you're asked to select a content area based upon a clickable map-based view, but then you're dropped into pages of descriptive text. Not only can this be disconcerting for a user, it points out the fact that oftentimes resources aren't allocated wisely across a Web site, with too much attention and time spent on the top page of a site in comparison to the remainder of the site.
A third way of thinking about a site as a whole is using a branching metaphor, where all content springs from a common root and then branches out into many divisions and content areas. This is an obvious metaphor to use for web sites built atop file systems, since most file systems share this organization of directories (or folders) branching into subdirectories (or subfolders), and so on.
A branching metaphor shouldn't be pursued over the linear flow of information, however: too many branches can be confusing or frustrating for a user, especially if navigating those branches requires repeated jumps to a monolithic top structure.
In general, there some key issues you should keep in mind when organizing a site on a macro level, including:
Providing a main entry point, or top view, which makes it easy for users to find the content which they're most interested in. At times, you'll know exactly what a user is looking for: if you run a site which provides audio clips of theme songs from popular cartoon series of the '70s, users probably expect to find a listing of available audio samples or a link to such a listing from your site's top page. Other times, you can't be expected to know: for a site covering a wide diversity of subjects, it may be necessary to provide a search mechanism or user-customizable top view in order for users to navigate your site comfortably.
Offering multiple paths to the same content. Not all readers seek the same information in the same way. A good glossary or index will cross-reference information: for example, you may be told to look under "automobiles" if you seek information under "cars". That same information could probably be found by looking through a table of contents. With hypertext links, you can refer to the same information in many ways. Do so, where it facilitates the user without overwhelming her.
Keep in mind, too, that a site, whether it be a file system or a database, need not be organized as the user sees it: the underlying structure doesn't have to be identical to the structure which the user navigates. However, a close relationship between the two can make it easier to maintain a site, as content is revised and expanded. A change in one part of your web space can have an impact on other parts of your site which share links or other references: the easier it is for you to see these relationships while maintaining these underlying documents, the more likely it becomes that your site as a whole is kept up-to-date and cohesive.