Karen Coombs
University of Houston
A couple definitions: Mashing up — taking data from different places and shmooshing it together. Remixing — rethinking the way we do the library web site.
University of Houston library web site, 3 or so years ago, had 1500 pages of content all managed centrally. Needed re-architecting for the same reasons we have all experienced: Staff have a wide range of HTML and computer savvy — running the whole gamut from technology illiterate to programmers. Library web sites incorporate information from lots of different sources. There’s lots of redundancy of data — the same information appears on many different pages. Library users don’t come (or wish to come) to library site — there’s a need to get library information where patrons are. And finally, library information is not well integrated into the curriculum.
The ACRL information literacy report reinforced that library instruction needs to take place as part of the curriculum, not as an add on. So — in the classroom, in the Course Management System.
The traditional source has been to implement database-driven sources, skinning pages to look like each other. What Karen wanted was an easy to use system with little Web Services (her department) intervention. Content that can be easily mixed, reused, and shared within and between systems.
Took inspiration from iGoogle, Drupal, netvibes, and WordPress. Liked content types, widgets (easy drag-and-drop customization).
In the system built there, content owners are responsible for content organization and metadata. Librarians have responsibility; supervisors have review role. A librarian owns pages but also items (building blocks of pages).
Use many tools: LibraryFind, WorldCat, Archon, Serials Solutions, flickr, WordPress multiuser.
The site is completely modular — librarians can add modules to pages, organize them how they want. Fonts and colors are controlled centrally, but layout is up to the content owner.
Content is remixable. This means that content can be used elsewhere inside the site, but also used outside the site. The external uses aren’t quite ready — the API is still in development. But they do use microformats, so if you view an event, the event is stored as an HCalendar microformat. Contacts are HCards, to be added directly to visitor’s address book. Flash objects can also be embedded into a web page.
Virtual Subject Library
This is essentially a subject guide. It brings together federated search, new books, relevant databases, subject liaisons, text blocks, etc. Sample (may not be permanent — this link is on a test server).
Karen walked us through a quick demonstration of building a page. It’s efficient and elegant — assuming that all the resources have already been added. An advantage to this is that there are no broken links. Or if there are, they are found and corrected very quickly since there is only one database entry. Most staff built their libraries in the course of a week — but it took more time for them to conceptualize what they wanted to have on the page and where to put it.
Content Creation and Management
Tab editor works similarly. Through the admin interface, a librarian provides the names of the tabs, gives each tab a type, sets the order, and then (for each tab) makes it do the right thing. A search tab is configured to search something. A text tab is configured to display text. And so forth.
An interesting add-on is that the link tool in the basic text editor takes the librarian to a search interface to all the links in the database. So an existing link can be added (and is therefore recorded once, used multiple times). New links can be added if the link is not already in the database.
Since the site is modular, it is easy to replace functionality. Google Calendar could replace the current events tool. One staff directory could supplant another.
Next Steps
It needs an API — badly. Both to integrate content into external sites and to improve internal AJAX content which will run much faster via API than via direct database query. While images and video can be uploaded easily, it’s not easy to get them into a text block, for example — so this part is only half done. Integration with WorldCat — put bibliographies from WorldCat into a page.
Staff interface is very personalized. User interface is not, yet. A main impediment is that university information systems do not offer easy ways to get data about students (role, major, etc.) Bring federated search results into context of web site.
Questions
Q: How does this work with accessibility?
A: The site, as seen by the public, is very accessible. The staff interface is not accessibility compliant yet — nor is it cross-browser compliant (FIrefox only).
Q: Can you talk about use cases for the API under development, and demand?
A: The first use case is internal users — to make current actions based on database connections will be faster via an API. Also, want to be able move things between Intranet and public site — some content belongs in both places. Desire to put library content into University web site. Courseware is difficult because UH is a WebCT site and that’s not particular API-friendly. An API would make building applications for mobile devices easier.
Q: Could you talk about development effort?
A: Been in the works for about 3 years. It’s written in Cold Fusion. This was because old site was in that, and they didn’t want the site frozen. They could replace parts as they went along. One developer FTE for one year built it; they now have two developers working on it.