/ Transforming Print Encyclopedias into Successful Electronic Reference Products

If you are an editor, or, like me, you manage editors, you went into publishing because you love books. You will be glad to hear that I am not predicting their demise. I am not even predicting the demise of the multi-volume reference book, at least not any time soon. But I am enthusiastic about the choices that go far beyond books available today to reference publishers, libraries, and students.

A couple of years ago I was so enthusiastic about the electronic possibilities for reference publishing that I wanted to learn to do everything myself: I took a semester-long multimedia-development course at a local university. To learn to use six computer programs in about as many weeks and then create my own project using them, I spent every night after work at the computer lab until the lab closed at 11 p.m. I struggled with programming, Photoshop layers, color-palette translations, animations, video clips, and sound files to create the most organizationally interesting but unattractive and bug-filled CD-ROM prototype I am ever likely to see. Every detail I imagined was ten times as difficult and frustrating to execute than I expected; I spent 5 percent of the time on creativity and 95 percent on the technical aspects. I did not learn to do everything, as I had hoped. I did learn something very practical, however: Developers, programmers, designers, and coordinators of electronic publications earn their money.

I also relearned something that I knew already from the print world: Producing a multilayered reference product is a job for a team of people. Which team members work in house and which are freelance or part of an outside service is the decision of the team manager and his or her company, but to produce an electronic product, the team must include not only an editor, but all those other roles as well. Heading the team is a project coordinator who can speak the languages of both editors and techies.

Cross-References to Hyperlinks

"And what was a cross-reference, after all, but the prototype for a hyperlink?"

The reference work or encyclopedia is perfectly suited to electronic publishing. Not meant to be read consecutively from beginning to end, the encyclopedia is a multilayered reference tool that exists somewhat uncomfortably in the two dimensions of the printed page. Content originally planned through use of a topical or chronological structure often must be presented alphabetically for ease of access in the published work, while chronologies, cultural tables, and thematic outlines that attempt to illustrate other possible structures and means of access to the content appear in front matter or back matter, where readers rarely notice them. The all-important index is another way to gain access to information that might otherwise be almost inaccessible, and cross-references provide some valuable links among articles, but moving from one reference to another in a multi-volume work can be time-consuming and cumbersome. The student who has researched her topic thoroughly ends up with a heavy pile of open volumes on the library table. Does she have enough note cards or enough dimes for the photocopier to capture the fruits of her research?

Present the content electronically, however, and those problems vanish. No more choosing among chronological, thematic, or alphabetical arrangements; we have left the limited two-dimensional world of the printed page behind, and all those means of access to the content can coexist! And what was a cross-reference, after all, but the prototype for a hyperlink? Moving to the referenced article and back again is instantaneous. We can even link two or more multi-volume works. For example, in the Scribner American History and Culture CD-ROM that we are currently developing, users will be able to search the ten volumes of the Dictionary of American History, the three volumes of the Encyclopedia of American Social History and the two-volumeDictionary of American Biography supplements in a single search. And we have the opportunity to add more ways to access the content: clickable chronologies or maps; report topics; or prepackaged search paths. Results will be printed conveniently at the click of the mouse. The more we can make the product easy — even fun — to use, the larger our market will be. Students and other researchers often find big reference books forbidding and always head for the computer first when beginning research. Librarians know that, and increasingly seek out quality electronic reference products to replace or supplement the reams of unauthorized and unconfirmed information available on the Web, which users tend to trust too much.


All right, you say, let's be realistic. The electronic format may be perfect philosophically or architecturally, but there are some problems.

  • Librarians complain that they have run out of room in their CD-ROM towers

  • Librarians find they must assign an assistant to do nothing but help students access one CD after another all day

  • Librarians would prefer on-line access, but find Web-based searches slow

  • Librarians worry that endless subscription fees will eat up their diminishing budgets while they might not be permitted to archive the content they are paying for

  • Many school libraries do not have enough computers to serve Ms. Chapel's thirty English students who descend upon the library all at once demanding to use the Scribner Writers on CD-ROM.

For libraries, the more print volumes on the shelf, the better.

A publisher ought to be able to give customers the opportunity to choose the product that will best serve their needs. For some customers, the solid permanence and familiarity of books make the multi-volume set the best choice. For others, CD-ROMs or on-line services are the answer. Sometimes one format can complement another. For example, a report topic on nineteenth-century women writers identified by using the Scribner Writers on CD-ROM includes volume and page references; the student does not have to read the article on Emily Dickinson on screen but can move on to the books and give someone else a chance to use the CD-ROM for searching. A CD-ROM can be enhanced by links to a Web site where updates are posted.

