Chapter 7. Docbase Navigation

Docbases are rich with implied interconnectedness. For example, a report about Internet Explorer in the ProductAnalysis docbase might prompt a reader to explore the docbase along several dimensions:

  • More reports about Internet Explorer

  • The previous report about Internet Explorer

  • More reports by the author of this report

  • The next report by the author of this report

  • More reports about Microsoft products

  • More reports due around the same time as this one

In the relational database discipline, we satisfy the “More reports about...” kind of request with an SQL query, such as:

select * from docbase where product = 'Internet Explorer'

To handle a “Next report by author...” kind of request, we fetch and then navigate within a result set. These mechanisms enable users to explore the interconnectedness of a data set. But they don’t reveal it explicitly. That’s our goal in this chapter.

I’ve said that a docbase marries two disciplines: data management and publishing. From a data-management perspective, it might be enough to just bolt a web interface onto standard database query mechanisms. But a docbase isn’t just a database; it’s a hypertextual publication. The interface to that publication is distributed across every page of the docbase. A docbase works best when every piece of its distributed interface answers two basic questions: “Where am I?” and “Where can I go from here?”

The answers to these questions can take many shapes and styles. In the BYTE Magazine docbase described in Chapter 5, one answer to “Where am I?” was “In the August 1998 issue of BYTE.” Another was “At the end of the series of elements belonging to the Web Project section.”

There were many answers to “Where can I go from here?”

  • The previous element

  • The parent element

  • The section-level table of contents

  • The issue-level table of contents

  • More Web Project articles

  • More distributed computing articles

In the BYTE Magazine docbase, the “More like this” links were, in effect, precomputed queries, as were the Next and Prev links. As I explained in Chapter 5, the system relied on dynamic generation of statically served pages. The Docbase::Indexer module I’ll demonstrate in this chapter takes a similar approach. It augments docbase records with two complementary sets of navigational controls. What I’ll call tabbed indexes generalize the notion of “More like this” for any of the header fields of a docbase. And sequential indexes implement “Next” and “Previous” for header fields. Both sets of controls explicitly connect each record to related records, along multiple dimensions.

Although you can achieve all these effects by dynamically generating statically served pages, we’ll find as we go along that a little server-side assistance can really help matters. I’ll show two ways to create these navigational controls, one dynamic and one static. The dynamic method, which entails less indexing overhead and not much runtime overhead, is my preferred solution. However, it requires an HTTP server, and sometimes one isn’t available. The static method, which requires no HTTP server but incurs a lot of indexing and storage overhead, can be useful in special situations. For example, you might want to deliver a docbase of service bulletins to field personnel who use CD-ROM-equipped laptops. In that case, it’s handy to be able to deploy a docbase that runs straight off the CD-ROM, relying on only the file:// protocol that browsers use to interact with file-based data stores.

It’s helpful to think in terms of a continuum. At one end are files containing HTML pages (or XML pages) that browsers can render directly. At the other end are server-side processes that generate these pages. An application can live at any point along that continuum. Its distance from the endpoints isn’t a measure of rightness or wrongness but only of appropriateness. If your users need to run a docbase straight off a CD-ROM, and you don’t want to configure their laptops with local HTTP servers, then a static docbase is an appropriate solution. Alternatively, as we’ll see in Chapter 15, you may conclude that you want to equip your users with local HTTP service, in which case a dynamic docbase can be an appropriate solution. A groupware developer who can do things more than one way will be best prepared to come up with the right solution to any given problem.

Introducing the Docbase Navigational Controls

The Docbase system implements both tabbed-index and sequential controls. The ProductAnalysis record shown in Figure 7.1 includes a top-of-page toolbar that presents these controls.

The Docbase navigational controls

Figure 7-1. The Docbase navigational controls

The toolbar in Figure 7.1 comprises three elements. Let’s briefly consider what each of them does.

Sequential Controls

When you click the arrows, you move forward and backward in the data set. The dropdown list between the arrows announces the current index, which defines what it means to go forward and backward. The same dropdown list enables you to switch to another index. In Figure 7.1, for example, the current index is company. As the <alt> tag would announce if your cursor drifted over the right arrow, clicking there means “Next record by company.” The resulting page, in this case, would be a report about another Netscape product, Messaging Server.

