Chapter 27. Organizing and Managing a Website

The bulk of this book has led you through the design and creation of your own web content, from text to graphics and multimedia, as well as the implementation of basic JavaScript functionality for enhanced user interaction. Along the way I’ve noted some of the ways you can think about the lifecycle of that content, but in this chapter you’ll learn how to look at your work as a whole.

This chapter shows you how to think about organizing and presenting multiple web pages so that visitors will be able to navigate among them without confusion. You’ll also learn about ways to make your website memorable enough to visit again and again. Web developers use the term sticky to describe pages that people don’t want to leave. Hopefully this chapter will help you to make your websites downright gooey!

Because websites can be (and usually should be) updated frequently, it’s essential to create pages that can be easily maintained. This chapter shows you how to add comments and other documentation to your pages so that you—or anyone else on your staff—can understand and modify your pages, and also introduces you to version control so that you can innovate individually or as part of a team without overwriting work that you might want to save.

When One Page Is Enough

Building and organizing an attractive and effective website doesn’t always need to be a complex task. If you are creating a web presence for a single entity (such as a local event) that requires only a brief amount of very specific information, you can effectively present that information on a single page without a lot of flashy graphics. In fact, there are several positive features to a single-page web presence:

• All the information on the site downloads quicker than on more extensive sites.

• The whole site can be printed on paper with a single print command, even if it is several paper pages long.

• Visitors can easily save the site on their hard drives for future reference, especially if it uses a minimum of graphics.

• Links between different parts of the same page usually respond more quickly than links to other pages.

Figure 27.1 shows the first part of a web page that serves its intended audience better as a single lengthy page than it would as a multipage site. The page begins, as most introductory pages should, with a succinct explanation of what the page is about and who would want to read it. A detailed table of contents allows visitors to skip directly to the reference material in which they are most interested. It contains about eight paper pages worth of text explaining how to begin the process of buying a house—something a visitor might think about printing out and reading later, perhaps while also taking notes.

Figure 27.1 A good table of contents can make a lengthy page easy to navigate.

As Figure 27.2 shows, each short section of the page is followed by a link leading back to the table of contents, so navigating around the page feels much the same as navigating around a multipage site. Because the contents of the page are intended as a handy reference, visitors will definitely prefer the convenience of bookmarking or saving a single page instead of several separate pages.

Figure 27.2 Always provide a link back to the table of contents after each section of a long web page.

Having seen all the fancy graphics and layouts in this book, you might be tempted to forget that a good, old-fashioned outline is often the clearest and most efficient way to organize long web pages within a site.

Organizing a Simple Site

Although single-page sites have their place, most companies and individuals serve their readers better by dividing their site into short, quick-read pages surrounded by graphical navigation that allows them to reach almost all the information they could want within a few clicks. Furthermore, using multiple pages instead of a series of very long pages minimizes scrolling around on the page, which can be especially bothersome for visitors who are using mobile devices to view the site or who have relatively low-resolution monitors (less than 800×600).

The goal of the home page is simply to make the organization visible on the Internet, but also—and more importantly—act as a portal to the information contained within the site itself. The main page of a site should provide the user with enough information to provide a clear picture of the organization, as well as traditional address and telephone contact information and an email address to contact with questions or feedback. It should also provide clear pathways into the highly structured information that should be contained on other pages in the site. The main page shown in Figure 27.3 provides examples of all these good features: basic information, contact information, and paths to information for multiple audiences.

Figure 27.3 This university main page uses a basic design, minimal but useful graphics, and clear structure to entice users to explore for more information.

One of the most common mistakes beginning website developers make is creating pages that look different than other pages on the site. Another equally serious mistake is using the same, publicly available clip art that thousands of other web authors are also using. Remember that on the Internet, one click can take you around the world. The only way to make your pages memorable and recognizable as a cohesive site is to make all your pages adhere to a unique, unmistakable visual theme. In other words, strive for uniqueness as compared to other websites, yet uniformity within the site itself.

