I usually hate seeing social media on digital collections pages, because how disheartening to see 0 likes, 0 tweets, 0 comments on most of your items. But for promoted collections, like their Historic American Sheet Music, I was surprised and impressed to see some community participation.
I wonder how they assign subject headings. Some look like LCSH (abundance of dashes) and some seem more like tags. The subjects link to other items in their catalog, which is useful, although it takes you out of the Digital Collections site experience.
According to their About page, the application was built in-house using Django and a good number of tools and widgets. (I usually use BuiltWith to get a behind-the-scenes peek at a site’s architecture.)
The Lloyd Sealy Library website uses Drupal 7 as its content management system and Git for version control. The tricky thing about this setup is that you can keep track of some parts of a Drupal site using Git, but not all. Code can be tracked in Git, but content can’t be.
theme files (CSS, PHP, INC, etc.)
the out-of-the-box system
any core or module updates (do on dev, push to production)
Code: Using Git to push code from dev to production is pretty straightforward. I was a SVN gal, so getting used to the extra steps in Git took some time to learn. I used video tutorials made by our consultants at Cherry Hill as well as Lynda.com videos. (For those new to using version control, it’s a mandatory practice if you manage institutional websites. Using version control between two servers lets you work on the same content simultaneously with other people and roll out changes in a deliberate manner. Version control keeps track of all the changes made over time, too, so if you mess up, you can easily revert your site back to a safe version.)
Content: Keeping the content up to date on both servers is a little hairier. We use the Backup and Migrate module to update our dev database on an irregular schedule with new content made on the production server. The only reason to update the dev database is so that our dev and production sites aren’t confusingly dissimilar. Additionally, some CSS might refer to classes newly specified in the database content. The schedule is irregular because the webmaster, Mandy, and I sometimes test out content on the dev side first (like a search box) before copying the content manually onto the production site.
Why have a two-way update scheme? Why not do everything on dev first, and restore the database from dev to production? We want most content changes to be publicly visible immediately. All of our librarians have editor access, which was one of the major appeals of using a CMS that allowed different roles. Every librarian can edit pages and write blog posts as they wish. It would be silly to embargo these content additions.
Help: A lot of workflow points are covered in Drupal’s help page, Building a Drupal site with Git. As with all Drupal help pages, though, parts of it are incomplete. The Drupal4Lib listserv is very active and helpful for both general and library-specific Drupal questions.
Non-Drupal files: Lastly, we have some online resources outside of Drupal that we don’t want clogging up our remote repository, like the hundreds of trial transcript PDFs. These aren’t going to be changing, and they’re not code. The trial transcript directory is therefore listed in our .gitignore file.
If you haven’t done a usability test on your library’s online services in the last 12 months, you’re overdue! Web trends and user expectations change at a fast rate, as do the many parts of a library’s resource ecosystem. Before rolling out the new Lloyd Sealy Library website in December, I conducted a usability test on the beta version of the site in November. The feedback from students and faculty was helpful in refining parts of the site that weren’t as usable — in areas that were already of concern to us and in places we didn’t know were problematic.
There are a bundle of resources out there for usability testing, but not many example scripts specifically for library websites. Below are the scripts I used for students and faculty. Note that this is tailored to John Jay College’s Lloyd Sealy Library website, so some tasks might not be phrased the same way or even performed on your site. At the bottom of this post, I’ve included some notes about this usability study and my approach.
In designing the new Lloyd Sealy Library website, I used Balsamiq, a sketchy wireframing tool, to plan page layouts, information architecture, and user flows. I like the sketchiness particularly. Too often, group-approved design gets bogged down in colors and fonts, but charmingly drawn mocks like these free your conversations from the details so you can focus on the important elements of user experience.
Here’s a real mock I used to design a page on a forthcoming project (click for larger):
I use the desktop software ($79), but there’s also a cloud-based web app ($12+/mo), which is amazingly well done. There are some very nice touches, like the kinds of items you can drag ‘n’ drop to create your mock, the auto-filltext that appears when you type ‘Lorem,’ and the ‘What should I make for dinner?’ option in the Help menu (really). It’s not the speediest tool, but I have found that added friction allows time for you to really consider what you’re designing. Perhaps William Morris phrased it best: “You can’t have art without resistance in the materials.”
We use Drupal 7 as the CMS behind our library website. It’s robust and flexible, but has a notoriously steep learning curve on the back end. One thing we struggled with at first was how best to direct our users to the databases they have access to. (At this time, CUNY doesn’t have a discovery layer, so students must find articles by choosing a database first and searching within.)
Making a good directory for our 200+ databases required getting familiar with Content Types (specifying categories of content, like ‘database’ or ‘blog post’) and Views (how these fields are presented, like displaying a URL as a link). When you make a new content type, behind the scenes, Drupal adds more tables to its core database, where every field you pick is a column and every piece of content you add is a row.
The full page of our database directory looks like this:
Each database we subscribe to has its own row of information and links, like this: