Journal Reviews and Reports

CompendexWeb

George S. Porter
Engineering Librarian
Sherman Fairchild Library of Engineering and Applied Science
California Institute of Technology
Mail Code 1-43
Pasadena, CA 91125-4300
george@library.caltech.edu

In the summer of 1999, Engineering Information, Inc. (Ei) announced a new interface for CompendexWeb. They labeled the old interface, which many sci/tech librarians were familiar with from several years of use, the "Traditional Interface" and introduced a "Simplified Interface". As the summer progressed, few librarians of my acquaintance expressed any real interest in trying the new interface. We all had work to do and knew how to accomplish it in the tried and true interface. Ei turned up the heat a bit late in the summer as they indicated a strong desire to pull the plug on the "Traditional Interface" and set a deadline for the changeover to the "Simplified" version. The looming deadline was brought into stark relief for me when Susan Ardis posted a query on ELDNET-L.

Ei seized my attention by threatening to discontinue the old/traditional interface by October 1, 1999. At least that's the way the Welcome screen appeared to read. There is nothing like an adrenaline rush to motivate the masses to try the new way. Ei has since relented, somewhat. Their welcome message now indicates that due to an outpouring of concern, both interfaces will be maintained while improvements are made to the "Simplified Interface". It does leave one wondering what "improvements" can be made to a "simplified" interface.

The new interface has a vastly more attractive record display. There is an unfortunate, but intended, emphasis on their Document Delivery Service.

How do the different interfaces hold up in a side-by-side comparison? Have any improvements been made in the intervening 6 months? Searches were conducted 15 September 1999 and 30 March 2000. Results from the different sessions are separated with a |

Start with a reasonable search query:

java beans and (object or objects) searched 1990-present, although the topic is self-limiting to a shorter period

Traditional interface/keywords : 2 | 2 Traditional/All fields (or advanced keywords) : 5 | 6

Simplified/Basic : 3 | 3 Simplified/Advanced (all fields or native syntax) : 5 | 6

It is ALWAYS alarming when an interface provides different sized retrieval sets for what are ostensibly identical search queries. [Rarely do I indulge in absolutes and broad generalizations. In this particular case, it is not possible to over generalize!] Search engine designers should have come to this realization of their own accord, repeatedly, as they reinvent the wheel. No one should foist such a system onto a paying public without addressing this basic design concept. It has been troubling for years that the Keyword and Advanced Keyword in the "Traditional Interface" gave differing results. The new interface doesn't appear to address this shortcoming to any great extent. The rationale, as explained by Ei, is that the Keywords or Basic search version does automatic truncation or stemming. The underlying search engine does not appear to have been tweaked much, but the divergence in retrieval between the two most basic search sets is unsettling.

I have a problem with a trend that I've noticed developing among some database producers and vendors. Why on earth are Ei, ISI, et al insisting on locking researchers into search front-ends that are expressly designed (automatic stemming being a prominent example) for novice searchers? The power of a Dialog or STN command line interface, capable of exploiting the richness of the underlying data structures to manipulate sets is being walled off from the end user. This isn't necessarily a problem when creating an interface for SIRS, Readers' Guide to Periodical Literature or the like, but we're talking about the tools that should be providing both the content and the interface to facilitate literature reviews for graduate students in various science and engineering disciplines. Notable exceptions to this misguided interface design trend include Ovid (a very positive holdover from the BRS search engine technology) and SciFinder Scholar from the Chemical Abstracts Service.

The new displays, although my preference in both interfaces is Abstract, are more compact and visually pleasing. Contrast Figure 1 (Traditional) with Figure 2 (Simplified). The screen size was matched to facilitate comparison.

(Figure 1)

(Figure 2)

Many of the clunky gray buttons, which chewed up the top 2 inches of printouts, have disappeared. The overall space gain is not that great because Ei has added a couple of EXTREMELY helpful links and messages that have been missing all these years:

The search statement is now displayed (but not editable and re-executable).
Links to other decade segments now appear.

The classification codes, document type, and identifiers have all been relegated to the Ei Tagged display format. This is a very good compromise. It removes some of the visual clutter from the Abstract display, while preserving the subject terms and bibliographic information. In fact, the subject terms are much more readable since they've been placed in a table next to the abstract proper, instead of being lost as semicolon delimited, line-wrapping text noise.

Search Tips seemed more inviting than Help. I'm an experienced professional, why would I want to consult a Help file? However, even seasoned searchers will cadge a few search tips, given the opportunity. Search Tips for the Advanced Template took a while to be developed, but are generally well executed. Most of the tips/help were helpful. If there is a bound phrase index available (author, subject term, serial title), it STRONGLY RECOMMENDs (their emphasis) that you use the index file. Kudos. That kind of emphasis is more than welcome.

An egregious blunder has to be pointed out, though, in the Basic advice. Among the examples under All Fields Search lurks "gallium arsenide materials". It is bad enough that Ei has failed to achieve a level of specificity in their subject headings sufficient for retrieving articles about GaAs, without compounding this deficiency by encouraging users to add extraneous words which will be ANDed into a WORD (NOT PHRASE) search further damaging retrieval prospects. Results: gallium arsenide (28913 | 30601 1990+); gallium arsenide materials (8251 | 8791). Roughly 21,000 records lost based on misguided advice from a Help! file. Although this glaring deficiency was pointed out to Ei more than 6 months ago, they have yet to exercise themselves over it and it remains intact and ignominious.

Advanced search: 28502 | 30170 vs 8 | 8!!! Phrase searching is very powerful, indeed. That power results in the difference between an inadequate search (Simplified/Basic) and a totally unacceptable result (Simplified/Advanced)!

Overall, I'd have to say Ei has addressed most of the easy stuff. Writing decent Help files is neither extraordinarily easy nor impossible. It is a shame that counterproductive advice was included in the original draft and unconscionable that it be allowed to remain uncorrected. Ei has improved the display of retrieval sets and eased the transition between segments of the database. Actually improving the search engine is an item that remains on the table, as is dealing with shortcomings in their documentation.

We welcome your comments about this article. Please fill out this form for possible inclusion in a future issue.