However, the seductive "search" function can often complicate what should be a straightforward process of obtaining only pertinent information. An electronic search for "dam" may bring up dozens of barely relevant references, whereas a book index, created by a professional indexer, or cross-references chosen thoughtfully by editors and scholars, will point the user directly to the few articles on Hoover Dam, hydroelectric power, and the Tennessee Valley Authority. Here is where the editor comes in — and stays! — in electronic-product development.

With three-dimensional complexity and automated searching come challenges to the product's ease of use that only an editor, as a member of the development team, can solve. Although automatic searching has its uses, most of the time finding information needs human intervention. After all, no search engine can imitate the depth of thought and editorial judgment that goes into creating a thorough, analytical book index. The aim should be to put that same intensity of editorial planning into the creation of the navigation tools in the electronic product.

"Just as reference books are ideally suited to electronic formats, so are reference editors ideally suited to electronic publishing"

But reference editors are perhaps too attached to books, you might argue. The reference editor's world is defined by the printed page; the minutiae of type specifications; sewn bindings and beautifully stamped cases; indexes cast off so perfectly that there is only one blank page at the end of a five-volume set. How are such editors going to make the transition to publishing a little disk in a box, or perhaps worse yet in their eyes, a service that you cannot hold in your hand?

Books are not going away, as I have already argued. Furthermore, just as reference books are ideally suited to electronic formats, so are reference editors ideally suited to electronic publishing. They are sophisticated thinkers in the abstract, practiced at mapping out intersections of time and space as they relate to the creation of a historical encyclopedia's table of contents, for example; they are experts at creating multilayered content full of links. It will not be necessary to hire a new editor specializing in electronic-product development, as long as there is other electronic-publishing support within the company to coordinate the more technical aspects. I guarantee that one or two editors on every reference editorial team will take naturally to electronic publishing. Just watch and see who suddenly comes up with creative ideas that were impossible in print and who emerges as a master of data manipulation.

A Market-Driven Concept

The concept for the product — the subject matter and the initial plan for its presentation — must be market driven. To avoid mistakes, we must maintain two-way communication with the market at all times. At Scribner Reference we have the advantage of a large library-sales force that gives us immediate feedback from the field on existing and proposed products. In addition, we conduct surveys and consult our librarian advisory board to find out whether the product is really needed in libraries. That is the same sort of research we do for a print product and seems almost too obvious to mention, but it's important not to abandon thoroughness in any area — market research or editorial — in the excitement of electronic publishing. As Matthew Bender's Barbara DeYoung put it recently in an AAP/PSP (Professional and Scholarly Publishing) seminar: Is your product "nice-to-have" or "need-to-have"? In these days of shrinking library budgets, customers are less and less likely to buy nice-to-have products, especially in expensive electronic formats.

In Scribner Reference we have created electronic products by converting published multivolume sets that have already had a long life in print. As a proponent of print-CD-Internet choices, I might be unrealistic; clearly we still have a fear of cannibalizing print sales with an early electronic product, even though there is evidence that many libraries duplicate content in different formats. Although the idea that CD-ROM technology is a short-lived technology that will soon be superseded by Web-based products has become the received wisdom lately, there could be a swing back to CD-ROMs when librarians recognize the technological limits of the Web in manipulating large databases (speed is certainly a problem, for example) and realize that with some products they have paid for access, not content. It is likely that CD-ROMs will continue to sell, especially in combination with Web-based services.

The specter of print-sales cannibalization fades when we note that print and electronic products do not necessarily correspond one to one. If you are considering converting a print reference product to an electronic reference product, think about the content of the books as a database and each chapter or article as an entry in that database. Smaller databases can be combined to create larger ones in which entries and groups of entries are linked to each other in useful ways (a "relational database"). If a new print product does not fit right into an already-existing larger database, or naturally combine with others to create such a database, then you might hesitate to make an electronic product out of it right away. For example, at Scribner Reference we would not make a CD-ROM out of the forthcoming two-volume Mystery Writers alone, but we would add those 84 articles to the database of 1,564 writers now represented by the second release of Scribner Writers on CD-ROM. The print product's usefulness must be enhanced in electronic form; the context of a large database of material is one of our current ways to meet that demand. (Other ways are discussed below under "Content and Added Value.") It is important when targeting print content for conversion to make sure that the combined database is not only needed in the marketplace but also has the potential, with enhancements, to become a cohesive product.

