When you write a book, a paper, an article, or even a memo, you usually don't just jump right in with the first sentence and then write it through to the end. Same goes with the visual arts—you don't normally start from the top left corner of the canvas or page and work your way down to the bottom right.
A better way to write or draw or design a work is to do some planning beforehand—to know what it is you're going to do and what you're trying to accomplish, and to have a general idea or rough sketch of the structure of the piece before you jump in and work on it.
Just as with more traditional modes of communication, writing and designing Web pages takes some planning and thought before you start flinging text and graphics around and linking them wildly to each other—perhaps even more so, because trying to apply the rules of traditional writing or design to online hypertext often results in documents that are either difficult to understand and navigate online or that simply don't take advantage of the features that hypertext provides. Poorly organized Web pages are also difficult to revise or to expand.
In this chapter I describe some of the things you should think about before you begin developing your Web pages. Specifically, you
After you have an overall idea of how you're going to construct your Web pages, you'll be ready to actually start writing and designing those pages tomorrow in Chapter 3, "Begin with the Basics." If you're anxious to get started, be patient! There will be more than enough HTML to learn over the next couple of days.
First, here's a look at some simple terminology I'll be using throughout this book. You need to know what the following terms mean and how they apply to the body of work you're developing for the Web:
A Web presentation consists of one or more Web pages linked together in a meaningful way, which, as a whole, describes a body of information or creates an overall consistent effect (see Figure 2.1).
Figure 2.1. Web presentations and pages.
A Web presentation is a collection of one or more Web pages.Each Web presentation is stored on a Web site, which is the actual machine on the Web that stores the presentation. Some people refer to the Web presentation and the Web site as the same thing; I like to keep them separate because a single Web site can contain many different presentations with very different purposes and developed by different people. Throughout the first week or so of this book you'll be learning how to develop Web presentations; later on you'll learn how to publish your presentation on an actual Web site.
A Web site is a system on the Internet containing one or more Web presentations.A Web page is an individual element of a presentation in the same way that a page is a single element of a book or a newspaper (although, unlike a paper page, Web pages can be of any length). Web pages are sometimes called Web documents. Both terms refer to the same thing: a Web page is a single disk file with a single filename that is retrieved from a server and formatted by a Web browser.
A Web page is a single element of a Web presentation and is contained in a single disk file.The terms Web presentation, site, and page are pretty easy to grasp, but the term "home page" is a little more problematic because it can have several different meanings.
If you are reading and browsing the Web, the home page is usually referred to as the Web page that loads when you start up your browser or when you choose the "Home" button. Each browser has its own default home page, which is often the same page for the site that developed the browser. (For example, the Netscape home page is at Netscape's Web site, and the Lynx home page is at the University of Kansas.)
Within your browser, you can change that default home page to start up any page you want—a common tactic I've seen many people use to create a simple page of links to other interesting places or pages that they visit a lot.
If you're publishing pages on the Web, however, the term home page has an entirely different meaning. The home page is the first or topmost page in your Web presentation—it's the entry point to the rest of the pages you've created and the first page your readers will see (see Figure 2.2).
The home page usually contains an overview of the content in the presentation available from that starting point—for example, in the form of a table of contents or a set of icons. If your content is small enough, you may include everything on that single home page—making your home page and your Web presentation the same thing.
The home page is the entry or starting point for the rest of your Web presentation.This may seem like a silly question. You wouldn't have bought this book if you didn't have some idea of what you want to put online already. But maybe you don't really know what it is you want to put up on the Web, or you have a vague idea but nothing concrete. Maybe it has suddenly become your job to put your company on the Web, and someone handed you this book and said "Here, this will help." Maybe you just want to do something similar to some other Web page you've seen that you thought was particularly cool.
What you want to put on the Web is what I'll refer to throughout this book as your content. Content is a general term that can refer to text, or graphics, or media, or interactive forms, or anything. If you were to tell someone what your Web pages are "about," you would be describing your content.
Your content is the stuff you're putting on the Web. Information, fiction, images, art, programs, humor, diagrams, games—all of this is content.What sort of content can you put on the Web? Just about anything you want to. Here are some of the kinds of content that are popular on the Web right now:
The Web is limited only by what you want to do with it. In fact, if what you want to do with it isn't in this list, or seems especially wild or half-baked, then that's an excellent reason to try it. The most interesting Web pages out there are the ones that stretch the boundaries of what the Web is supposed to be capable of.
If you really have no idea of what to put up on the Web, don't feel that you have to stop here, put this book away, and come up with something before continuing. Maybe by reading through this book you'll get some ideas (and this book will be useful even if you don't have ideas). I've personally found that the best way to come up with ideas is to spend an afternoon browsing on the Web and exploring what other people have done.
What do you want people to be able to accomplish in your presentation? Are your readers looking for specific information on how to do something? Are they going to read through each page in turn, going on only when they're done with the page they're on? Are they just going to start at your home page and wander aimlessly around, exploring your "world" until they get bored and go somewhere else?
As an exercise, come up with a list of several goals that your readers might have for your Web pages. The clearer your goals, the better.
For example, say you were creating a Web presentation describing the company where you work. Some people reading that presentation may want to know about job openings. Others may want to know where you're actually located. Still others may have heard that your company makes technical white papers available over the Net, and they want to download the most recent version of a particular one. Each of these is a valid goal, and you should list each one.
For a shopping catalog Web presentation, you might have only a few goals: to allow you readers to browse the items you have for sale by name or by price, and to order specific items once they're done browsing.
For a personal or special-interest presentation, you may have only a single goal: to allow your reader to browse and explore the information you've provided.
The goals do not have to be lofty ("this Web presentation will bring about world peace") or even make much sense to anyone except you. Still, coming up with goals for your Web documents prepares you to design, organize, and write your Web pages specifically to reach those goals. Goals also help you resist the urge to obscure your content with extra information.
If you're designing Web pages for someone else—for example, if you're creating the Web site for your company or if you've been hired as a consultant, having a set of goals for the site from your employer is definitely one of the most important pieces of information you should have before you create a single page. The ideas you have for the presentation may not be the ideas that other people have for the presentation, and you may end up doing a lot of work that has to be thrown away.
With your goals in mind, now try to organize your content into main topics or sections, chunking related information together under a single topic. Sometimes the goals you came up with in the previous section and your list of topics will be closely related. For example, if you're putting together a Web page for a bookstore, the goal of being able to order books fits nicely under a topic called, appropriately, "Ordering Books."
You don't have to be exact at this point in development. Your goal here is just to try to come up with an idea of what, specifically, you'll be describing in your Web pages. You can organize things better later, as you write the actual pages.
For example, say you were designing a Web presentation about how to tune your car. This is a simple example since tune-ups consist of a concrete set of steps that fit neatly into topic headings. In this example, your topics might include
Don't worry about the order of the steps or how you're going to get your reader to go from one section to another. Just list the things you want to describe in your presentation.
How about a less task-oriented example? Say you wanted to create a set of Web pages about a particular rock band because you're a big fan and you're sure there are other fans out there who would benefit from your extensive knowledge. Your topics might be
You can come up with as many topics as you want, but try to keep each topic reasonably short. If a single topic seems too large, try to break it up into subtopics. If you have too many small topics, try to group them together into some sort of more general topic heading. For example, if you were creating an online encyclopedia of poisonous plants, having individual topics for each plant would be overkill. You could just as easily group each plant name under a letter of the alphabet (A, B, C, and so on) and use each letter as a topic. That's assuming, of course, that your readers will be looking up information in your encyclopedia alphabetically. If they want to look up poisonous plants using some other method, you would have to come up with different topics.
Your goal is to have a set of topics that are roughly the same size and that group together related bits of the information you have to present.
At this point you should have a good idea about what you want to talk about and a list of topics. The next step is to actually start structuring the information you have into a set of Web pages. But before you do that, consider some "standard" structures that have been used in other help systems and online tools. This section describes some of those structures, their various features, and some important considerations, including
Think, as you read this section, how your information might fit into one of these structures or how you could combine these structures to create a new structure for your Web presentation.
Many of the ideas I describe in this section were drawn from a book called Designing and Writing Online Documentation by William K. Horton (John Wiley & Sons, 1994). Although Horton's book was written primarily for technical writers and developers working specifically with online help systems, it's a great book for ideas on structuring documents and for dealing with hypertext information in general. If you start doing a lot of work with the Web, you might want to pick up this book; it provides a lot of insight beyond what I have to offer.
Probably the easiest and most logical way to structure your Web documents is in a hierarchical or menu fashion, illustrated in Figure 2.3. Hierarchies and menus lend themselves especially well to online and hypertext documents. Most online help systems, for example, are hierarchical. You start with a list or menu of major topics; selecting one leads you to a list of subtopics, which then leads you to discussion about a particular topic. Different help systems have different levels, of course, but most follow this simple structure.
Figure 2.3. Hierarchical organization.
In a hierarchical organization, it's easy for readers to know their position in the structure; choices are to move up for more general information or down for more specific information. Providing a link back to the top level enables your reader to get back to some known position quickly and easily.
In hierarchies, the home page provides the most general overview to the content below it. The home page also defines the main links for the pages further down in the hierarchy.
For example, a Web presentation about gardening might have a home page with the topics shown in Figure 2.4.
Figure 2.4. Gardening home page.
If you selected Fruits, you would then be linked "down" to a page about fruits (Figure 2.5). From there you can go back to the home page, or you can select another link and go further down into more specific information about particular fruits.
Selecting Soft Fruits takes you to yet another menu-like page, where you have still more categories to choose from (Figure 2.6). From there you can go up to Fruits, back to the home page, or down to one of the choices in this menu.
Note that each level has a consistent interface (up, down, back to index), and that each level has a limited set of choices for basic navigation. Hierarchies are structured enough that the chance of getting lost is minimal. (This is especially true if you provide clues about where "up" is; for example, a link that says "Up to Soft Fruits" as opposed to just "Up"). Additionally, if you organize each level of the hierarchy and avoid overlap between topics (and the content you have lends itself to a hierarchical organization), hierarchies can be an easy way to find particular bits of information. If that was one of your goals for your readers, using a hierarchy may work particularly well.
Avoid including too many levels and too many choices, however, because you can easily annoy your reader. Too many menu pages results in "voice-mail syndrome." After having to choose from too many menus you forget what it was you originally wanted, and you're too annoyed to care. Try to keep your hierarchy two to three levels deep, combining information on the pages at the lowest levels (or endpoints) of the hierarchy if necessary.
Another way to organize your documents is to use a linear or sequential organization, much like printed documents are organized. In a linear structure, illustrated in Figure 2.7, the home page is the title, or introduction, and each page follows sequentially from that structure. In a strict linear structure, there are links that move from one page to another, typically forward and back. You may also want to include a link to "Home" that takes you quickly back to the first page.
Figure 2.7. Linear organization.
Context is generally easy to figure out in a linear structure simply because there are so few places to go.
A linear organization is very rigid and limits your readers' freedom to explore and your freedom to present information. Linear structures are good for putting material online when the information also has a very linear structure offline (such as short stories, step-by-step instructions, or computer-based training), or when you explicitly want to prevent your reader from skipping around.
For example, consider teaching someone how to make cheese using the Web. Cheese-making is a complex process that involves several steps that must be followed in a specific order.
Describing this process using Web pages lends itself to a linear structure rather well. When navigating a set of Web pages on this subject, you would start with the home page, which might have a summary or an overview of the steps to follow. Then, using the link for "forward," move on to the first step, "Choosing the Right Milk"; to the next step, "Setting and Curdling the Milk"; all the way through to the last step, "Curing and Ripening the Cheese." If you needed to review at any time, you could use the link for "back." Since the process is so linear, there would be little need for links that branch off from the main stem or links that join together different steps in the process.
You can soften the rigidity of a linear structure by allowing the reader to deviate from the main path. For example, you could have a linear structure with alternatives that branch out from a single point (see Figure 2.8). The offshoots can then rejoin the main branch at some point further down, or they can continue down their separate tracks until they each come to an "end."
Figure 2.8. Linear with alternatives.
For example, say you had an installation procedure for a software package that was similar in most ways, regardless of the computer type, except for one step. At that point in the linear installation, you could branch out to cover each system, as shown in Figure 2.9.
Figure 2.9. Different steps for different systems.
After the system-specific part of the installation, you could then link back to the original branch and continue on with the generic installation.
In addition to branching from a linear structure, you could also provide links that allow readers to skip forward or back in the chain if they need to review a particular step or if they already understand some content (see Figure 2.10).
Figure 2.10. Skip ahead or back.
A popular form of document organization on the Web is a combination of a linear structure and a hierarchical one, as shown in Figure 2.11. This structure occurs most often when very structured but linear documents are put online; the popular FAQ (Frequently Asked Questions) files use this structure.
Figure 2.11. Combination of linear and hierarchical.
The combination of linear and hierarchical documents works well as long as there are appropriate clues regarding context. Because the reader can either move up and down or forward and back, it's easy to lose one's mental positioning in the hierarchy when one crosses hierarchical boundaries by moving forward or back.
For example, say you were putting the Shakespearean play Macbeth online as a set of Web pages. In addition to the simple linear structure that the play provides, you could create a hierarchical table of contents and summary of each act linked to appropriate places within the text, something like that shown in Figure 2.12.
Figure 2.12. Macbeth hierarchy.
Because this is both a linear and hierarchical structure, on each page of the script you provide links to go forward, back, return to beginning, and up. But what is the context for going up?
If you've just come down into this page from an act summary, the context makes sense. "Up" means go back to the summary you just came from.
But say you went down from a summary and then went forward, crossing an act boundary (say from Act 1 to Act 2). Now what does "up" mean? The fact that you're moving up to a page that you may not have seen before is disorienting given the nature of what you expect from a hierarchy. Up and down are supposed to be consistent.
Consider two possible solutions:
A web is a set of documents with little or no actual overall structure; the only thing tying each page together is a link (see Figure 2.13). The reader drifts from document to document, following the links around.
Web structures tend to be free-flowing and allow the reader to wander aimlessly through the content. Web structures are excellent for content that is intended to be meandering or unrelated, or when you want to encourage browsing. The World Wide Web itself is, of course, a giant web structure.
An example of content organized in a web structure might be a set of virtual "rooms" created using Web pages. If you've ever played an old text-adventure game like Zork or Dungeon, or if you've used a MUD (Multi-User Dungeon), you are familiar with this kind of environment.
In the context of a Web presentation, the environment is organized so that each page is a specific location (and usually contains a description of that location). From that location you can "move" in several different directions, exploring the environment much in the way you would move from room to room in a building in the real world (and getting lost just as easily). For example, the initial home page might look something like what's shown in Figure 2.14.
Figure 2.14. The home page for a Web-based virtual environment.
From that page you can then explore one of the links, say, to go into the building, which would take you to the page shown in Figure 2.15.
Figure 2.15. Another page in the Web environment.
Each room has a set of links to each "adjacent" room in the environment. By following the links, you can explore the rooms in the environment.
The problem with web organizations is that it's too easy to get lost in them—just as you might in the "world" you were exploring in the example. Without any overall structure to the content, it's difficult to figure out the relationship between where you are and where you're going, and, often, where you've been. Context is difficult, and often the only way to find your way back out of a Web structure is to retrace your steps. Web structures can be extremely disorienting and immensely frustrating if you have a specific goal in mind.
To solve the problem of disorientation, you can use clues on each page. Two ideas:
The next step in planning your Web presentation is to figure out what content goes on what page and to come up with some simple links for navigation between those pages.
If you're using one of the structures described in the previous section, much of the organization may arise from that structure, in which case this section will be easy. If you want to combine different kinds of structures, however, or if you have a lot of content that needs to be linked together in sophisticated ways, sitting down and making a specific plan of what goes where will be incredibly useful later on as you develop and link each individual page.
Storyboarding a presentation is a concept borrowed from filmmaking in which each scene and each individual camera shot is sketched and roughed out in the order in which it occurs in the movie. Storyboarding provides an overall structure and plan to the film that allows the director and his staff to have a distinct idea of where each individual shot fits into the overall movie.
The storyboarding concept works quite well for developing Web pages as well. The storyboard provides an overall rough outline of what the presentation will look like when it's done, including which topics go on which pages, the primary links, maybe even some conceptual idea of what sort of graphics you'll be using and where they will go. With that representation in hand, you can develop each page without trying to remember exactly where that page fits into the overall presentation and its often complex relationships to other pages.
Storyboarding, borrwed from filmmaking, is the process of creating a rough outline and sketch of what your presentation will look like before you actually write any pages. Storyboarding helps you visualize the entire presentation and how it will look when it's complete.In the case of really large sets of documents, a storyboard enables different people to develop different portions of the same Web presentation. With a clear storyboard, you can minimize duplication of work and reduce the amount of contextual information each person needs to remember.
For smaller or simpler Web presentations, or presentations with a simple logical structure, storyboarding may be unnecessary. But for larger and more complex projects, the existence of a storyboard can save enormous amounts of time and frustration. If you can't keep all the parts of your content and their relationships in your head, consider doing a storyboard.
So what does a storyboard for a Web presentation look like? It can be as simple as a couple of sheets of paper. Each sheet can represent a page, with a list of topics that each page will describe and some thoughts about the links that page will include. I've seen storyboards for very complex hypertext systems that involved a really large bulletin board, index cards, and string. Each index card had a topic written on it, and the links were represented by string tied on pins from card to card (see Figure 2.16).
Figure 2.16. A complex storyboard.
The point of a storyboard is that it organizes your Web pages in a way that works for you. If you like index cards and string, work with it. If a simple outline on paper or on the computer works better, use that instead.
Some things to think about when developing your storyboard are as follows:
Designing a Web presentation, like designing a book outline, a building plan, or a painting, can sometimes be a complex and involved process. Having a plan before beginning can help you keep the details straight and help you develop the finished product with fewer false starts. In this chapter, you've learned how to put together a simple plan and structure for creating a set of Web pages, including
With that plan in place, you can now move on to the next few chapters and learn the specifics of how to write individual Web pages, create links between them, and add graphics and media to enhance the presentation for your audience.
Q: This all seems like an awful lot of work. All I want to do is make something simple, and you're telling me I have to have goals and topics and storyboards.
A: If you are doing something simple, then no, you won't need to do much, if any, of the stuff I recommend in this chapter. But once you're talking about two or three interlinked pages or more, it really helps to have a plan before you start. If you just dive in, you may discover that keeping everything straight in your head is too difficult. And the result may not be what you expected, making it hard for people to get the information they need out of your presentation as well as making difficult for you to reorganize it so that it makes sense. Having a plan before you start can't hurt, and it may save you time in the long run.
Q: You've talked a lot in this chapter about organizing topics and pages, but you've said nothing about the design and layout of individual pages.
A: I discuss that later in this book, after you've learned more about the sorts of layout HTML (the language used for Web pages) can do, and the stuff that it just can't do. There's a whole chapter and more about page layout and design on Day 6, in Chapter 11, "Writing and Designing Web Pages: Dos and Don'ts."
Q: What if I don't like any of the basic structures you talked about in this chapter?
A: Then design your own. As long as your readers can find what they want or do what you want them to do, there are no rules that say you must use a hierarchy or a linear structure. I presented those structures only as potential ideas for organizing your Web pages.