As an example of how uniformity can help make a site more cohesive, think about large, popular sites you might have visited, such as ESPN.com. If you visit the MLB section at ESPN.com (see Figure 27.4) and the NFL section (see Figure 27.5), you’ll notice a very similar structure.

Figure 27.4 The MLB section at ESPN.com.

Figure 27.5 The NFL section at ESPN.com.

In both examples, you see navigation elements at the top of the page (including some sub-navigation elements), a large area in the middle of the page for the featured item graphic, a rectangle on the right side containing links to top stories at the moment, and a second rectangle under the top stories links for the display of an advertisement. The only difference between the MLB section and the NFL section is the color scheme: The MLB section is part of a predominantly blue color scheme, whereas the NFL section is predominantly green. However, in both sections, you know that if you want to read the popular news stories, you look to the right of the page. If you want to navigate to another section in the site or to the site’s main page, you look to a navigational element in the top left of the page.

These consistent elements help ensure your users will be able to navigate throughout your content with confidence. From a maintenance perspective, the consistent structural template enables you to reuse pieces of the code. This code reuse typically happens through dynamic server-side programming outside the scope of this book, but in general it means that instead of copying and pasting the same HTML and JavaScript over and over, that client-side code only exists in one place and is applied dynamically to the content. Therefore, instead of making changes to thousands of files, you would only need to make a change once.

Organizing a Larger Site

For complex sites, sophisticated layout and graphics can help organize and improve the look of your site when used consistently throughout all of your pages. To see how you can make aesthetics and organization work hand-in-hand, let’s look at examples of navigation (and thus underlying organization) for a few sites that present a large volume of information to several different audiences.

Figure 27.6 shows the main page of Amazon.com, specifically with the side navigation selected. Amazon is in the business of selling products, plain and simple. Therefore, it makes sense for Amazon to show product categories as the main navigational elements, as shown in this figure.

Figure 27.6 Amazon.com shows product categories as primary navigation elements.

Although Amazon is in the business of selling products, it still has to provide information regarding who it is, how to contact it, and other ancillary yet important information to enhance the business-to-consumer relationship. Links to this sort of information appear in the footer, or bottom portion, of the Amazon.com website—outside of the viewing area of this screenshot. When creating your site template, you must determine the most important content areas and how to organize that content; also, remember to provide users with basic information—especially if that information will enhance your image and make the user feel as if you value what they have to say.

The next example is of a secondary page within the Starbucks.com website. All of the pages in the Starbucks.com website follow one of the common types of presenting navigation and subnavigation: a horizontal strip for main navigation, with secondary elements for that section placed in a vertical column on the left. As shown in Figure 27.7, the section the user is currently browsing (About Us) is highlighted. This visual indicator helps users orient themselves within the site. Using a visual indicator is a useful tactic because your users might arrive at a page via a search engine or by a link from another website. After your users arrive, you want them to feel at home—or at least feel as if they know where they are in relation to your site—once they get there.

Figure 27.7 This Starbucks.com secondary page shows a main navigation element selected with secondary navigation on the left side of the page.

As you can see by the different main navigation elements—Our Coffees, Our Stores, Starbucks Card, At Home, For Business, About Us, and Shop Online—the Starbucks website has to serve the needs of many different types of people coming to the website for many different reasons. As you organize your own site content, determine the information that is most important to you, as well as that which is most important to your users, and create a navigation scheme that finds a happy medium between the two.

Figure 27.8 shows another example of a navigation style, this time with a twist on the standard top navigation/left-side navigation scheme. In this example, the left-side navigation (secondary navigation in this case) also appears in a drop-down menu under the main navigation (refer to Chapter 11, “Using CSS to Do More with Lists, Text, and Navigation,” for information on how to do something like this). Hovering the mouse over any of the other main navigation elements shows similar menus. This scheme enables users to have an entire site map at their fingertips because they would be able to reach any place in the site within one click of any other page.

Figure 27.8 The BAWSI.org website shows sub-navigation attached to each main navigation element.

