Great digital collections site from Duke

My favorite digital collections site is from Duke University Libraries: library.duke.edu/digitalcollections/ Beautiful design and so easy to dive effortlessly into the content.

Home page (click to embiggen)
Home page (click to embiggen)
Item detail page (click for large)
Item detail page (click for large)

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.)

Well done, Duke!

Wearable tech

My UP wristband

As sensors become cheaper and more prevalent, we’re beginning to collect more data from our own movements and the objects around us. Moreover, it’s becoming a less geeky thing to do! I’ve been thinking a bit about how we can use wearable tech for library-specific purposes.

Examples of current or upcoming wearable technology:

  • Google Glass, which others have talked about using in the library for various purposes
  • MYO armband: I’ve preordered this based on their first 3-minute video alone. So far my only library use cases are wowing people during presentations and confounding colleagues by turning their ebook pages from across the hall
  • Pebble Watch: Kickstarter-famous epaper watch connects to your smartphone; first reviews range from good to just okay. Primarily for notifications and activity-tracking, but other uses will reveal themselves when the SDK is released
  • Any others?

Other examples of wearable tech for personal use:

  • Jawbone UP wristband: sleep & activity tracking; I use this and like it
  • Nike FuelBand: activity tracking
  • Sound-activated T-shirts, available at any street fair, strictly for goofballs

Article of interest: 9 trends to watch for in wearable tech

Drupal’s WSoD (White Screen of Death)

5:50pm, Friday

One Friday night a few weeks ago, all was peaceful here in the library. Everyone else had left, the lights were dimmed, and I was wrapping up a few last things before heading out to my weekend. I had done a few tweaks to the site’s dropdown menu CSS, and as I put on my scarf and coat, I casually pushed them from our development server’s Git repository to our remote master repo, then pulled the commits down to our production server.

I reloaded the library webpage.

It had gone completely blank.

As the panic slowly seeped into my bloodstream, I reloaded again and again, even looked at the source code — nothing, not even a space or error message.

Reverting

I had never rolled back any changes before, and the Git cheat sheet I have tacked to my wall didn’t  have enough information about undoing mistakes to make me comfortable about rushing off a command. I called our Drupal consultant, who answered his cell phone while driving and spoke in a calming voice about how this is why we use version control, just revert to a safe commit, and it will all be okay.

Our commits are logged and easily readable in an Unfuddle project, so I peered at that and picked out what I knew to be the previous, safe commit, and entered this commend:

sudo git reset --hard 5154951c5a3a6a9211ba68268c6159c51cdb5f58

Every StackExchange thread featuring this command also included dire warnings that had previously frightened me away from using it, but if you really do want to wipe out changes in your local repository (in this case, whatever had just been pulled down to our production server), this is how you do it.

The site came back up as it had been before, after maybe five or ten minutes of downtime. I breathed a little easier and left for the weekend.

Investigating

But why had it gone blank? This was what I had to look into when I got back. If I pulled the most up-to-date commits down from the remote repo again, the site would still blank out. (I knew because I tried, hoping the WSoD had been a fluke. It wasn’t.) There were 60 changed files in the commit, mostly CSS, PDFs, and files for two non-essential modules. Even weirder, why was the up-to-date dev site totally fine? Until we fixed whatever was wrong on the production site, we’d have to pause development.

Drupal’s help pages have a list of common problems that case the White Screen of Death. It’s thorough but not complete. We went about troubleshooting at times when site use was low, so a few seconds of downtime wouldn’t be too disruptive. We still couldn’t tell if it was a server problem or something in those 60 files, so we started with these:

  1. Out of PHP memory?
    • Already at 128 MB, double recommended amount
  2. No more space on virtual machine?
    • Have around 30 GB left, not the problem
  3. Restart production server?
    • Pulled from remote repo, then restarted server, still WSOD
  4. PHP execution time limit too low?
    • Dev is 600 seconds, production is 30; changed to 600s, still WSOD
  5. Change settings file to display error when site goes blank after pull
    • Message on blank site: Fatal error: require_once(): Failed opening required ‘…/sites/all/modules/admin_menu/admin_views/plugins/views_plugin_display_system.inc’ (include_path=’.:/usr/share/php:/usr/share/pear’) in …/includes/bootstrap.inc on line 3066

This error matched our server logs and Drupal error reports. The file that required opening had been deleted in the toxic commit, but at first it didn’t seem like that would be the problem. The Admin Views module is only visible to logged-in administrative users who want a more tricked-out menu bar at the top of their screens — why would it bring the site down?

In exasperation, I disabled the Admin Views module and tried again to pull down — and voilà, the site was still there, updated, and looked fine. Apparently, that was all I had to do: turn off the module causing problems so the site code wouldn’t quit out on me.

If it were a more essential module (not just one for a few admins’ convenience), we would have had to look into this issue further. For now, having caused enough headaches for myself, I’ll leave well enough alone.

Related post:
Using Drupal and Git for a library website

From Wikipedia to the Lloyd Sealy Library

This is an article I wrote for Lloyd Sealy Library’s Spring 2013 newsletter.

