John started off by showing two older versions of Ann Arbor’s website (via the Wayback Machine, I think) [Dave's aside - my but haven't we come far in 10 years!].
The previous version of their site used Userland/Frontier as a CMS. It was a proprietary, closed system.
Their current design started out with the library redesigning their whole network infrastructure. Cool. They decided to use open standards whenever possible.
Choosing a new CMS:
- made an informal list of requirements
- Wanted it to be LAMP based
- Extensive API
- Easily theme-able – in order to work with external web designers
- Blog-based technology
- 100% modular
- Excellent API – Drupal is an API-Centric Project
- Large user-base
- very active project
- taxonomy based organization
- bloggable – comments, rss, etc
They had over 2000 registered users (username/password) within the first couple of hours of releasing their new site.
- ability to cross-post blog entries inside multiple taxonomies
- configruable interwiki links to catalog items, wikipedia, wherever
- you can browse events by location, type (storytime, lectures), subject, and age
They have rss feeds of holds and checkouts in their my account page
Does this new apprpach work?
- teens love it!
- I asked later, and adults like it and leave comments, too – just not as muc as the kids.
III has a patron API – it returns patron info.
Catalog – taking it apart
- turned into a n applciation server
- all non-essential html was stripped from the screen files
- unnecessary options were removed
Client URL – allows software to communicate with many different types of servers using different protocols
- PHP has native libcurl support
Result – the Wrapper
- they can get and update patron information, run catalog queries,etc
- Then they integrated Drupal through API
His Beef: they shouldn’t have to do that! Automation vendors should supply APIs!
Gaming – they have an advertisement at the theater – it shows live scores at the theater from the gaming going on in the library. Amazing!