"On a book page you don't need little signs on every page saying 'Forward' and 'Back' or 'This Way to the Table of Contents' "

It's also important at the concept stage to know what kind of equipment your customers are using, and what competition your product will face. The marketing department or your electronic-development people can research the former; they might need to do a survey. Editors are helpful in analyzing the latter.


At the design phase you will choose colors, icons, and buttons and plan screen layout. A market focus group should react to preliminary designs before much programming is done. The editor should also have the opportunity to comment on the design. Some editors are more visually oriented than others, but all of them will know if a screen in chartreuse and fuchsia is an appropriate representation of your imprint. Names and labels might need editing. The editor can make sure that screen shots prepared for marketing brochures are free of embarrassing errors.

Some developers include organizing content and planning navigation under the "design" rubric, but I stubbornly consider organization and navigation "development" issues, as in print publishing. (Those issues are discussed below under "Development.") Designing a computer screen and designing a printed page are very different. Some surprises, both good and bad, about computer screens are:

  • The computer screen is always in full color. That is exciting if you are accustomed to black-and-white book interiors, and you can easily make a black-and-white print product look more visually appealing on the screen. However, you might be tempted to overuse color to the point of making the user dizzy. A good designer will choose a range of compatible colors appropriate to the subject matter and stick with it (sometimes referred to as the "color palette"). It's especially important to make sure the combination of type and background colors doesn't make the reader squint.
  • The screen is small, and there is little room left for your content after you find a place for navigation features that you want on every screen, such as toolbars. On a book page you don't need little signs on every page saying "Forward" and "Back" or "This Way to the Table of Contents," but on a computer screen those features are necessary and take up a significant amount of room. The more numerous the useful features are to which you want the user to have constant access, the less room you have for the actual content of the database. For example, if you want the user to be able to see the search he just did as well as its result, you will have to have side-by-side windows on the screen, with the boxes for typing a search on one side and the text of the article that the search pulled up from the database on the other side. If you think of the screen as a page, you might have only 50 or 100 words of text on that page, instead of the 750 you might be accustomed to on an 81/2-x-11 book page.
  • The screen is shaped horizontally, not vertically. That makes side-by-side windows a natural and any attempt to translate a print design onto the screen awkward at best.
  • Resolution is imperfect. Detailed illustrations are going to be difficult to see, unless you include a feature whereby the user can click on pictures to make them larger.
  • Users won't always see what you see in testing. That is especially true with a Web site, but it is also true for CD-ROMs. Different monitors show your product in different sizes and resolutions.
  • Items such as pictures can move or rotate on the computer screen. Some animations are easy to create and can add excitement to your opening screen. Animated diagrams to illustrate a point in the text are more difficult to create and, of course, more costly.

Although a computer interface is different from a book interior in so many ways, it is important to keep in mind that just as a reader needs a margin on the book page to rest the eye, some space is needed on the screen for the same reason. As screens become crowded with features, that becomes quite a challenge for the designer. Don't forget that although you might plan many useful navigation features, the best way to achieve self-explanatory navigation ("transparency") is through simplicity of design.

"Editors will be dubious, but keyboarding and scanning are both guaranteed at 99.995% accuracy"

Conversion and Development

Conversion is taking a print product and turning it into a digital file, which can in turn be manipulated to become part of a CD-ROM database or a new print product. Development is taking those digital files and creating a new product, usually electronic. Ideally the content will be coded during conversion with SGML codes that identify the content elements, making it easier for those new digital files to flow into the design template created by the developer. Sometimes it's hard to know whether you need a developer before you convert the data, so that the DTD (Document Type Definition) will be perfectly suited to the electronic product currently being planned, or whether you should get the conversion going immediately and take your time deciding on the right developer later. If you have a large amount of material to convert — whether by keyboarding or by scanning — that process should start as soon as possible. Ideally, you will have a developer on the project soon, so that the developer and the conversion house can communicate. Before choosing among developers, check their references.

Conversion is amazingly accurate. Editors will be dubious, but keyboarding and scanning are both guaranteed at 99.995 percent accuracy. To avoid any possible lapse in Scribner editorial quality, we had all of the newly keyboarded Dictionary of American Biography printed out, and one of our senior editors offered proofreaders a flat fee for proofreading each impressive stack on the floor of his office; he inspired proofreaders to read quickly by writing the fee on top of each stack, $1,200 on taller stacks and $800 on shorter ones, for example. All 19,173 biographies were read in record time. I thought that strategy was terribly clever, but in retrospect I must admit that a thorough read was not needed. Mostly all the proofreaders found were decades-old editing oddities.

