|
|
|
Scott Meyers, Ph. D.
Software Development Consultant
smeyers@aristeia.com
Jason Jones
Sr. Electronic Production Specialist
Pearson PTR
jonesj@awl.com
This article describes the design and development of a portable HTML/WWW based reading environment for electronic books and other large documents. We discuss our efforts to create an interface that gives users significant control over the browsing experience and our attempts to structure documents for improved navigation, search performance, integration with other web-based material and collaboration.
Our challenge in designing the Effective C++ CD2 was to turn the text of two highly interrelated paper publications into an effective online resource for student and professional programmers whose needs might include individual, or team based, reference and training. The initial specification called for:
Publishing in HTML was the natural choice to deliver on several of these goals; HTML browsers are available on most operating systems, the files can be stored on a central server or client machine and they can be easily integrated with other stores of HTML, PDF or multi-media documents (SMIL, Flash, Shockwave, etc.). We knew from the start that we wanted to publish in HTML, we also knew from experience that most books published in HTML offer the user a poor reading environment.
Proprietary electronic book systems, such as DynaText or KnowledgeStation 3, are able to take complete advantage of their hypertext material (usually SGML or even HTML), allowing the user to do document wide searching, make annotations, create two-way bookmarks to any point in the text, highlight regions and so on. With a proprietary hypertext browser the reader is presented with a rich user interface and the document becomes an application that mimics and extends the natural action of reading.
HTML books by comparison are typically sparse in terms of capabilities and user interface niceties. They are most often published for download or packaged on a CD-ROM in the back of a print book, as straight pages of HTML text with the occasional Table of Contents for navigation. There tend to be four reasons for this:
The first reason is becoming less important as more advanced browsers have become commonplace and most users are capable of viewing at least a somewhat enhanced HTML standard. We could confidently say that our core audience of student and professional programmers would be using a 4.0+ capable browser, enabling us to support a wider standard and some properties like CSS and CSSP. The second and third reasons are certainly valid for publishers who aren't planning to recognize any revenue and do not have the resources to invest in adapting their print materials, but with a modest budget and the desire to produce a valuable electronic resource, vanilla HTML just doesn't cut it.
The fourth reason presents a much more significant hurdle. The client/server model is the standard paradigm for web development, with the server responsible for the storage of client generated data, such as users' preferences, and for the processing of client input, such as document wide searching on a query string. Without a server-side element, it is very difficult to duplicate any of the functionality which makes proprietary electronic book systems so attractive. Fortunately, as browsers have advanced, so too have their client-side capabilities, making it possible for much of the load to be shifted to the client and for a truly portable web application to be written.
With this in mind, we set out to design an interface and an associated document structure which would function to some extent like a proprietary system, but which could be easily extended and integrated with other web-based materials. Our primary goal was to create an HTML-based environment that would be significantly adaptable to a user's browsing preferences while providing the user with a multitude of ways to access and reference the textual material.
In brief, the design aspects which we have focused on (to be explored in more detail throughout the paper) are:
User feedback is summarized in two sections, one covering our discussion of adaptability and the other covering navigation. At the end of this article, we also present some ideas for future research.
To experiment with any of the topics discussed in this article, visit the on-line demo of the Effective C++ CD at http://meyerscd.awl.com.
When we began designing the Effective C++ CD, we focused on how to best deliver the material to a wide range of users on varying hardware platforms, with different uses for the content and different browsing preferences. We determined that to meet the needs of a wide range of users, the interface should be pliable and should offer the user some measure of control over its appearance and function. Our primary concerns were user control over the size of images, user control over the size of navigation content and user control of the file size being browsed. We separated each of these components so that users can mix and match to suit their preferences.
Each of the three adaptive elements discussed below operates from a persistent control panel located on the left-hand side, of the browser window in the navigation frame. The user can change options at will and determine their current settings from the panel's rollover states. Here is an example of three control panels with different settings.
 |
 |
 |
