- EEBO-TCP Interface Taskforce Meeting
- July 16-17
- Northwestern University
The EEBO-TCP Interface Taskforce1 met on July 16 and 17 at Northwestern University to discuss what should be included in the search screens that will serve as access points to encoded EEBO texts. Using a prototype interface constructed by the University of Michigan Digital Library Services, task force members described how they envisioned using EEBO-TCP texts, and the group then worked toward outlining what capabilities an interface would need in order to best meet these expectations. The two-day meeting brought a number of important issues to light, providing valuable insights that will be used to construct a number of different interface design options; these new prototypes will then be made available via the web for evaluation.
The Task Force consisted of librarians and faculty members from several different disciplines, and the discussion highlighted the challenges that working with both early modern texts and digital resources pose for beginning students as well as advanced scholars. The central principle affirmed by the group was that the interface’s design should optimize campus-wide access to EEBO-TCP texts. Along with serving the needs of “expert users,” task force members hoped to see an interface that could be made easily navigable for students as well as for faculty members whose research has not previously incorporated early modern texts.
Discussion suggested that the interface should:
1. Minimize discomfort with the unfamiliar features of these texts: Spelling. Participants wanted the interface to help compensate for the extensive variation in early modern spelling to ensure that users could perform more thorough searches. Strategies proposed included:
- A front end normalizer, which would take a search term submitted in modern English and automatically provide returns that included variant spellings of that term.
- Allowing users to build their own lists of alternate spellings, which would be stored for use in future searches.
- Increasing the flexibility of the current Word Index capability so that users could construct variant spelling lists based on particular works or certain subsets of the corpus. Many task force members also wanted the Word Index to sort by frequency of a word’s appearance as well.
- Simpler truncation, and internal wildcard capability (currently unavailable).
Subject matter. It was agreed that offering searches by subject headings would be beneficial, but it was noted that helpful designations are often omitted from currently existing records and could not be created for this project. There was also much interest in allowing searching according to genre and format.
2. Provide more intuitive search screens. A number of participants said they expected the Simple Search screen to provide access to materials by Author, Title, and Subject, when currently users are asked what sorts of texts they want to search. The discussion then centered on the following questions:
- How do users most want to search these texts? Do they want to identify particular texts, single them out, and then perform searches within that subset? Or, are they more interested in looking for concepts (ie., keywords) directly across all texts?
- How much, and where, should users be exposed to the actual encoding? It was agreed that users should be given the choice and even encouraged to search texts using actual tags, but that beginners should be able to use the database without knowing much about SGML. It was suggested that an “expert” search screen be constructed for those who want to use tagging.
- When should bibliographic information appear on the screen? There was consensus that full citations should appear earlier, but there was also concern that this information might overwhelm users. The idea of putting this information, along with the Table of Contents, in a pop-up window received great support.
- How much of the text surrounding a search term should be displayed? Should Keyword in Context lines be longer, and what would be too long and result in a cluttered screen? Similarly, how wide should Proximity Searches be?
Members agreed that the following changes should be reflected in the new interface:
- Ambiguous labels (like act and line) in pull-down menus should be refined, and full text should be the default setting.
- A browsing mechanism should be added so users can see exactly what is in the database. This could be organized by author, title, or chronology.
- The Advanced Search screen should allow users to narrow results to the categories Prose, Poetry, Drama, and Verse Drama, where Prose would be the default setting.
- Users should be able to perform nested searches more easily.
- Clicking on a search term on a KWIC line should bring users to that precise place in the larger text, rather than to the division’s beginning.
3. Include extensive Help Menus. These should be divided so that users can navigate to their desired answers more easily. Members agreed that the following Help designs would make the section most useful:
- Definitions for features of search screens should appear when the mouse is dragged over them.
- Help menus should appear in a pop up so users don’t lose their place.
- Help should appear from the first screen, pointing users to screens that tell them what they can find in the database and giving them hints on how to search.
- Different kinds of help, all well indexed, should be available.
- A User’s Guide to the database should be available, and it should have two levels. One level should give basic instruction on navigating the database, and another level should describe what tags were used and explain how to use tags in searching.
- A Guide to Early Modern Texts should explain printing conventions of the era, describe spelling habits, offer help in decoding unfamiliar characters, citing pages without numbers, etc.
- Critical essays could also be linked to the database to offer explanations of how printing changed, how ballads and broadsides circulated, etc.
As a result of the meeting, a number of prototype search screens will be developed, and feedback about their functionality will be gathered other the Web. The EEBO-TCP will also be actively pursuing the possibility of a front-end normalizer in response to the task force’s concerns. In addition, the Partnership will look into the possibility of encoding the Thomason Tracts in their entirety to offer better access to these closely-studied texts.