A brief technical primer on Stanford's new library website

The Stanford University Libraries recently launched a redesign of its main library website at http://library.stanford.edu.  This is a Drupal 7-based site hosted on Pantheon.

In the future we hope to document more thoroughly the technical approaches we took on several bits of the site, but for now I'll summarize a few of the features this community might be interested with a brief summary of the technical approach taken for each. In no particular order:

* Shibboleth: User accounts are generated via Stanford's WebAuth authentication system through Shibboleth.  We used the simpleSAMLphp module to implement Shibboleth on Pantheon.

* Integrated Search: (http://bit.ly/QkLOgz) We use a "bento box" style of search results, inspired heavily by our peers at NC State University Libraries .  The Drupal search uses apacheSolr, and populates one pane of the search results with a "see all results" link that displays results with facets.  The other panes are populated by results generated via our SearchWorks API (basically a solr-based search API implemented as part of our Blacklight-based discovery environment). Links from these panes take users out of Drupal to SearchWorks results.

* Library Hours: (http://bit.ly/QkLPkF) This one got quite involved as we re-engineered all aspects of our library hours workflow, from the way in which branch libraries provide their hours for the website to the way in which they are displayed.  On the back-end there is a SQLite database that contains hours information for all libraries and individual service locations.  This is populated by an import of spreadsheet data for each library and location.  Feeds are created from the SQLite database that are imported into Drupal via the Feeds module, and an individual node is created for each day-location combination.  Some complex views requiring quite a bit of pre-processing were built to represent the hours in different ways.  As a side note, we also created a separate library hours REST API that uses the same hours data and can be used to feed other Drupal and non-Drupal applications.  We hope to have this documented for others to use soon.  

* People: (http://bit.ly/QkLRsz) Stanford University has a central LDAP directory, but in our older static web site we asked library staff to maintain a second, separate directory entry. This resulted in the two directories getting out of sync quickly and became a management nightmare for many.  In our new site we create a feed from an LDAP query for core contact information like name, phone and email. This feed is imported to create new People nodes in Drupal for all staff.  Library staff can then augment their People nodes in Drupal with biographical information, pictures, and other data not part of the LDAP feed.  If they need to change their name, email or phone, they change it once in the main Stanford directory, and the nightly feed update will change these data in the Drupal node so that they only need to maintain that core information once.

* Course & Topic Guides: (http://bit.ly/QkLU7T) Finding the right guide technology has long been a struggle for us, as it has been for many.  We had been using LibGuides, but wanted our guides more tightly integrated into our site.  Ease of content creation was an important goal for the guides environment, as was link management and the desire to be able to add data to guides from many sources.  We built a content type that relied heavily on Panelizer and the Panels In-Place-Editor (IPE) to make the guide creation process more friendly.  We built several fieldable
panels panes, which we call widgets, to add content from our catalog (again using the SearchWorks API), RSS feeds, image galleries, embeddable widgets, WYSIWYG content and more.

* Branch Microsites:  (http://bit.ly/QkLYo2) Stanford has 14 branches that need the ability to create their own sites within a site.  These microsites needed some independence in information architecture and content, while still fitting into the IA of the main site, with consistent look and feel and navigation.  We built a content type that used the Book module to support sub-navigation, again relying heavily on Panelizer and the IPE to make it easy for branch librarians to build content and feature-rich microsites.  Most of these sites are still in development (not part of the initial launch), but you can look at library.stanford.edu/music for an example.

* Chat: We are using libraryH3lp for online chat reference.

We conceived of and built the site over an 18-month period, with engineering support from Chapter Three.  Throughout the design and implementation phases we relied heavily on an ongoing program of user research and user testing.  Some of this is recounted in our blog at:  http://library.stanford.edu/blogs/library-website-redesign.