From Wikipedia to John Jay

Guiding researchers to our resources from within Wikipedia articles

In March, a blog post by John Mark Ockerbloom circulated virally from librarian to librarian. The title, “From Wikipedia to Our Libraries,” describes typical online research:

The pattern of quick online information-finding using search engines and Wikipedia is well-known enough that it has its own acronym: GWR, for Google » Wikipedia » References. … It’s less important that our researchers start from our libraries’ websites than that they end up finding the knowledge resources our libraries make available to them. Looked at the right way, Wikipedia can be a big help in making online readers aware of their library’s offerings.

He goes on to explain the Library Resources template he made for use within a Wikipedia article that automagically points users to relevant resources in their local libraries and around the world. (Look at Flannery O’Conner’s page to see an example.)

As a regular Wikipedia user and editor myself, I strongly agree with Ockerbloom’s sentiment. Wikipedia, launched in 2001, is a robust beginning resource for many subjects, and you’d be hard-pressed to find anyone on a college campus who doesn’t use it with some frequency. In the site’s infancy, libraries tended to rail against Wikipedia, citing bad information and lack of expert editorship as its primary evils. But even as early as 2005, prominent sources like Nature began to conclude that Wikipedia had grown to be just as accurate as the print encyclopedias lining library walls (source). The difference, though, is that Wikipedia has 4.1 million articles in English (25 million total), more than any traditional encyclopedia can hope to have, and it’s used far more than any other beginning resource.

We can safely assume that Wikipedia is one inevitable resource for the college student, the curious passerby, and the expert researcher alike. Researchers at Project Information Literacy found that 82% of college students consult Wikipedia when working on a research project (source). The site is a starting point that can be a stepping stone toward deeper research. We information professionals have a responsibility to point interested readers to more exhaustive, credible resources—including our own. We can do this within Wikipedia in any given article by citing good related resources and unique materials held in our libraries and archives.

At John Jay, we are fortunate enough to have many rare and unique materials in our Special Collections, ranging from the records of the Mollen Commission (1990s investigation into NYPD corruption) to the personal papers of Richard Louis Dugdale (19th-century sociologist famous for studying the “Juke” family). For those collections whose finding aids or descriptions are completed, I have noted the availability of these materials in the relevant Wikipedia articles, including links to pages from the Library that give more information on the subjects. In this way, we can easily promote our materials and our scholarship on a high-visibility, high-traffic site.

For example, on William C. Dodge’s page, I have added (as of April 2013):

Dodge kept scrapbooks throughout his life documenting his career and personal interests. These scrapbooks are housed in the Special Collections of the Lloyd Sealy Library at John Jay College of Criminal Justice. Included in the Dodge Collection are materials related to his campaign and clippings from New York City newspapers that documented local crime at the time.[2]

The citation links to the Library’s finding aids page:

[2] “Manuscript Collection.” Lloyd Sealy Library Special Collections, John Jay College of Criminal Justice. Retrieved 5 March 2013.

This work is an ongoing process. Our hope is that more researchers will discover our extensive collections. We continue to add links to relevant Wikipedia pages as we review and receive more materials.

In addition, we’re proud to say that we are the first CUNY library to have its own Wikipedia page. Using material from Gerald Markowitz’s chronicle of John Jay College, Educating for Justice, and Prof. Nancy Egan’s rich history of the Library, the article describes our collections and services, in addition to our former and current facilities. Within hours, the page had already been improved by people unaffiliated with John Jay and by Wikipedia’s bots—both indicators of Wikipedia’s dedication to increasing quality.

In the interest of continuing to harness Wikipedia for the good of the research community, consider these questions:

To other CUNY librarians: Which special collections and unique materials do you have that you can link to from Wikipedia? Does your library need its own Wikipedia presence?

To other faculty members: What specialized knowledge do you have that you can contribute to Wikipedia?

To everyone: If you’re not a Wikipedia editor yet, you should be! If you’re a woman, I encourage you doubly: a 2011 Wikimedia Foundation survey found that only 9% of contributors identified as female, indicating a problematic perspective bias. Getting started as a Wikipedia editor is easy. Contributing can be as simple as correcting one punctuation error or as involved as creating a whole new article from scratch. Writing for Wikipedia may be challenging at first as you learn its etiquette and adopt the encyclopedic tone, but it’s surprisingly addictive—and rewarding.

Psst: this Friday, April 26, 2013, 1-3pm Eastern, join the world in the Global Women Wikipedia Write-In, “designed to encourage internet users to write entries about women from around the world into Wikipedia and to improve existing entries on these topics.” I’ve begun early by writing about Jane Grant!

___________________________________________________

References 

Using Drupal and Git for a library website

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.

Code

  • theme files (CSS, PHP, INC, etc.)
  • the out-of-the-box system
  • all modules
  • any core or module updates (do on dev, push to production)

Content

  • anything in the Drupal database:
    • written content (pages, blog posts, menus, etc.)
    • configurations (preferences, blocks, regions, etc.)

Here’s our workflow:

Git and Drupal workflow diagram

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.

Any Drupal/Git workflow tips?