• Choose a category
• All
• Classic-Fiction

After all participants suggested everything they thought their site needed, I shooed them out of the room. Using only paper and pencil, I created a more organized sketch based on how I thought the information should be organized. My diagram looked like the one shown in Figure 2-2.

Figure 2-2: This chart shows an organized represen-tation of the data.

Creating a site overview

Keep these suggestions in mind while creating a site overview diagram:

♦ Use the Law of Seven. This law suggests that people generally can’t handle more than seven choices at a time. Try not to have more than seven major segments of information at any level. Each of these can be separated into as many as seven chunks, and each of these can have seven chunks.

Note: Even this book uses the Law of Seven! (Well, sorta — this book has eight minibooks.) The monster you’re holding is too intimidating to look at as just one book, but if you break it into smaller segments, it becomes easier to manage. Clever, huh?

♦ Identify commonalities. While you look over the data, general groupings emerge. In the university example, I could easily see that we had a lot of course data, degree information, information about faculty, and research. I wanted to consider a few other topics that didn’t fit as well, until I realized that they could be grouped as events and opportunities.

♦ Try to assign each topic to a group. If you read Book VI, you probably recognize that I’m doing a form of data normalization here. This data structure isn’t necessarily a formal one, but I’m using the same sort of thinking, so it could be. Clearly, I’m using the principle of functional dependency.

♦ Arrange a hierarchy. Group the topics from most general to most specific. For example, the term course info is very broad. N100 is a specific course, and it may have many sections (specific date, time, and instructor combinations). Thus, it makes sense to group sections under N100 and to group N100 under courses.

♦ Provide representative data. Not every single scrap of information is necessary here. The point is to have enough data so you can see the relationships among data.

♦ Keep in mind that this diagram does not represent the site design. When I showed this diagram to people, many assumed that I was setting up a menu structure, and they wanted a different kind of organization or menu. That’s not the point yet. The purpose of this type of diagram is to see how the data itself fits together. Of course, this diagram tends to inform the page setup and the menu structure, but it doesn’t have to.

♦ Not each box is a page. It might be, but it doesn’t have to be. Later in the process, you can decide how to organize the parts of the site. For example, we decided to put all sections of N100 on one page with the N100 information using AJAX.

Building this sort of site diagram is absolutely critical for larger sites, or else you never really grasp the scope of the project. Have the major stakeholders look it over to see whether it accurately reflects the information you’re trying to convey.

Building the site diagram

The site diagram is a more specific version of the site overview. At this point, you make a commitment about the particular pages you want in the system and their organizational relationship. Figure 2-3 shows a site diagram for the department site.

Figure 2-3: Now, you have a site diagram for the department site.

Semantic navigation

One idea that has been popular in Web design circles is the notion of semantic navigation, where you set up your menu structure so that it reflects the jobs people are trying to do, rather than reflect the hierarchy of your sites. For example, a university department site might have a menu for common student activities, alumni, and faculty.

This idea can be quite helpful if done properly, but don’t try to set up your entire site this way because it involves too much duplication of data. (Students and faculty both need course information, but you don’t want to post that