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!