You will also notice that the Overview link in the side navigation window is styled a bit differently—with heavier purple text—than the other links in the window, indicating to visitors what page they are on. This visual detail, similar to what you saw on the Starbucks site, is an unobtrusive way to provide users with a sense of where they are within the current navigational scheme.

There are many different types of navigation styles and ways of indicating to users just where they are and where they might want to go next. Keep in mind the following fact: Studies have repeatedly shown that people become confused and annoyed when presented with more than seven choices at a time, and people feel most comfortable with five or fewer choices. Therefore, you should avoid presenting more than five links (either in a list or as graphical icons) next to one another if at all possible and definitely avoid presenting more than seven at once. Amazon.com gets a pass here because it is an Internet superstore and users expect a lot of “departments” in which to shop when they get there. But when you need to present more than seven links in a navigation list, break them into multiple lists with a separate heading for each of the five to seven items, as you saw in the Amazon.com example in Figure 27.6.

It will also help your readers navigate your site without confusion if you avoid putting any page more than two (or, at most, three) links away from the main page. You should also always send readers back to a main category page (or the home page) after they’ve read a subsidiary page. In other words, try to design somewhat of a flat link structure in which most pages are no more than one or two links deep. You don’t want visitors to have to rely heavily, if at all, on their browsers’ Back buttons to navigate through your site.

Writing Maintainable Code

If you’ve ever done any programming before reading this book, you already know how important it is to write code that can be maintained—that is, you or someone else should be able look at your code later and not be utterly confused by it. The challenge is to make your code as immediately understandable as possible. There will come a time when you’ll look back on a page that you wrote and you won’t have a clue what you were thinking or why you wrote the code the way you did. Fortunately, there is a way to combat this problem of apparent memory loss!

Documenting Code with Comments

Whenever you develop an HTML page or JavaScript snippet, keep in mind that you or someone else will almost certainly need to make changes to it someday. Simple text web pages are usually easy to read and revise, but complex pages with graphics, tables, and other layout tricks can be quite difficult to decipher.

To see what I’m talking about, visit just about any page in a web browser and view its source code. Using Internet Explorer, click the View menu, and then click Source. Using Firefox, click the View menu, and then click Page Source. You might see a jumbled bunch of code that is tough to decipher as pure HTML. This might be due to the fact that the markup has been generated dynamically by content management software systems. Or it might be due to the fact that its human maintainer has not paid attention to structure, ease of reading, code commenting, and other methods for making the code readable by humans. For the sake of maintaining your own pages, I encourage you to impose a little more order on your HTML markup. The same goes for your JavaScript: Proper indentation is your (and your future development partner’s) friend.

As you have seen in several different chapters throughout this book, you can enclose comments to yourself or your coauthors between <!-- and --> tags. These comments will not appear on the web page when viewed with a browser but can be read by anyone who examines the HTML code in a text editor or via web browser’s View Source (or View Page Source) function. The following example provides a little refresher just to show you how a comment is coded:

<!-- This image needs to be updated daily. -->
<img src="headline.jpg" alt="Today's Headline" />

As this code reveals, the comment just before the <img /> tag provides a clue as to how the image is used. When someone reads this code, he knows immediately that this is an image that must be updated every day. The text in the comment is completely ignored by web browsers.

Indenting Code for Clarity

I have a confession. Throughout the book I’ve been carefully indoctrinating you into an HTML code development style without really letting on. It’s time to spill the beans. You’ve no doubt noticed a consistent pattern with respect to the indentation of all the HTML code in the book. More specifically, each child tag is indented to the right two spaces from its parent tag. Furthermore, content within a tag that spans more than one line is indented within the tag.

The best way to learn the value of indentation is to see some HTML code without it. You know how the song goes—”you don’t know what you’ve got ‘til it’s gone.” Anyway, here’s a very simple table coded without any indentation:

<table>
<tr><td>Cell One</td><td>Cell Two</td></tr>
<tr><td>Cell Three</td><td>Cell Four</td></tr>
</table>