To facilitate multiple users and the persistence of an individual users choices, any selection of a panel element will cause a cookie to be stored on the user's machine specifying the selected settings.
While web browsers offer a great degree of control over the textual display of a document, most offer no control whatsoever over the presentation of bitmapped graphics. This has resulted in many designers choosing one of the following options:
The first option is obviously inadequate as it works to the detriment of any user who favors a different resolution. Graphics which display well at 640x480 will be indecipherable at 1280x1024 and vice versa.
The second option is much better, but still suffers because the choice of what looks good at a certain resolution is left to the designer. From feedback we received on an earlier project, The Design Patterns CD,[1] which limits its users to a choice between lowres (640x480) and hires (800x600+) it was evident that this solution isn't good enough. Several users remarked that the graphics were too small, or too large, or too fuzzy, independent of the resolution they were at, demonstrating that users on wildly varying hardware are bound to have differing reactions.
Our goal for the Effective C++ CD was for it to look good on monitors from 12 to 21 inches in size at resolutions from 800x600 to 1600x1200 pixels. We also wanted the decision of what "looks good" to belong to the user. To satisfy this, each diagram on the CD comes in five different sizes, and users can dynamically change their preferred size at any time. Here is an example of three of the five sizes (smallest, medium, largest) available for the image from page 172 of Effective C++ (including a bit of surrounding text):
 |
 |
 |
When a user requests a different image size, the change occurs immediately; there is no need to reload the document. Thus, it's practical for users to change image sizes depending on the specifics of the image, e.g., how much detail is present in the image itself.
As they do with images, web site designers often adhere to the one-size-fits-all philosophy for navigation areas. In fact, web site navigation areas frequently are images. Operationally, however, there is an important difference. The content of a navigation area is often relatively static. As a result, once the user knows where the buttons on a navigation bar are located, she might well want to reduce the size of the navigation area to make more browser space available for content. Hence, it's reasonable to want to reduce the size of the navigation area even if she would prefer to view images within documents at a relatively large size.
Again, we chose to offer five different sizes of navigation area. Users can adjust the size of that area independently of the size of images displayed within documents. For example, here are screen shots from the Introduction to More Effective C++, each showing a different size navigation area (smallest, medium, largest). In each case, the image size is set to its medium setting.
 |
 |
 |
Of course, this is not the only way to give users control over the relative screen space devoted to navigational aids versus document content. Microsoft's HTML Help uses a two-pane design for the client area that gives users control over the location of the split between the navigation and content areas.
 |