One must be aware, however, that glitches can creep in when the converted files are plugged into the design template for the new product. A careful review is necessary at each stage of the process. For example, we have found that italics in headings might vanish or verse extracts might appear misaligned. One can anticipate some of those problems but not all of them.

If you have typesetting tapes available for the books you want to convert, go ahead and try to get the conversion house to use them. But they will probably tell you that stripping out the old codes and replacing them is more costly than starting from scratch. I am told that that is because typesetting files are often inconsistent, undocumented, use nonstandard coding, and may have been prepared sloppily. It is important to implement well-structured and consistent composition in the production of future print products, to create typesetting files that can actually be used for more than creating one print product. To use SGML coding at the start is the best way to go.

DTD (Document Type Definition)

"Functionality is what the product does, where it goes and how it gets there when the user takes mouse in hand"

It is easy to understand what a DTD is if you think of it as a glorified design survey, the kind of survey done in the print world by a production editor or managing editor to identify each element in a work that needs its own design specifications. Examples of such elements are chapter titles, chapter numbers, regular text, first-order headings, second-order headings, and picture captions. Instead of making up our own codes (like CT, CN, TX, H1, H2, and PC), however, we will now use SGML codes (Standard Generalized Markup Language), which are descriptive (like chapter title) as consistently as possible. And instead of identifying only elements that need a special design, we are also identifying elements that might one day be linked or regrouped in an electronic product. A DTD is much longer and more complicated than a design survey, and you will need someone — probably a staff person from the conversion house or developer — to advise you on creating it. The SGML-coded files will, ideally, plug into any design template — for electronic products or print.

Although the DTD will exist separately from any product to which it will be applied, the DTD should be developed with the actual workings of the first electronic product in mind, if possible, so that all the elements needing separate codes will have them. If you are already planning the presentation of the content in the electronic product, it will be easier to decide on the practicality or sheer craziness of coding (sometimes called "markup") at various levels. (The developer might talk about how much "granularity" you want to build into the DTD.) Should we code only what we need now, we might ask ourselves, to create the functionality now planned in the initial electronic product, and go back later to add more coding as needed for future releases or additional products? Ideally we would prepare for future products now, but how much coding can we afford now? Will it ever be useful to have coded separately various sub-sub-sub categories of text? Those are tricky questions that each company must answer in its own way. For example, we debated whether to identify separately each bibliographical entry in the Scribner Writers articles, or whether it was sufficient to identify the bibliography as a whole. We decided on the latter, because although a feature in the Scribner Writers on CD-ROM lets users jump to the start of each article's bibliography, the bibliographical entries are not footnotes or references to which one might wish to jump individually.

"Functionality" is what the product does, where it goes and how it gets there when the user takes mouse in hand and begins to journey through the screens and features. The entire team, including the editor, should be involved in developing the functionality of the product and the DTD. The plan for the functionality will look like a storyboard, a lot of boxes with arrows connecting them; it might become a large wall chart.

Content and Added Value

The range of content to be included might not be as obvious as you might expect. Should you include prefaces, various content lists, indexes? Editors can advise here, as well as on the details of the larger puzzle: What can we add to this new electronic database to make it more useful? As I mentioned above, one way we have made our books more useful in electronic form is to combine them with others on like subjects. But a large database can be unwieldy. How will the user approach the content? Will every search give 300+ results, and if so, what is the user supposed to do next?

The development team will have to do some research to find out which searches or ways of using the product are most likely to be the most popular, and the editor can edit search results to meet users' needs. We have added special searches and lists of report topics to our products to make them friendly to high-school students, and we have added hundreds of pictures to works that were not illustrated at all in print. Picture research was supervised by the editor, who learned to choose pictures that not only elucidate the text but also look clear at computer-screen resolution.

"Don't plan a lot of expensive features without first checking to see whether the market really wants them"