If you switch indexes, the right arrow means something different. For example, Figure 7.2 shows the same record but with the analyst index in effect.

Alternate index in effect

Figure 7-2. Alternate index in effect

In Figure 7.2, the right arrow’s <alt> tag would pop up the message “Next record by analyst.” Clicking the arrow would produce a report by Ben Smith about’s Post.Office.

Sequential indexes enable users to explore local context. When you’re browsing in a library, it’s often handy to scan the books surrounding the one you’ve found on a shelf. The same principle applies here. The sequential controls make possible the serendipitous discovery of records that are “near” the current record, relative to each of the indexes.


The counters announce your position in the current index and the number of records in the docbase. When you switch indexes, the position counter adjusts itself accordingly. The Calendar Server report, for example, is tenth in the company index, but second in the analyst index.

Why bother with counters? They’re probably not essential. But when you’re exploring a shelf, it’s nice to know how long the shelf is and where your current position is relative to the beginning and the end of the shelf.

Tabbed-Index Controls

The sequential controls implement a localized version of the “More like this” idea. They lead to similar records but operate in a very narrow scope. The tabbed-index controls expand the scope of “More like this.” In Figure 7.1, the tabbed-index selector is ready to select the option company tabs. Figure 7.3 shows the outcome of that selection.

A tabbed-index page

Figure 7-3. A tabbed-index page

The page shown in Figure 7.3 lists reports about products from companies whose names begin with N —in this case, Netscape and Novell. See how the N tab is emphasized? The transition from Figure 7.1 to Figure 7.3 is context-preserving. For each tabbed index that a record links to, the Docbase system knows which tab on the link’s destination page corresponds to the record displayed on the link’s source page.

This notion of context preservation is a crucial aspect of web design. We’ll see later on how Docbase::Navigate achieves this effect. For now, just consider the alternative. It would be easier to connect each docbase record to the tabbed indexes in the same standard way—for example, by wiring the company choice on every tabbed-index selector to the index page for the first (e.g., the A) tab. What’s wrong with that approach? Can’t a user who lands on the A page just click once to get to the N page? Yes. Delivering the N page without loss of context is a small detail, one that many web designs overlook. But those small details add up. You have to work harder to make a web navigation system do the right thing, and once you start to think in these terms, you’ll uncover more and more right things. Take care of these details. People may not notice, but that’s OK. The goal is to make docbases transparently useful.

The tabbed-index pages built by Docbase::Indexer maintain two levels of context, using a pair of tabbed controls. In Figure 7.3, one indicates that we are looking at N companies and leads to similar pages for products from companies whose names begin with A, B, and so on. Why not the whole alphabet? As we’ll see later, the data set is sparse. There aren’t yet enough records to fully populate this tabbed index, so Docbase::Indexer includes only those tabs for which records exist. This is another one of those small details that many web designs overlook.

The other tabbed index tells us we’re looking at a company-ordered list of reports. And it leads to similar pages that list reports other ways. For example, clicking the analyst link in Figure 7.3 leads to the page shown in Figure 7.4.

An alternate tabbed-index page

Figure 7-4. An alternate tabbed-index page

The first tab row looks as it did in Figure 7.3, though adjusted to indicate that analyst is the current index. But the second tab row takes a different form. Here the tabs are the full names of the analysts who file reports to this docbase. Why? Context again. When an index contains a small set of values, there’s room on the screen to show more of each of them. As we discussed in Part I, each level in a layered information system should say as much as it comfortably can about the next level, so users know as much as possible about what that next click will yield.

This chapter will show, in great detail, how to create these navigational controls from a collection of docbase records. We’ll see a lot of Perl code and examine some fairly complex Perl data structures. But before we dive in, let’s take a moment to reflect some more on why these controls are useful, why it might make sense to create them using the Perl modules we’ll build in this chapter, and what all this can mean to a groupware developer trying to manage semistructured information.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.