This is a nice design, but though it allows users to reduce the area allotted for navigational aids, it affords no way for users to scale down the space needed for the information in the navigation area. Instead, the information is simply clipped on the right and users must grapple with cumbersome horizontal scroll controls.
|
The design used on the Effective C++ CD allows users to reduce the size of the navigation area while still displaying 100% of the information within it.
Another approach to this problem is to make the navigation area a window in its own right instead of a pane in the content window. The navigation window can then be minimized independent of the content window, thus maximizing the display area for a document's content while simultaneously making a full-size navigation area available via single mouse operation. The web site for Clarkson University (http://www.clarkson.edu) provides this kind of "remote control" capability.
|
Internet Explorer provides a similar capability by giving users the ability to toggle the visibility of the navigation pane. Neither the Clarkson design nor the IE design gives users control over the horizontal space required to display the information in the navigation area. (The navigation area in the Clarkson design determines line breaks dynamically, but the size of the text is not adjusted if the window is made narrower. If graphics were used in the Clarkson design, they would presumably be fixed in size.)
An ideal design would probably offer users all three capabilities: control over the space required to display the information (as on the Effective C++ CD), control over the space available to display the information (as in HTML Help), and control over the visibility of the navigation area itself (as in Internet Explorer).
An important strength of electronic publication is its support for search capabilities
not possible with paper books. Designers of web sites (including books on CD)
generally focus on search engines external to the browser itself because browser
searches work on only the current document.[2] However,
browser search (Find) functions generally have two important strengths.
vector<int>", yet the underlying
HTML contains "vector<int>"; they correctly
find a match. The big drawback to browser based searches is that they work only on the current document. It's generally not practical to publish all of the information on a web site or CD in a single file, so there's a tradeoff to be made. Bigger files support more complete browser-based searches, but the files take longer to load and demand more memory. Smaller files load faster and use less memory, but they yield more limited browser searches. With the Effective C++ CD, our solution was to provide three copies of each book broken down into different size files and allow users to choose which file size they prefer. This affects not only the search capability of the browser, but users can also make their decisions based on preferred document navigation size, document printing, and display speed.
Dynamically sizable images and navigation areas were part of our prototype releases at an early stage and feedback from reviewers has been consistently positive. Users appreciate being able to customize their browsing environment to suit their particular hardware, and several individuals who reviewed prototypes on a wide range of screens, from workstation to laptop, found that the interface's adaptability served them well.
Multiple file-sizes were also in early prototypes, but were limited to the Item and Chapter chunks (i.e. small and medium), each of which functioned very well with typical computer hardware. With the release of later prototypes, we found that reviewers were having trouble with large documents however. The size of the book-length documents, together with graphics and dynamic functions, requires fast hardware and a significant amount of memory, making them unsuitable for most users.
It was our intention that the Effective C++ CD serve as a both a resource for the individual and for users in collaborative environments, such as corporations or universities, where the CD might function as part of a larger document store or as on-line training material. HTML publications are easily adaptable to multiple environments and offer users the ability to interact with and augment a document by searching, bookmarking and linking into and out of the document collection. To serve the needs of collaborative users though, the document interface must present a consistent navigational model. Taking advantage of dynamic controls, we developed a scheme for paragraph-level addressing that remains consistent from document links to search engine hits, and makes it easy for users to find and reference material throughout the CD in a consistent manner.
We determined to use frames for the Effective C++ CD because we wanted to insure that the navigation and preferences areas remain a persistent presence in the browser window no matter how far through the document the user scrolls, so that the user can make the most of the dynamic features accessible through these menus, such as image sizing and individual page targeting, without having to lose the document place by scrolling back.
Much has been written about the negative aspects of using frames for HTML display [3], but with a little effort, frames can be made to function quite well for browsing large, interlinked documents such as books.[4] Our primary concerns for the project were with the following frameset limitations:
Limitations 1-3 were encountered by reviewers of the Design Patterns CD [1] and comprised about 90% of their complaints regarding framesets, fortunately we already had solutions for these. Limitation 4 was first discovered in early prototypes of the CD. A user would bookmark an anchor in a frame and following that bookmark would result in the document page loading without the navigation area. Here is a diagram of the scheme we came up with to address these limitations.
|
We decided to generate one frameset per displayed document, so that the frameset
functions only as a top-level means of associating a document with a navigation
bar. For every document X.HTM, there is an associated frameset
X_FR.HTM which is responsible for loading X.HTM into
the content frame. The browser title bar will be the title of X_FR.HTM,
thus every document can be uniquely identified and bookmarked at the frameset
level. Use of the back and forward buttons under these circumstances is the
same as if the browser were displaying an unframed document. While this does
mean that the navigation bar has to load and unload with every document change
as well (because it loads as part of the new frameset), the performance hit
is small since all of the navigation area graphics are cached.
In conjunction with this setup, we used javascript to filter a URL's anchor
through the frameset and to the loaded document. Every link on the Effective
C++ CD which targets a point in another document, actually links to the
document's paired frameset which subsequently handles the targeting. For instance,
links of the form X.HTM#anchor_name are coded as X_FR.HTM#anchor_name
and we use javascript to pass the anchor along to X.HTM as it loads.
Another javascript function insures that a framed document never loads itself
into the top window, but instead passes the targeted anchor to it's paired frameset,
via a redirection page, which then reloads the files appropriately. If document
X.HTM sees itself to be the top level document, it will call X_DIR.HTM
and reload. Paragraph-level bookmarks all X_DIR.HTM
directly.5
Setting a bookmark using the browser simply records the most recently loaded URL. That URL certainly corresponds to the file being viewed, but it need not have a particularly good relationship to a user's current position within that file. For example, if the user has scrolled down in the file or has used the browser's search function to move forward, her current position may be arbitrarily distant from the most recently loaded URL. The farther she is from the most recently loaded URL, however, the less useful setting a bookmark is, because returning to that bookmark won't put her very close to the information in which she is interested.
One solution to this problem is the use of small HTML files. That way, bookmarking the file itself always puts a user reasonably close to where she really wants to be. As noted above though, small files cripple browser-based searches and for books such as Effective C++ and More Effective C++, small files simply can't be made to work. Some of the discussions in the books span many pages on a single topic; splitting them into multiple HTML files makes no sense. Furthermore, it's often useful to bookmark material in the middle of such a discussion.
This is a problem that proprietary browsing systems such as DynaText address very well. As a stand-alone application, DynaText can allow users to create bookmarks (even two-way bookmarks) at any point in the text, and can preserve these across browsing sessions. We wanted essentially this same facility, but from within a portable, serverless HTML environment.
Our solution was to associate each paragraph on the CD with a unique anchor, and to end each paragraph on the CD with a symbol that is a link to that anchor. We call this symbol the paragraph's dingbat. When the cursor is moved over a dingbat, the dingbat expands into a textual description of the paragraph. This is typically an abbreviated version of the document's title, plus the number of the paragraph within the document. For instance, "Try that using scanf and printf! " becomes "Try that using scanf and printf! Item E2, P5" denoting paragraph 5 of Effective C++ Item 2.
When the dingbat is expanded, browser commands can be used to bookmark it; the textual description then becomes the title of the bookmark. Using Netscape Navigator under Windows, for example, users just right-click the expanded dingbat, then select "Add Bookmark" from the resulting pop-up menu.6
Using similar browser commands, users can copy the URL for a dingbat to the clipboard. This is important, because it means it's easy to create links from other HTML documents into the Effective C++ CD. That is, not only do paragraph-specific URLs (and the dingbats through which users interact with them) facilitate bookmarking specific information for particular users, they also facilitate the integration of the CD with other collections of HTML documents. For example, users could link to specific parts of the CD from HTML documents they have that describe their C++ coding standards. Another benefit of paragraph-specific bookmarks is that they provide a paragraph level referencing model, making it easy for a user to identify the location of material she wants to pass on to another user who also has the CD. For instance, a user could pass along the actual URL for the material, or simply say something like "take a look at paragraph 22 of the Intro."
A common problem with search applications independent of the browser's native search function is that their targeting can be imprecise. The search may take the user only to the document, or to a large section of the document (started by a subhead for instance) which contains the user's search match. To find the actual match in that section, the user then has to perform a browser search.
For document-wide searching we were committed to using a Java applet designed for a prior project, The Design Patterns CD [1], which was capable of both full-text and indexed searching, with regular expression matches possible in full text mode. The applet was already geared towards targeting small blocks of HTML through the use of auto-generated anchors in the target document which form sections for the applet. Here is what the applet's interface originally looked like.
|
The design of the applet wasn't too bad to begin with, but from extensive use with the Design Patterns CD and customer feedback, it became apparent that the applet needed an overhaul.
The first thing we did was to eliminate full text and regular expression searching. Due to limitations with the applet, links to hits resulting from full text searches resulted in jumps to the top of a document only. Regular expressions were tied to full text searches and would be found across entire documents, not smaller sections, but because of the static file-system, the matches could not be highlighted.
The second thing we did was to optimize the applet with an HTML tag-stripper/translator so that specific characters would be found correctly, and institute simple wildcard capabilities.
Reviewers of the initial prototypes still found the applet lacking though, noting that the list of hits returned gave no indication of place nor content, forcing the user to try every link until they found something close to what they were actually looking for. Fortunately, a number of the reviewers had suggestions, and one in particular, Mark Rodgers, delivered what amounted to the specification we eventually adopted - a two paned applet, the top showing search results, the bottom showing context information for that result with the result highlighted, as well as a counter indicating which result was currently selected. Here is the revised interface.
|
To provide the search results and context, we decided to take advantage of the paragraph level anchors in every HTML file on the CD. The search applet links matches to the individual paragraphs where they were found, displays the paragraph text in the applet's context and targets the paragraph directly in the browser window.
The search applet is sensitive to the users' preferences as well, and will only search on files from the currently selected file size. An added benefit of this scheme is that it enhances the possibilities for user collaboration because the the search and document share the same referencing model (by paragraph). Users can easily pass the location of a search result, or the number of the search hit, on to other users by passing the counter value, or the paragraph target.
Additionally, the revised applet provides an additional "quick reference" reading model for users. A user can search the books text and view a paragraph of context without having to load a page into the browser window, in fact, the user can close the document altogether and do quick lookups/browsing with the search applet only.
URLs on the Internet are in a constant state of flux. This is a serious problem for CD designers, because URLs on a CD are, by definition, fixed. This is especially true for documents such as books. If the life of a book on CD is going to match the life of a paper book, at some point the CD's links to the Internet will become incorrect.
Our solution was to insulate the URLs on the CD from the actual URLs holding the information the CD links to, by assigning the CD URLs a key and using an on-line translation table to direct the user to the appropriate location. As long as the translation table is maintained, the links on the CD will not go out of date. There is a possible performance penalty depending on the state of the server hosting the translation script, but in practice this penalty has rarely been noticeable.
Feedback concerning our navigation enhancements has been very positive, if a little uneven.
We haven't received any complaints concerning our use of frames, which could mean that the frameset enhancements are working well and have resolved most of the problems users tend to have with frames, or could simply mean that frames based browsing isn't the contentious issue it once was.
The dynamic function of paragraph-specific bookmarking was difficult for our prototype reviewers to adjust to at first, but user's don't seem to be experiencing many problems. On the contrary, mail received from users has demonstrated the utility of this function in collaborative environments. Nearly every correction, comment, or user request which comes to us via e-mail references the text using it's paragraph specific information. User's have keyed on to this as an effective and natural means of precisely communicating a textual location. Beyond this functionality though, it is apparent that the " " character disrupts the flow of text for some people. We have received a few requests to make the markers invisible, or to provide a mechanism by which they could be turned off.
The response to our revised search applet has been entirely positive. Prototype reviewers immediately recognized the increased utility that paragraph referencing and contextual display represent and users seem to be finding the applet more than adequate for locating information.
The Effective C++ CD has only been out for a short time and user feedback is still coming in, but the comments we've received so far have been very positive. Users appreciate being given more control over their browsing environment and are willing to upgrade their browser platform if necessary to take advantage of customization features.
We have received a cautionary note from one user however, concerning accessibility. The CD makes use of dynamic HTML, style sheets and javascript, and unfortunately it does not degrade gracefully for screen readers (programs which voice HTML text) and other devices designed to help the visually impaired. Since the release of the CD, we have been developing a mechanism to address this difficulty by degrading to a functional javascript version for javascript 1.1 browsers such as Netscape Navigator 3.0, and both a non-javascript framed version, recommended for browsers such as Opera, and a pure HTML 3.2 version as well for parsing by screen readers. The dynamic effects are absent in both of these latter versions though.
In addition to making the interface more accessible, we are working to broaden the interface's capabilities by incorporating signed scripts to allow client-side generation of the following:
State information beyond that available to cookies
Our goal is to eventually provide an interface as rich what is available to proprietary browsers, but that will accommodate any HTML source from a standard browser.
While HTML publication on CD does suffer from the lack of a server/database pairing which is typically found in dynamic web applications, client-side scripting in conjunction with a user centered interface can deliver a compelling experience that offers users a level of control over their browsing environment that they don't normally receive.
User interface elements like paragraph-specific bookmarking and paragraph-granularity searching increase the functionality of HTML documents by allowing users to better interact with them and with other users of the same material. At the same time, elements such as independent diagram and navigation area sizing allow users to customize their environment to their liking, and indirect routing of Internet URL's from the CD insures that CD links will not go quickly out of date.
Nielsen, Jacob (1996) Why Frames Suck (Most of the Time). Alertbox, http://www.useit.com/alertbox/9612.html
Ashworth, Catherine A. Ph.D. and Hamilton, David B. Ph.D. (1997) A Case for Frames. Conference Proceedings - 3rd Conference on Human Factors & the Web
Many people were involved in the design and development of the Effective C++ CD and have thus had a direct impact on this paper.
We would like to thank Marty Rabinowitz, John Wait, and Sarah Weaver of Pearson PTR for their efforts in the design and production of the CD, as well as Razzaq Lodhia and Jason Dawson of Videomation Interactive, who carried out the bulk of the CD's implementation, and Chris Peterson of Silverbeach Software who was responsible for the search applet's development.
We are also indebted to the following individuals who took the time to review prototypes of the CD: Andrei Alexandrescu, Steve Clamage, Chris Cleeland, David Drysdale, Carolyn Duby, Bruce Eckel, David Goh, Michael Hoffman, Tim Johnson, Brian Kernighan, Martin Klaus, Barbara Moo, Rob Murray, Vivian Neou, John Peterson, Rajashree Purohit, Mark Rodgers, Bobby Schmidt, Ducky Sherwood, Martin Shoemaker, Herb Sutter and John Vlissides. Their detailed critiques and suggestions helped us make the CD both more useful and more usable.
Some of the material in this paper will appear in an article entitled "Browsing Innovations in the Effective C++ CD", to be published in a future issue of Microsoft Interactive Developer.
A few browsers, such as Opera Software's Opera browser, do support the scaling of web pages, including images, natively, but this support is uncommon.
The document cannot reload X_FR.HTM
directly because of bugs with the frameset implementation of Netscape Navigator.
To properly bookmark the page on MSIE, you need to be using version 5.0 and you need to drag the dingbat text link to your favorites menu. Since version 3.0, MSIE has been unable to create local bookmarks if those bookmarks contain anchors. 5.0 solves this problem, but in a not altogether satisfactory way.
| "Document Design for Effective Electronic Publication" |
|---|
Thanks to our conference sponsors:
|
Thanks to our conference event sponsor:
|
