Managing A Weekly Publication
This chapter is from the book
This chapter is from the book
This chapter is from the book
"For a list of all the ways technology has failed to improve the
quality of life, please press three."
—Alice
Kahn
In Chapter 2, "Updating a Daily News Site," you put together a daily newspaper. You learned how to fashion columns and create readable style. But more magic is needed to manage the design and technology of publications—especially large publications and information sites. In this chapter, you explore some of these issues through WebReview.com, an award-winning resource site for web developers and designers.
Project Snapshot
The problem: Managing larger, regularly updated, content-rich sites.
This chapter is for anyone who is looking for solutions to manage navigation, presentation, and effective markup of large, content-rich sites.
Technical Specs
The following are the technical specifications that you need to manage a weekly publication:
Markup used—XHTML 1.0 (You can also use HTML 4 if you prefer.)
Document type definition (DTD) used—Transitional.
From a markup perspective, I used XHTML 1.0 transitional when I developed the site. My rationale for doing so was two-fold. First, a site that's predominantly made up of text conceivably can be simplified to ensure crisp separation of document formatting and presentation, even using complicated tables to ensure the layout remains intact across platforms and browsers. The rationale was a good one, but during the production process, I learned my choice was compromised by the amount of ads I had to design into the site. The more complex a layout becomes, the more difficult it becomes to separate document formatting from presentation.
Structure Inspiration
A primary concern with any regularly published, content-rich site is how to effectively manage a site's infrastructure. There's no definite answer here—much depends on your publication's specific needs. However, it's a good idea to grab a pen and paper, a great big white board or charting software, such as Visio, and work out the site's physical structure before you attempt to write any of the markup.
A strong physical site structure helps ensure that your markup is more consistent. Where things such as directories for images, media, and style sheets, archived information, and so on, are placed will immediately be reflected in the way you write your internal links. This, in turn, reflects on the markup and the speed at which you can troubleshoot problematic documents.
Unfortunately, many of you will walk into situations that you can't change; pre-existing problems must be dealt with as best as possible. Streamline wherever you can. Cleaner markup that relies on style sheets makes so much sense when it's put into this perspective. Imagine how easy it would be to update a site simply by changing its style sheet and not having to rebuild it from the ground up? Now that's practical.
The second reason I selected XHTML 1.0 was that I wanted to make a statement that showed that XML—in the form of XHTML—could easily be used on the web. I learned some interesting lessons from making the choice to use XHTML, especially in terms of JavaScript, as you see later in this chapter.
Because the exercises in this chapter are comparative, you can choose to use HTML 4 or XHTML 1.0. My only recommendation is that you stick to the transitional DTD to ensure utmost flexibility in a design that's still primarily accessed through the web. If you're shifting toward a publication that appeals to users accessing with wireless and other devices, consider moving to strict markup instead.
Here are the additional technologies or skills that you need:
Familiarity with HTML.
Familiarity with a text editor, such as Notepad, SimpleText, or a favorite HTML editor.
Browser considerations: Cross-browser compatible site.
You must use an external style sheet and an embedded style sheet.
Here's how you should structure your site. In the case of WebReview.com, the site uses a hierarchical structure. Top-level pages are used daily. The second tier contains information by year, and the third level contains the individual issues and their dependents by date.
How a real-world site is structured will be determined greatly by individual needs. So if you have a publication site that is updated monthly, you'll have different archival management needs. What's more, you might already be working on a site that has legacy problems with structure and have to make do. See the sidebar, "Structure Inspiration" for some ideas on how to solve structure problems.