Home | Proceedings


Document Design for Effective Electronic Publication1

Scott Meyers, Ph. D.
Software Development Consultant
smeyers@aristeia.com

Jason Jones
Sr. Electronic Production Specialist
Pearson PTR
jonesj@awl.com

Abstract

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.

Introduction

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:

  1. In an effort to maximize their documents' utility, publishers target a basic HTML standard (2.0 - 3.2) that will be browseable by the widest range of users.
  2. HTML documents are derived from text originally produced for other purposes (e.g., print publication), and little work is invested in adapting them for use in an electronic environment.
  3. Little or no income is realized from the HTML documents themselves. They are generally either free or included with other products at no additional cost.
  4. The distributed documents are serverless entities being browsed from the user's hard drive or CD. They have no database backing them up and no way to write user data to the file-system, thus they can't support many of the functions that proprietary systems can.

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:

Adaptability
  • Image sizes. Web browsers do not generally give users control over the size of images.4 We allow users to dynamically change image sizes to suit their monitor size, graphics resolution, and personal preferences.
  • Navigation area sizes. As with image sizes, we allow users to dynamically change the amount of space taken up by the navigation area to suit their preferences.
  • File sizes. Taking advantage of the CD's storage capacity, multiple copies of each book are supplied (each broken down into different file sizes), and users can dynamically choose the size they prefer.
Navigation
  • Frameset enhancements. Each frameset is generated through javascript to allow for HTML anchor filtering and document title updating to insure correct bookmarking of frame positions.
  • Paragraph-specific bookmarking. Typically, frames based web sites can only be bookmarked at the top frameset level. To overcome this limitation, we introduced paragraph markers that assign each paragraph a unique URL, allowing the paragraph position to be bookmarked or easily linked to from other HTML documents created by users.
  • Searching. Most HTML search engines do a poor job of identifying where in a document a particular phrase occurs. To enhance the users' search capabilities, the CD's applet identifies each paragraph on the CD that satisfies a query.
  • Link validity. Internet URLs are inherently unstable, but CDs are read-only, hence not updatable. Every link to the Internet from the CD is directed through an on-line table of URLs which can be updated as the need arises.

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.

Adaptability

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.

Figure 1

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.

Graphic sizes

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:

  1. Targeting a single display resolution such as 640x480 only.
  2. Targeting multiple independent resolutions such as 640x480, 800x600 and 1024x768, and querying the client or user on which to display.

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):

Figure 2

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.

Navigation area sizes

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.

Figure 3

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.

Figure 4

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.

Figure 5

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.

 
Figure 6

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).

File sizes

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.

  1. Browsers already have to parse HTML, so they don't get confused when a user searches for "vector<int>", yet the underlying HTML contains "vector&lt;int&gt;"; they correctly find a match.
  2. Browsers are uniquely capable of highlighting the text they find, something no external search engine can do. (Some search engines (e.g., Deja News) appear to be able to highlight matched text, but they actually generate a new page as a result of each search, then they display that page. This isn't practical for a book on CD, because the CD has no web server, and at any rate, it doesn't make sense to generate a new copy of an entire book simply to highlight some search hits.)

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.

User Response

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.

Navigation

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.

Frameset Enhancements

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:

  1. Browsers do not update the title bar when new documents are loaded into the frame.
  2. Use of the browser's forward and back buttons, in conjunction with frames, can lead to incorrect document sets.
  3. Linking to an anchor in a document that requires a frameset change does not work.
  4. Browsers do not bookmark the frameset when a user bookmarks a followed anchor in a subframe.

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.

Figure 7

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

Paragraph-specific bookmarking

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."

Searching

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.

Figure 8

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.

Figure 9

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.

Preservation of link validity

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.

User Response

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.

Future Plans

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.

Conclusions

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.

References

  1. Gamma, Erich Ph.D. Helm, Richard Ph.D. Johnson, Ralph Ph.D. Vlissides, John Ph.D. The Design Patterns CD. Addison Wesley Longman, Massachussetts, 1998
  2. Kientzle, Tim (1999) A Java Applet Search Engine. Dr. Dobb's Journal, Feb.1999
  3. Nielsen, Jacob (1996) Why Frames Suck (Most of the Time). Alertbox, http://www.useit.com/alertbox/9612.html

  4. 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

Credits

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.


Notes

  1. 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.

  2. The model for this discussion is the Effective C++ CD, a dynamic CD-ROM based application comprising the HTML text of two books, a comprehensive index and search capabilities. An on-line demo of the Effective C++ CD can be found at http://meyerscd.awl.com.
  3. DynaText is a very useful tool for both building an browsing a large document collection, as a proprietary tool though it lacks the ability to integrate with non-DynaText material. KnowledgeStation is a bit better at this due to the fact that the program is essentially a custom wrapper for IE4.0, allowing other HTML documents to be easily viewed. Unfortunately, KnowledgeStation's platform support is currently limited to Windows.
  4. 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.

  5. The document cannot reload X_FR.HTM directly because of bugs with the frameset implementation of Netscape Navigator.

  6. 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"
<- Back

Thanks to our conference sponsors:
A T and T Laboratories
ORACLE Corporation  
National Association of Securities Dealers, Inc.

Thanks to our conference event sponsor:

Bell Atlantic


Site Created: Dec. 12, 1998
Last Updated: June 10, 1999
Contact hfweb@nist.gov with corrections.