380 likes | 516 Views
The FirstSearch User Interface Architecture Universal Access for Any User, in Many Languages, on Any Platform. Gary Perlman, perlman@oclc.org Consulting Research Scientist OCLC Online Computer Library Center. Outline. What is OCLC and FirstSearch? Goals for New FirstSearch
E N D
The FirstSearch User Interface ArchitectureUniversal Access for Any User, in Many Languages, on Any Platform Gary Perlman, perlman@oclc.org Consulting Research Scientist OCLC Online Computer Library Center
Outline • What is OCLC and FirstSearch? • Goals for New FirstSearch • The User Interface Architecture • How the Architecture Meets the Goals • Summary and Conclusions
What is OCLC and FirstSearch? • Non-profit member library association • Furthering access to the world's information and reducing information costs. • 37,000 libraries, 74 countries/territories • Shared cataloging 43M+ records, 779M+ holdings, 103M+ ILL • Uniform interface to 80+ Databases • 100M+ records, 6K+ full text serials • TTY 1991, Web 1996, 16K+ libraries, ~10M searches/month
FirstSearch: The Second SystemMany New Features • Limit to library holdings • Limit to available full text • Cross-database searching • Ranking and sorting • Integrated thesaurus • More wildcards • Library customization
Goal: Retire Related SystemsMany Legacy Requirements • FirstSearch TTY: 24x80 telnet version • EPIC: query language • Electronic Collections Online: full text journals • FirstSearch Web (original)
Goal: Avoid All Old ProblemsMany New Variables • New functionality • New application layer (SiteSearch), concurrent development • New programming language (Java) • New version of UNIX • New “high performance” file system • New server hardware
General RequirementsMany with One-Line of Detail • Multi-platform • Multilingual • Levels of users • Text-only version • Universally accessible (ADA compliant) • Help system
General Requirements:Multi-Platform • Browser: Netscape and Explorer • Versions: 4.x (and then 3.x) • JavaScript: available or not • Screen size: large, medium, small • Hardware: Windows, Macintosh • Colors: down to 256
General Requirements:Multilingual • English (en) • French (fr) • Spanish (es)
General Requirements:Levels of Users • Home (welcome) • Basic (most naïve users) • Advanced (most experienced users) • Expert (query language users)
General Requirements:Text-Only / Accessible Version • Replacement for FirstSearch TTY • Possible ADA-compliant version • No real experience in the area
General Requirements:Better Group Coordination • Development: functionality • Database: loading data • Marketing: requirements & terminology • Documentation: help & translation • Graphic design:icons, fonts, colors, layout • Usability: evaluation & re-design
Goals for the UI Architecture • Adapt to inevitable requests for changes (due to new requirements, usability, performance, etc.) • Allow incremental development (due to so many unknowns) • Defer decisions & allow global changes
Partitioning and Construction • Functional Partition (Pages): database selection, search, results • Platform-dependent Partition (Style): browser, version, options, hardware • Language-dependent Partition (Lang) • Cross-products of pages and styles and languages using Templates
Functional Partition:The FSPage Object • pagename: an internal identifier • pagetitle: a title displayed to users • pagelabel: a short phrase for links in menus • tips: on-screen help tips • status: on-screen status information • controls: page-specific controls • action: a form action • panel: a main form panel • ...
FSPage for Expert Search [expert] pagename = expert pagetitle = &Lang.pagetitle.expert; pagelabel = &Lang.pagelabel.expert; tips = &Lang.tips.expert; status = &Lang.status.expert; controls = &Style.dbinfo.gadget; &Style.scanindex.gadget; &Style.thesaurus.gadget; &Style.news.gadget; action = QUERY:searchtype=expert term = termexpert index = indexexpert focus = termexpert panel = &Style.dialog.begin; &Pages.basic.submit; &Pages.expert.searchbox; &Pages.expert.index; &Pages.advanced.limits; &Pages.advanced.options; &Pages.basic.submit; &Style.dialog.end;
FSPage for Expert Search:search box [expert] searchbox = &Style.dialog.rowbegin; &Style.font.labelbegin; <label for=termexpert> &Lang.label.find; </label> &Style.font.labelend; &Style.dialog.elementbegin; <textarea name=termexpert id=termexpert> &termexpert; </textarea> &Style.dialog.elementend; &Style.dialog.rowend;
Expert Search (Lynx) Current database: WorldCat Type search terms and choose limits. Click on Search. Use the reference information on the screen. [Search] dog_____________________________________ ________________________________________ ________________________________________ ________________________________________ ________________________________________ ________________________________________ Indexed in: [Keyword (kw:)_________] Limit to: Year 1990-______ Document Type [Books________] Language [English___________] Library Code ___________ [_] Items in my library (OCL) Rank by: [No ranking__________] [Search] [info] [index] [subjects] [news] [help]
FSPage for Detailed Record [record] pagename = record pagetitle = &Lang.pagetitle.record; pagelabel = &Lang.pagelabel.record; tips = &Lang.tips.record; status = &Lang.status.record; controls = &Style.thesaurus.gadget; &Style.ill.gadget; &Style.holdings.gadget; &Style.email.gadget; &Style.print.gadget; action = FETCH:fetchtype=record panel = &Style.dialog.begin; &Style.navigate.gadget; &Style.record.gadget; &Style.navigate.gadget; &Style.dialog.end;
Platform-Dependent Partition:Replace Styles with Entities • Mark up text with entities (constants, variables, and methods) &ErrorBegin; Something bad happened &ErrorEnd; ErrorBegin = <font color=red size=4><b> ErrorEnd = </b></font>
Platform-Dependent Partition:Modify Entities with Entities &ErrorBegin; Something bad happened &ErrorEnd; ErrorBegin = <font color=red size=&ErrorSize;><b> ErrorEnd = </b></font> [screensize=default] ErrorSize = 4 [screensize=small] ErrorSize = 3 [screensize=large] ErrorSize = 5
Style Abstraction/Presentation extract formats/styles Platform- independent HTML file Style file style entity substitution
Language-Dependent Partition • Replace all language with entities &ErrorBegin; &Lang.msg.bad; &ErrorEnd; [msg] bad = Something bad happened nohits = Your search <b>&query;</b> matched no records nojs = your browser does not support JavaScript
Internationalization/Localization replace language strings Language- independent HTML file Language file language entity substitution
Result of Partitioning • Pages.ini: functional decisions • Style.ini: platform-dependent decisions • Language files: • en.ini (English) • es.ini (Spanish) • fr.ini (French)
Template-Based Page Generation <html pagename="&pagename;"> <head> <title>&pagetitle;</title> </head> <body> &pagestatus; &pagestips; <form name="main" method="POST” action="&pageaction;"> &pagepanel; &pagecontrols; &Style.FSMenu.gadget; </form> </body> </html>
Dynamic Page Generation Pages file Language files Style file GUI template Lynx template Print template
Adapting to Levels of Users • Page names: Basic, Advanced, Expert • Search box: 1 small, 3 small, 1 large • Indexes: 3, 10-15, 20-30 • Limits: full-text/library, all, all • Help: simple examples, complex examples, reference material on screen
Lynx Text-Only Version • Used same style file as graphical, but used vertical page template • Lynx knows that <tr> starts a new line, so tables could be left in HTML • Lynx-only format entities used to tune the display: space, bar, break, line, paragraph, comment
Accessibility Issues: WAI Guide • title attribute: shows popup help on form elements and links • LABELtag: associates prompts with form elements • accesskey attribute: associates Alt-x key with form element • table attributes: not yet supported
Coordination Issues • INI files were easy to edit by non-programmers, but validation scripts were run for all • Partitioning style and language centralized decisions, providing control to the right authority • Large- and small-scale changes were made independently
Summary of Architecture • Style, Language, and Functional partitions stored in INI files - required the user interface police, armed with validation scripts • Heavy dependence on dynamic entity substitution, including page templates • Both required a change of development paradigm - more rigorous control
Cost-Benefit Analysis:Cross-Product of Partitions • Pages • add/change screens independently • Styles • add/change templates • add/change (conditional) attributes • Languages • change terminology in one place • add a new language
Conclusions • Addressing many access issues helped with individual (unexpected) issues • Not critical to get design right; need to be able to change what is wrong • Expect the unexpected • new/changed requirements • “opportunities” from usability testing
Thank You! • Gary Perlman • perlman@oclc.org • http://www.acm.org/~perlman/