Not only is there no indentation, there also is no delineation between rows and columns within the table. Now compare this code with the following code, which describes the same table:

<table>
  <tr>
    <td>Cell One</td>
    <td>Cell Two</td>
  </tr>
  <tr>
    <td>Cell Three</td>
    <td>Cell Four</td>
  </tr>
</table>

This heavily indented code makes it plainly obvious how the rows and columns are divided up via <tr> and <td> tags.

Consistent indentation might even be more important than comments when it comes to making your HTML code understandable and maintainable. And you don’t have to buy into this specific indentation strategy. If you’d rather use three or four spaces instead of two, that’s fine. And if you want to tighten things up a bit and not indent content within a tag, that also works. The main thing to take from this is that it’s important to develop a coding style of your own and then ruthlessly stick to it.

Thinking About Version Control

If you’ve ever used Google Docs, you have encountered a form of version control; in Google Docs, Google automatically saves revisions of your work as you are typing. This is different than simply automatically saving your work (although it does that, too) because you can revert to any revision along the way. You might have encountered this concept when using popular blog-authoring software such as Blogger or WordPress, or even when editing wikis—both of these also enable users to revise their work without overwriting, and thus deleting for all time, the previous work.

You might be wondering, “Well, what does that have to do with code? You’re talking about documents.” The answer is simple: Just as you might want to revert to a previous edition of an article or letter, you might want to revert to a previous edition of your code. This could be because you followed a good idea to the end, and the code just proved untenable, but you don’t want to start over entirely—just at a certain point along your revision path.

There is more to version control than just revision history. When you start using version control systems to maintain your code, you will hear terms like:

• Commit/check-in and checkout—When you put an object into the code repository, you are committing that file; when you checkout a file, you are grabbing it from the repository (where all the current and historical versions are stored) and working on it until you are ready to commit or check-in the file again.

• Branch—The files you have under version control can branch or fork at any point, thus creating two or more development paths. Suppose you want to try some new display layouts or form interactivity but you don’t want an existing site to appear modified in any way. You might have started with one master set of files but then forked this set of files for the new site, continuing to develop them independently. If you continued developing the original set of files, that would be working with the trunk.

• Change/diff—This is just the term (change OR diff) for a modification made under version control. You might also hear diff used as a verb, as in “I diffed the files,” to refer to the action of comparing two versions of an object. (There is an underlying UNIX command called diff.)

There are many more terms than just these few listed here, but if you can conceptualize the repository, the (local) working copy, and the process of checking in and checking out files, you are well on your way to implementing version control for your digital objects.

Using a Version Control System