In the Scribner Writers CD, we added headnotes that serve as abstracts to long bio-critical articles, so that the user does not have to read a long essay to find out whether she wants to continue investigating in a particular direction or not. For example, if you are reading the article on Ralph Waldo Emerson, and Thomas Carlyle's name comes up, the word "Carlyle" is a link to the article by that name. Click on it, and you do not go to the beginning of a 12,000-word article, where you might have to read a long passage to figure out who Carlyle was; instead, you go to a headnote that gives you his birth and death dates, his nationality, ("Aha," you say, "He was not a New England Transcendentalist like Emerson; he was British"), a phrase or two about what he was famous for, and his picture. If you would like to continue reading about him after glancing quickly at that information, you can. Or you can go back to Emerson and continue reading about him, without the flow of the Emerson article having been drastically interrupted. The headnotes serve as a bridge from one article to another and add a new layer of context to the articles. The in-house project editor who originated that idea hired freelance writers, researchers, and copy editors to create the headnotes. Every special feature we have invented has taken much editorial thought and time to devise and execute.

The question of how much can be done automatically through programming ("programmatically") comes up. Should every article title embedded in text be automatically hyperlinked to the article itself? What if the article is about the person "Napoleon" and the text refers to the dessert? What if the first two names of "George Washington Carver" are linked automatically to an article on George Washington? What if automatic links are so tangential that no editor or indexer would ever choose to waste a reader's time with them? Then our product is not making sense, that's what. If automatic linking is to be done and then revised, time must be allowed for testing and fixing. If we forgo automatic linking altogether, editors or indexers must identify each useful link by hand. If we are dealing with many millions of words of text, that might be prohibitively costly or time consuming.

To prepare usefully limited search categories, the editor will probably find himself involved in the creation of a set of descriptors about each reference article called "metadata." Articles will be put into categories based on predictions about users' interests determined by surveys and other market research; each article must be considered individually and placed in one or more of those categories. Some companies, especially aggregators, find it useful to use Library of Congress categories; at Scribners we use simpler, curriculum-related ones. The more those decisions can be considered and reconsidered, the more rich and useful the future electronic product becomes. For example, an indexer puts all the Dictionary of American History articles on court cases in the "Law" category; the editor spots Brown v. Board of Education and adds it also to the "Civil Rights" category. "Law" and "Civil Rights" are now part of the metadata for Brown v Board of Education. Metadata also includes information about the print origin of the product (title, volume number, pages, contributor, number of illustrations, etc.), some of which might actually appear on a screen somewhere in the product and some of which you are saving for use in the creation of other electronic products or print spin-offs in the future. If the metadata can be organized hierarchically, it can be used to create broad or narrow searches.

Again, the importance of editorial involvement and oversight in creating special features cannot be overemphasized, nor can the importance of keeping in touch with your market at all times. For example, don't plan a lot of expensive features without first checking to see whether the market really wants them; a sound track, for example, is probably unnecessary for a product to be used primarily in libraries where quiet is usually the librarian's aim.


Production and testing should constantly feed into each other in a never-ending cycle.

Bugs not even the techies can imagine will be lurking in your first test disk, and your second test disk, and your third. Testing is imperative, and the more of it your budget and schedule allow, the better. As soon as possible after conversion, test files should be made available to a number of editors so that they can examine them — perhaps on a private Web site.

As features develop, they should be tested not just to ascertain that they work but to confirm that they make sense. Sometimes the developers and editors working on the project will have become so used to certain features that they use them without thinking about them anymore. A fresh perspective is always a good idea. The first person to test the disk will be the editor who has worked on designing and preparing it, but others who have never seen the project should also look at it. "What is this button called 'Tips'?" they will say. "It looks like a 'help' feature but instead leads me to related articles. This is confusing." Or "Why is the Search button almost hidden in a toolbar while less central and less useful features are listed in the middle of the screen in large type?" That is the first, in-house stage of what we call the "reality check."

As soon as you have a prototype disk ready, it should be tested by real users. What do users do with what is available on the search screen; is a stack of boxes in which to type search terms the best way to present a nested search, for example? Is the navigation intuitive? Does the product have enough visual appeal? And last but not least, is the content complete and accessible, or do maps or glossaries need to be added? Following the testing of the prototype, the team can lock in the specifications for the product.

"Beta testing" usually refers to the testing of a disk that is almost ready to be replicated. Again, real customers and users should test it. At that stage you are mainly testing installation and looking for little glitches in text and functionality.

"Librarians don't need an 800 number to call for help in using books"

Watch out for including new articles or features at the last minute that haven't gone through all of the proper preparation; it's never as simple as you think it will be. Shortly before publication of the Scribner Writers on CD-ROM, brand-new articles from the then-forthcoming American Writers Retrospective Supplement were added to the CD-ROM database and all the italics in those nineteen lengthy essays vanished during conversion from the typesetter's files. Spending our Friday evening inserting italic codes one by one was not in our publisher's plan for the weekend, nor mine, nor the other Scribner editors', nor was that the best use of a top-flight editorial team's valuable time, but among us we got the job done by the deadline. Unfortunately, "Italicized by Hand" won't be a useful tag line for marketing purposes! In dealing with technology, one must, in a paradoxical way, count on unpredictability.

