Working with a small Web presentation of up to a couple hundred pages is relatively easy. You can keep the overall structure in your head, write the pages as the need comes up, and insert them in the appropriate places reasonably easily. Your readers can generally find what they want even if your structure isn't as good as it could be.
With larger presentations, such as those produced by companies or organizations, the rules tend to be somewhat different. There might be more content than you can work on yourself. The structure might be much more immense and complex. Much of the material you put up on the Web might not have been designed for use on the Web in the first place.
This chapter describes the issues you could run into if you end up managing a larger site. If you're the Webmaster for your site, or if you're involved in setting the standards for Web pages in your organization, you'll want to read this chapter.
The things you'll learn about in this chapter include the following topics:
With a smaller presentation, having a coherent plan before you start isn't crucial to the success of your presentation. You can generally keep the structure orderly without a written plan, add pages as they need to be added, and not disturb things overly much. For a larger presentation, if you try to keep the whole project in your head, it's likely that you'll lose track of portions of it, forget how they fit together, and eventually lose control, which requires lots of maintenance work later on. Having a plan of attack beforehand will help keep everything straight.
A plan is particularly important if other people will be working on the site with you. By having a plan for the presentation, you can let other people work on their individual sections, and each of you will know where the other's section fits into the overall plan for the site.
Most of the rules I described in earlier chapters for creating a plan for a presentation still apply for larger presentations as well. So, let's review the steps for making a plan in the new light of this larger presentation:
Figure 30.1. Smaller presentations.
Each subpresentation can have its own tree of pages, its own home page, and sometimes even its own site and server. By extension, you can have different people working on different subpresentations without worrying that their work will conflict or overlap with someone else's work in the larger tree. You, as the Webmaster or team leader, can then focus on the bigger picture of how the bigger presentation fits together.
Larger presentations tend of be made up of content that was written explicitly for the presentation itself, as well as content that was converted from its original form, such as press releases, newsletters, technical papers, chapters from books, posters, and so on. Handling all that content and making sure all of it ends up online and accessible is probably going to be the bulk of the setup and maintenance for the site—a tedious task, but an important one nonetheless.
In this section, you'll learn how to deal with these different kinds of content and the best way to manage them.
For the content you'll be writing explicitly for your large Web presentation, the same techniques apply for how you plan to get it online as they did for smaller presentations. Depending on how you prefer to work, you can work in HTML itself, use a tag editor, or write in a word processor and convert the result to HTML.
The market for HTML editors and converters is growing daily, and any list I provide will soon be out of date. Your best bet is to consult a list on the Web, which can be much more rapidly updated as new editors appear. Try the one at Yahoo at http://www.yahoo.com/Computers/World_Wide_Web/HTML_Editors/.
A lot of content that ends up on Web sites (particularly large ones) was produced originally for hardcopy or for some other medium—for example, press releases or documentation. To put this kind of material on the Web, you can convert it to HTML, add links to it, massage it in any other way you might need to, and then publish it. Hopefully, you'll only have to do this once; for content that needs frequent updating, stay tuned for the hints in the next section.
HTML converters exist for many common word-processing and page-layout formats, both as freely available tools and often as add-ins by the company that produced the application you work with. (Call your vendor to see whether they have one available or are planning on one.) Keep in mind that you might have to configure the converter to work with the way you've set things up in the original file, and that the result might lose much of the layout that the original had. See http://www.yahoo.com/Computers/World_Wide_Web/HTML_Converters/ for a constantly updated list of available converters.
You can save a lot of time in the HTML conversion process by planning ahead when you make the original hardcopy documents. Just a few small adjustments in how you work can save time at the end of the process. Here are some hints for making conversion easier:
The final kind of content you might end up including on your site is the kind that is produced for both hardcopy and online and is updated reasonably frequently. For this kind of content, coming up with a good method of publishing it can be difficult. If you try to maintain the documents in your favorite word processor, say, and then convert to HTML, adding the extra links for formatting or organization is often one of the more tedious parts of the task—particularly if you have to add them multiple times every time the HTML is regenerated. On the other hand, maintaining separate sources for both hardcopy and HTML is an even worse proposal because you can never be sure that all your changes make it in both places. Not to mention the fact that hardcopy and HTML are inherently different, and writing the same document for both can result in a document that is difficult to read and navigate in either medium.
There is no good solution to this problem. There are, however, several tools available that purport to help with the process—two for the FrameMaker word processing/layout application, and one that works as a separate application on different types of files. I expect that more will appear as time goes on.
FrameMaker itself, which is widely in use for large documentation projects but less used in smaller organizations, makes an outstanding Web development tool. Unlike many other documentation tools, it provides a hyperlinking facility within the program itself with which you can create links. (It was designed to allow online help files to be written directly in the program.) Then, when you convert the Frame files to HTML, those links can be preserved and regenerated over and over again.
FrameMaker's potential strengths as a Web development tool have not been overlooked by Frame Technologies, the makers of FrameMaker. The newest version of FrameMaker, FrameMaker 5.0, has a built-in export filter that converts existing documents to HTML and preserves hypertext links from cross-references and Frame's own hyperlinking facility. FrameMaker 5 is available for most platforms (Windows, Macintosh, most flavors of UNIX, with all the files compatible between platforms). It also reads files created by MS Word, WordPerfect, and RTF format (which can be generated by many other programs), so converting your existing content to Frame isn't such a painful process. You can find out more about FrameMaker 5.0 from Frame's Web site at http://www.frame.com/.
Quadralay's WebWorks Publisher, part of its integrated WebWorks system, converts FrameMaker files to HTML. It also converts internal graphics to GIF files, splits files into smaller chunks for Web viewing (and links them all together), and converts tables and equations to inline transparent GIF files. (I assume that future versions will support the HTML 3.0 equivalents for these features.) WebWorks publisher is available for Windows and Sun systems, and it'll be available soon for Macintosh and other UNIX systems. For more information, check out http://www.quadralay.com/Products/products.html.
Interleaf's Cyberleaf is a publishing tool that operates on Interleaf, FrameMaker, RTF, WordPerfect, and ASCII files. It converts text to HTML, graphics to GIF format, and cross-references to links. It also provides a linking facility that enables you to set links within your generated files, and preserves those links even if you regenerate. Cyberleaf also includes several templates for different types of Web pages. Cyberleaf works on Sun, HP, Digital, and IBM UNIX workstations, and should be available for Windows later this year. You can find out more about Cyberleaf from Interleaf's Web site at http://www.ileaf.com/ip.html.
Why work in HTML at all? If the source files are so difficult to convert effectively and if you have to change your entire production environment in order to produce both hardcopy and HTML, you might wonder whether all the bother is worth it.
Fortunately, there are alternatives to working in HTML while still being able to distribute documents over the Web.
Small documents such as press releases might be best distributed as ordinary text. Most servers are set up to distribute files that have a .txt extension as text files, so you won't have to convert them to HTML at all. Just put them in a directory, provide an index file (or turn on directory indexing in your server for that directory), and you're done. Of course, you won't have links from those files, and they'll be displayed in Courier when they're viewed in a browser, but it's a good compromise.
Brochures, newsletters, and other documents that rely heavily on sophisticated page layout might be best distributed as Acrobat (PDF) files (see Figure 30.2). Adobe Acrobat, a cross-platform document translation tool which you learned about in Chapter 26, "Plug-ins and Embedded Objects," enables you to save documents from just about any program as full-page images, preserving all the layout and the fonts, which can then be viewed on any system that has the Acrobat viewer. Fortunately, the viewer is freely available on Adobe's Web site (http://www.adobe.com) as a helper application or a plug-in for Netscape. For many sites, using Acrobat files might be the ideal solution to producing files for both hardcopy and the Web.
Finally, if your organization works with SGML, SoftQuad's Panorama is a viewer that allows a Web browser to view SGML files. You won't need to edit or convert your files at all; as long as your readers have the viewer, they'll be able to read your files. Panorama comes in two versions: a free version (for Windows, UNIX, and Macintosh), and a supported, more fully featured version, Panorama PRO (Windows only). Panorama free is available for downloading and will be bundled with NCSA Mosaic. You can find out more about Panorama from SoftQuad's home page at http://www.sq.com/products/panorama/panor-fe.htm.
A new development for creating larger Web sites is the availability of complete Web site creation and management systems. In the olden days, you developed Web pages individually, linked them together by hand, and then FTPed them up to your Web server and tested them to make sure everything worked—all the stuff you've been learning in this book.
Web site management tools are intended to integrate a lot of that process so that doing things such as searching for dead links and getting an idea of the overall view of a site is easier to manage. Here are a few of the more popular commercial Web management packages.
Adobe SiteMill is the larger and more fully featured version of Adobe PageMill for the Macintosh. Whereas PageMill was used to create individual pages, SiteMill includes a tool for keeping track of links between pages in the presentation and automatically checking the validly of and fixing those links. Figure 30.3 shows the site view window in Adobe SiteMill.
FrontPage, which you learned about in Chapter 6, "HTML Assistants: Editors and Converters," also has integrated site creation and management capabilities, including the ability to include search engines, guestbooks, navigation bars, BBS-like discussion groups, and so on. For link management, it has a Site Explorer, which presents the site in a form similar to the Windows 95 Explorer (see Figure 30.4). FrontPage also includes its own simple Web server, thereby covering just about all sides of the process. Find out more about FrontPage at http://www.microsoft.com/frontpage/.
Figure 30.4. Front Page Explorer.
Also in Chapter 6, I mentioned GNNPress, formerly called NaviPress, which allows you to create and manage individual pages as well as "miniwebs"—collections of pages not unlike Web presentations. GNN also has a hosting service that includes an integrated server environment (called GNNServer) that allows you to save pages and miniwebs directly to the server without needing to FTP in between. GNNServer can also be purchased to for use on your own site. See http://www.gnnhost.com/index.htm for details.
Commercial Web servers often include integrated mechanisms for creating and managing pages and presentations, with a range of advanced capbilities from the simple to to extremely complex. At one end might be O'Reilly's WebSite, which has the WebView tool for getting an overall view of a site and the links between pages (Figure 30.5). At the other end might be Netscape's LiveWire Pro, which allows dynamic page creation and updating through Netscape Gold, an integrated Informix database to store and manage Web content, and site administration tools that you can use on any site on the network using Netscape's browser. Again, that URL for WebSite is http://website.ora.com/, and you can get information about LiveWire from Netscape at
http://home.netscape.com/comprod/products/tools/livewire_datasheet.html.
Figure 30.5. WebSite SiteView.
If your organization uses big databases such as Oracle or Sybase, you can integrate your presentations with that database. Oracle provides a package called Oracle WebServer that includes an HTTP server and lots of tools for generating HTML pages on-the-fly from content contained in the Oracle database. See http://www.oracle.com/products/websystem/webserver/html/ois4.html for more information.
If you use Sybase databases or SGI workstations, SGI WebFORCE is worth a look. It provides everything from the hardware to the Web server to the tools to tie it all together. Check out http://webforce.sgi.com/ for details.
Most organizations have some sort of database in which company information is kept. The "database" can be anything from a simple text file that is added to using a plain editor, to a simple PC-based database such as Microsoft Access or Microsoft Pro, all the way up to heavy-duty professional database systems (Oracle, Informix, Sybase). That database may contain everything from customer lists to company policy to every bit of paperwork that the company produces. The database can be part of a central information system for an organization.
Connecting that database to a Web server using a CGI script or other mechanism is a natural extension of both the Web presentation and to the database information system. Connecting the database to the presentation allows the information in that database to be searched, sorted, and displayed via a Web browser using the same interface that readers are used to. Connecting the Web browser to the database gives your readers access to the information contained in that database from anywhere on the Web.
Connecting a database to the Web is not as difficult as it sounds. Most of the major database manufacturers now have products that connect databases to the Web and often include mechanisms for creating and adding to Web pages stored in those databases as well (you learned about some of those systems in the previous section). Publicly available CGI scripts for making SQL database requests from a Web page are also available (see http://gdbdoc.gdb.org/letovsky/genera/dbgw.html for a good list of them).
Servers for the PC and Macintosh also often provide interfaces for popular database programs on those platforms. If you use a server on Windows 95 or Windows NT, you'll want to look at Cold Fusion, a system that integrates HTML pages and Web servers with database products such as Access, FoxPro, Paradox, Borland dBASE, as well as Oracle, Sybase, and Informix. You can buy Cold Fusion on its own (it's $495), or if you buy WebSite Professional, you get Cold Fusion packaged with it. Find out more about Cold Fusion at http://www.allaire.com/cgi-shl/dbml.exe?template=/allaire/index.dbm, and WebSite professional at http://website.ora.com/.
StarNine (makers of WebStar server for the Mac) has a great list of tools for integrating databases such as FileMaker Pro and FoxPro with the server. It's part of their "Extending WebStar" information at http://www.starnine.com/development/extendingwebstar.htm.
Smaller presentations are, by nature of their smallness, easier to navigate than larger presentations. In smaller presentations, there's only so much to see, and there's less of a chance of getting lost or heading down a long path toward a dead end. For this reason, larger presentations benefit from several navigation aids in addition to the more common links for page-to-page navigation. This section describes some useful aids for getting around larger presentations.
Button bars are rows of text or image links that point to specific places on your server (no, a text-only button bar is not an oxymoron). They're different from ordinary navigation icons in that they don't provide instructions for specific types of movement from the current page (up, back, next), but they provide shortcuts to the most important parts of your site. Think of button bars as a quick-reference card for your overall presentation.
Button bars can go at the top or the bottom of your pages, or both. They can contain text, images, or both. How you design your button bar is up to you and how you want to create your pages. But here are a few hints. (I couldn't let you go on without a few hints, could I?)
Button bars tend to work best when they explain what each item is without taking up a lot of space. Like I said, they're a quick reference, not a full menu that might end up being bigger than the content on the rest of your page. Keep your button bars brief and to the point. Netscape's button bar is a good example of this (see Figure 30.6).
Figure 30.6. Netscape's button bar.
Some sites use button bars made up of icons, the smallest form of button bar. The problem with using plain icons, however, is that it's often difficult to figure out just what the icons are for. For example, given the button bar in Figure 30.7, can you tell what each of the icons are for?
Figure 30.7. A button bar with unlabeled icons.
A single word or phrase helps the usability of this button bar immensely (see Figure 30.8). As part of your usability testing, you might want to test your button bar to see whether people can figure out what the icons mean.
Figure 30.8. A revised button bar.
Text-only button bars (such as the one shown in Figure 30.9) work just fine and have an advantage over icons in that they are fast to load. They might not be as flashy, but they get the point across. And, they work in all browsers and systems.
Figure 30.9. A text button bar.
How about a combination of both? Apple's Web site (http://www.apple.com/) has both a graphical and a text-based button bar, on separate lines (see Figure 30.10).
Figure 30.10. Apple's button bar.
If you use a graphical button bar, consider using individual images instead of a clickable image map. Why? Here are several reasons:
If you have a particularly large presentation or one that changes a lot, such as an online magazine, consider creating a What's New page as a link from your home page (and perhaps a button in your button bar). Your site might be fascinating to readers the first time they explore it, but it will be much less so if your readers have already seen the majority of the site and are just looking for new stuff. In fact, if they have to spend a lot of time searching your entire site for the new information, chances are excellent that your readers aren't going to bother.
A typical What's New page (such as the one in Figure 30.11) contains a list of links to pages that are new in the presentation (or pages that have new information), with a short description of what the page contains, sorted by how new they are (with the newest parts first). This way your readers can quickly scan the new stuff, visit the pages they are interested in, and move on. By placing the newest information first, your readers don't have to wait for the whole page to load or have to scroll to the bottom to get the new information.
Figure 30.11. A What's New page.
How do you create a What's New page? You can do one by hand by writing down information about changes you make to the presentation as you make them. You can also use our whatsnew script, available from http://www.lne.com/Web/Source/mkwhatsnew.txt, a Perl script that searches a tree of directories, finds files that are newer than a certain date, and returns a list of links to those files (as shown in Figure 30.12).
Figure 30.12. The output of whatsnew.
You can then edit the output of whatsnew to include a short description or any other formatting you might want to provide.
The difficulty with larger presentations is that when they become too large, they become difficult to navigate quickly and easily. With smaller presentations, this isn't so much of a problem because the structure isn't that deep. Even with a poor navigation structure, your readers can wander around on your pages and stumble across what they need within a short time. With larger presentations, the bulk of information becomes unwieldy, and finding information becomes more difficult.
The advantage to having all that information on the Web, however, is that you can provide several different views on or ways to navigate that information without having to revise the entire presentation.
For example, suppose you have a presentation that describes all the locations of the Tom's Hot Dog franchises in the United States, with a separate page for each separate location (its address, management team, special features, and so on). How will people find a franchise in their area? Your main structure is a hierarchy, with the presentation organized by region and by state. You could provide a view that mirrors the organization with link menus for the regions, which point to link menus for the states, cities, and eventually individual stores. Figure 30.13 shows how the topmost menu might look.
You could also present the structure in a table of contents form, with lists and sublists for state and city (see Figure 30.14).
Perhaps the structure could be a visual map from which users can select the state they're interested in (see Figure 30.15).
Finally, maybe a simple alphabetical index of locations could make it easier to find one specific franchise (see Figure 30.16).
Figure 30.14. A table of contents.
Figure 30.16. An alphabetical index.
Each view provides a different way to get into the information you're presenting. None of them change the way the pages are laid out or the way you've put them on your server. They're just different ways in which your readers can access your information, based on what they're looking for and how they want to find it. Giving your readers choices in this respect only improves the accessibility of the information on your site.
For really large presentations in which information is widely distributed among the pages, sometimes the best way to let people find what they want is to let them tell you what they want. Search engines are used to add searching capabilities to your pages so that your users can enter the keywords of things they're looking for and get a list of pages that contain those keywords (and, hopefully, links to those pages). For example, Figure 30.17 shows the search form from IBM's Web site (http://www.ibm.com), and Figure 30.18 shows the results.
Figure 30.18. The results of the search.
Why are they called search engines? The idea is that you can use several different types of searching methods or programs for the content of your server. If the search engine you're using doesn't work very well, you can replace it with another one. You aren't restricted to one single searching method or program, as you are with most desktop software.
If you're adept at programming and CGI, you can write your own search engine to search the contents of your server and the pages on it and to return a list of links to those pages. If you have an enormous amount of information, you might want to check out a document indexing and retrieval system such as freeWAIS-sf (http://ls6-www.informatik.uni-dortmund.de/freeWAIS-sf/README-sf), Harvest (http://harvest.cs.colorado.edu/), or Glimpse (http://glimpse.cs.arizona.edu:1994/). Also, there are commercial search engines you can buy (such as WebSearcher from Verity, which has enormous capabilities for indexing and searching) that will index your server and provide a front end to the information you have there. Your Web server may even contain its own search engine with which you can index your document. (Figure 30.19 shows the indexing window for WebSite's integrated search engine.) Which search engine you use isn't as important as making sure that it allows your readers to get what they want without waiting too long for that information. Once again, making sure you satisfy your audience and their goals for your pages is more important than having the most sophisticated technology.
Figure 30.19. WebSite's Site Indexer.
The task of providing a Web site for an organization, or for creating a presentation that will be updated and added to by others, doesn't just involve the work that you do on that site or presentation. It also involves making sure that your work can be added to and maintained by others after you've finished it, and that new pages won't branch off in different stylistic directions based on the whim of the author. For those reasons, it's an excellent idea to establish standards for the style and design of the pages on your site, write them down, and make them available for your authors.
Remember that the pages you develop for your site are an example to the people who will come after you and add their presentations to yours. Consistency within your pages, therefore, is doubly important, not just for your readers but also for the writers and designers working with you. Providing consistency in your own design helps others follow along without your having to supervise them at every step. Here are some examples of consistent design:
When you have a design in place for your pages, the best way you can help others follow your lead is to provide templates, which are a standard set of pages that people can copy and use for the basis of their own pages. Make a set of generic pages for them to begin with, or a set of templates in the tools they're using to create Web pages. (For example, if they're using MS Word and Internet Assistant, provide a Word file with the appropriate style sheet for them to use.)
Separate from the template itself, you should have instructions on how to use the template. You might want to include these instructions as part of your style guide, as described in the next section.
Writing groups within organizations often use the concept of a style guide to keep track of the standards in their documents so that others can pick up those standards quickly and easily. The style guide can contain everything from editorial style ("avoid the passive voice") to the fonts and styles used for particular portions of a document ("first level headings are in 18-point Helvetica," or "use boldface to define terms for the first time").
A style guide for Web design in your organization can help people create pages that conform to your design guidelines. If you have people editing pages, it also helps them know what to flag as wrong or needing work. Some ideas you might consider putting into your style guide for the Web are as follows:
The following sites might prove useful to you in developing your own Web style guides:
Some organizations, such as Apple and Microsoft, publish style guides for their publications, which can give you some hints for what to include in your own. Also, a more general writing style book (such as the The Chicago Manual of Style), or a book on online design (I like William Horton's Designing and Writing Online Documentation), will provide further material for you to use in your own style guide.
Of course, your style guide should be written and available as a Web presentation, at least within your organization. Consider publishing it on the Web at large, as well, because your experiences can help others in your position who are trying to come up with similar guidelines.
The very concept of controlling the content of pages that appear on a site is often considered utterly abhorrent to many people who believe that Web publishing is free and open, and that anyone should be able to publish anything at any time. The fact is that if your organization provides the network and the system on which Web pages are served, your organization has the right to have a say in the content it serves.
If your organization does want to have standards for Web page content, it's an excellent idea to have a set of content guidelines written down so that people writing pages on your site know ahead of time what they can and can't do (for example, publish proprietary information or offensive material). Work with your organization to establish these guidelines, and include them in your style guide or in your instructions for setting up Web pages.
You might also want to have different guidelines for different parts of your site. For example, a presentation of corporate information on your site might have very strict guidelines, but things might be much more lenient in a collection of personal pages. It's up to you and your organization to set guidelines for your site and to enforce those guidelines, but do make sure those guidelines are available to your Web designers before they begin to write.
Even though small and large Web presentations have similar features and can both be distributed in the same way on a Web server, the challenges of planning, managing, and navigating a larger presentation are often quite different from those of a smaller one. In this chapter, I described some of the difficulties and provided some ideas on how to manage larger presentations, particularly those for organizations. Here's a recap of the ideas:
Q: I have a lot of text-based content such as press releases. Rather than converting the files to HTML, I took your advice and renamed them as .txt files. The result works, but it's not very pretty, and there are no links from the files, which makes them a dead end in terms of hypertext. Is there some compromise I can do between full HTML and plain text?
A: There are simple text-to-HTML converters that will do much of the work of converting simple text to HTML for you. Or, simply putting a <PRE> ...</PRE> tag before and after the text accomplishes a similar result. If your files are in a consistent format, you can add highlights (such as boldfacing the headline) and a link at the bottom of the file back to your index. This can all be automated with reasonably simple scripts, particularly if your text files all have a very similar format.