Although there are several different version control systems available for use—some free and open source and some proprietary—two of the most popular systems are Subversion (http://subversion.apache.org) and Git (http://git-scm.com). If you have a web hosting service that enables you to install Subversion, you can create your own repository and use a Subversion client to connect to it.

But an increasingly popular tool is Git, which is a decentralized approach to version control and also offers numerous tools and hosting options for users who want to get started with a repository but don’t necessarily want/need/understand all the extra installation and maintenance overhead that goes with it. One such hosting option for Git repositories is GitHub (http://github.org), which allows users to create accounts and store and maintain as many code repositories for free as they would like (as long as they are open source), while also providing paid solutions for users who would like to maintain private code repositories.

For anyone wanting to get started with version control, I recommend Git and GitHub for its relative ease of use and free, cross-platform tools for use. The GitHub Help site would be a great place to start: http://help.github.com/. An added benefit of the already-free GitHub account is the ability to use Gist (http://gist.github.com), which is a way to share code snippets (or whole pages) with others, while these snippets themselves are git repositories and thus versioned and forkable in their own right. GitHub repositories, including Gists, are both excellent ways to get started with version control of your work.

Summary

This chapter has given you examples and explanations to help you organize your web pages into a coherent site that is informative, attractive, and easy to navigate. Web users have grown to become quite savvy in terms of expecting well-designed websites, and they will quickly abandon your site if they experience a poor design that is difficult to navigate.

This chapter also discussed the importance of making your code easy to maintain by adding comments and indentation. Comments are important not only as a reminder for you when you revisit code later but also as instruction if someone else should inherit your code. Indentation might seem like an aesthetic issue, but it can truly help you to quickly analyze and understand the structure of a web page at a glance. Because you are likely soon to need code management tools either for yourself or yourself plus other developers in your group, you were introduced to a few concepts in version control. Version control enables you to innovate without losing your solid, production-quality work and also provides more opportunities for other developers to work within your code base.

Q&A

Q. I’ve seen pages that ask viewers to change the width of their browser window or adjust other settings before proceeding beyond the home page. Why do they do this?

A. The snarky response is that the site creators do not care about their users. Never force your users to do something differently than they are doing with their browsers, and especially never, ever resize the browser automatically. Those are some of the biggest usability no-no’s. When sites tell you to change your settings, it is because the site creators think they can offer a better presentation if they’re given that specific control over the size of users’ windows or fonts. Of course, few people bother to change their settings when told to do so (as they shouldn’t), so these sites often look weird or unreadable. You’ll be much better off using the tips you learn in this book to make your site readable and attractive using any window size and using a wide variety of browser settings. The better organized your site is, the more usable it will be for visitors.

Q. Will lots of comments and spaces make my pages load slower when someone views them?

A. The size of a little extra text in your pages is negligible when compared to other, chunkier web page resources (such as images and multimedia). Besides, slower dial-up modem connections typically do a decent job of compressing text when transmitting it, so adding spaces to format your HTML doesn’t usually change the transfer time at all. You’d have to type hundreds of comment words to cause even one extra second of delay in loading a page. And keep in mind that with the broadband connections (cable, DSL, and so on) that many people now have, text travels extremely fast. It’s the graphics that slow pages down, so squeeze your images as tightly as you can, but use text comments freely.

Workshop

The workshop contains quiz questions and activities to help you solidify your understanding of the material covered. Try to answer all questions before looking at the “Answers” section that follows.

Quiz

1. What are three ways to ensure all your pages form a single cohesive website?

2. What two types of information should always be included on your home page?

3. You want to say, “Don’t change this image of me. It’s my only chance at immortality,” to future editors of a web page, but you don’t want users who view the page to see that message. How would you do it?

Answers

1. Use consistent background, colors, fonts, and styles. Repeat the same link words or graphics on the top of the page that the link leads to. Repeat the same small header, buttons, or other element on every page of the site.

2. Use enough identifying information so that users can immediately see the name of the site and what it is about. Also, whatever the most important message you want to convey to your intended audience is, state it directly and concisely. Whether it’s your mission statement or trademarked marketing slogan, make sure that it is in plain view here.

3. Put the following comment immediately before the <img /> tag:

<!-- Don't change this image of me.
     It's my only chance at immortality. -->

Exercises

• Grab a pencil (the oldfangled kind) and sketch out your website as a bunch of little rectangles with arrows between them. Sketch a rough overview of what each page will look like by putting squiggles where the text goes and doodles where the images go. Each arrow should start at a doodle icon that corresponds to the navigation button for the page the arrow leads to. Even if you have the latest whiz-bang website management tools (which are often more work than just creating the site itself), sketching your site by hand can give you a much more intuitive grasp of which pages on your site will be easy to get to and how the layout of adjacent pages will work together—all before you invest time in writing the actual HTML to connect the pages together. Believe it or not, I still sketch out websites like this when I’m first designing them. Sometimes you can’t beat a pencil and paper!

• Open the HTML files that make up your current website, and check them all for comments and code indentation. Are there areas in which the code needs to be explained to anyone who might look at it in the future? If so, add explanatory comments. Is it difficult for you to tell the hierarchy of your code? Is it difficult to see headings and sections? If so, indent your HTML so that the structure matches the hierarchy and thus enables you to jump quickly to the section you need to edit.