Packaging and Marketing

During development of the product, your production department will be working on the envelope or box in which the CD-ROMs will be shipped. Even though the product ought to be self-explanatory to any user, you should include a booklet of instructions in the packaging, because customers will feel ill served without one, and at the very least they need directions on installation. For the library market the packaging does not have to be fancy, as most librarians will not keep it. The editor should have the opportunity to revise all packaging and marketing copy for clarity and accuracy as well as to proofread the final proofs before printing. In addition, customers will appreciate having access to trial disks or demonstration files online, and they like to see full-color screen shots in printed marketing material.


Despite general alarm in the news media about the decline of American education, librarians don't need an 800 number to call for help in using books. However, anyone who has ever installed software or CD-ROMs in a computer knows that electronic products are different, and an 800 number for support is a must. Support is not the marketing director's job, the editor's job, or the electronic-publishing director's job; it is the job of a technical-support department, either at an outside service or in house. Support can take a lot of time even when your product is relatively easy to install and use; one reason is that many problems have little to do with your individual product and can be traced to the customer's own machine or network. Before you choose an outside service, get references; remember that these people will become the face of your company to customers as well as provide you with valuable information. A good provider (or in-house supervisor if you decide to create your own support department) will hire people with technical experience and gracious telephone manners — a rare combination — and present you with detailed telephone bills and call reports, so that you can track problems and improve the next release of your product.

The Electronic-Publishing Specialist

While the editor has an important role to play in electronic publishing, he or she cannot run the entire electronic project. If she tries, she might end up with a product like my class project! There must be at least one full-time person on staff who can negotiate knowledgeably with developers and other service providers and coordinate all the aspects of the project, including the editor's role. That is the person who is conversant enough with technology to serve as interpreter if the editor and the developer or programmer cannot understand each other.

Don't let an outside company use your project as a learning experience and your project budget as support to develop the company's capabilities for other clients' future benefit. But on the other hand, don't begrudge electronic publishing support people — whether they are in house or out of house— their roles and the money they will cost. Editorial team members must be able to focus on the editorial function without getting distracted by technology. Your budget and schedule will benefit from a team-based organization, your product will be richer and more user-friendly, and every member of the team will have more fun creating it.

The Reference Frontier

One of the things I have always loved about reference publishing is that the field is wide open for originality and creativity. Although competition is growing all the time and the field is becoming populated with more publishers and products than ever, one can still invent, for example, an Encyclopedia of the Renaissance or an Encyclopedia of Latin American History and Culture and know that such a work has never been published before. In library-reference publishing we are always oriented not only toward today's needs and school curricula but also toward the future, creating works that we hope will have lasting value to scholars, students, and nonspecialist readers alike and stay on library shelves for ten or twenty or more years. The endless possibilities provided by electronic formats have opened the reference frontier anew, but in recognizing new possibilities it is very important never to lose sight of market needs, or the importance of the editorial function, or other things that have brought us success in the past. Technology will continue to change and develop, and — unlike bound volumes — the electronic formats we are producing now will look archaic in ten years. The challenge now is to create content for the future inspired by the technology of the moment.

Sylvia Kanwischer Miller has been with Macmillan for 13 years, working on books in four reference imprints. Currently she is executive editor of Scribner Reference, where she acquires, develops, and supervises the editorial production of multivolume reference works and CD-ROMs in the humanities and social sciences. Her recent works include Civilizations of the Ancient Near East (4 vols.), winner of the 1996 Dartmouth Medal and the R. R. Hawkins Award, and Writers for Young Adults (3 vols.), one of the Best Reference Sources of 1997, according to the Library Journal. Electronic products are Dictionary of American Biography on CD-ROM and Scribner Writers on CD-ROM Release 2.0. Author of "If You Won the Lottery," a chapter in My First Year in Book Publishing edited by Lisa Healy (1994), she speaks each year on reference publishing at the New York University Publishing Institute. Last year she spoke on the role of the scholarly editor in electronic publishing at the Professional and Scholarly Publishing association (AAP) meeting, and last semester she was guest lecturer on information-product development at Drexel University. She holds a B.A. from the University of California at Berkeley, where she graduated Phi Beta Kappa, and an M.A. from Columbia University; both degrees are in comparative literature.