ECHO Blogging Central

It’s not everyday that Cliff Lynch and Dan Cohen are in the same city, let alone at the same meeting. But yesterday New York was lucky enough to have both of them in town for a one day workshop Digital Dilemmas hosted by the Metropolitan New York Library Council in association with OCLC.  If you’ve every heard either of them speak you’ll know what I mean.

Cliff began the day with a birds-eye-view of the challenges in the current digital landscape - a sort of tour de force for librarians deeply entangled in the day to day struggles of information management. As usual, the 45 minutes seemed like 10 and was chocked full of Cliff’s special blend of data, anecdote and insightful allusion. He advised the audience members to think broadly about our respective vocations in relation to the communities we serve and to not reduce the discussion to the mechanics of digital activities. Libraries, he remarked, are an integral part of,  and partner with their constituents and their constituents are members of a greater society. The society is changing. Learning and education are changing and consequently, the place for libraries in the society is changing.

Dan Cohen who rounded out the day, had a similar message but delivered in an entirely different manner. Dan conducted an experiment (crowdsourcing) to demonstrate information seeking behaviors and information retrieval behaviors. Dan posted an image of an artifact on Twitter and asked those who were following him whether they could identify the object. He then turned back to his presentation. Shortly after, the Twitter dialogue box kept popping up to interrupt him. His “followers” were responding. By the time he had finished discussing the ideas of the “open library” - a virtual environment where library activities occur outside the formal, professional structure - he had made his point.  The community had participated in creating new knowledge and had done so in an interactive and sometimes noisy fashion.  Dan’s point wasn’t that libraries are obsolete but that libraries and librarians must engage with their communities in the places that knowledge is being acquired and since knowledge acquiring behaviors are changing, libraries and librarians must change.

This is hardly bleeding edge ….. but  it does warrant repeating since it reminds us that we must remain interested in the big picture as well as the minutiae. Our communities would be well served if we imagined ourselves as partners in this endeavor rather than an endangered species.

Whatever your opinion, it is well worth checking out the meeting proceeding that will be posted shortly.

Kudos to Jason Kucsma Digitization and Emerging Technologies manager at METRO for putting this together.

We’ve reached a milestone in our list of Basecamp projects. 65 projects!  And, we have more in our queue that have been submitted but not approved.

Over the past few months, we’ve developed a process for managing the flow of projects that we are working on to be submitted, approved and documented.

We start with filling out a project submission form with information on the deadline, project owners and a brief description of the project requirements.  Once the project has been reviewed and approved, we assign an alphanumeric code and it gets promoted to Basecamp.  We have the following codes:

• I for Internal sites and applications  (such as the staff intranet)
• D for sites and applications used by the Digital Experience Group (such as our project submission form built in Ruby on Rails)
• N for public Nypl.org sites and applications
• V for audio/Video projects
• E for Externally hosted sites (such as Flickr)
• S for other Screens (such as information screens in library locations)

As of our last count, we have 41 projects filed under the letter N.  The biggest project is N0004, the nypl.org redesign project.  N0004 has 17 sub-projects.  We divided the redesign work into specific aspects to include content development, theming and configuration, redirects, third party applications, archival collections, blogs, taxonomies, events, locations.  Some of the sub-projects are very small, but didn’t fit anywhere else, like implementing the Qwidget application on the site.  And, some of the sub-projects are quite large in scope, such as Search, which is dependent on the Solr indexing projects and the new library catalog.

To paraphrase one of my colleagues, soon we may have more projects than library locations!

OK, so Stat of the Week has returned! Can we just agree to pretend those twelve skipped weeks never happened? Thanks.

Recently, the Digital Experience Group gave a presentation to the occasional meeting of our Site Managers, the people who run each of our branch libraries. These are the people who work every day with our patrons, help them with their requests, and get them situated on the computers. They know the NYPL patron as well as anyone. We asked this group, “What do you think the most frequently searched word on the NYPL web site is?” We got a lot of good guesses: “Jobs”. “DVD”. “Books”. “Hours”. “Classes”. “Late fees”.

Good guesses all. Many of these searches are definitely in the top 25 or so on a regular basis. But over the past year, one search term has consistently occupied the number one spot, and not by a small margin. I mean, we’re talking a 1996 Chicago Bulls level of dominance. That term is…

Tumblebooks.

When we revealed that answer to the site managers, the reponse was an audible “Huh?”

Tumblebooks are animated storybooks for children. They’re built and maintained on a third-party web site, but they’re there, free of charge, to anyone who visits via the web site of a participating library (like the NYPL). The site managers knew that they were very popular. But the number one search term? Consistently? Really? Yes, really. And they could be even further in front; as you can see from the screenshot above, the third most popular search term is “tumble books” as two words!

I’m not quite sure how Tumblebooks got so popular. Are they promoted in the schools? Great word of mouth? Did Oprah say something nice about them? I really don’t know. Feel free to comment if you can cast some light on the mystery.

Regardless, I love the unexpectedness of this discovery, and the popularity of Tumblebooks has some lessons for us:

1. Don’t make assumptions. As the Site Managers’ meeting showed, we probably could have interviewed every member of our front-line staff and never had anyone bring up Tumblebooks as a top priority for navigation. But in the quantitative statistics, there it is. We should never assume we know what’s getting a lot of traffic based on “common sense” without verification.
2. The popularity of content can lead to insights about audiences. We might not be able to interview every single patron as they arrive on the site, but since our most popular search is for animated storybooks, we can probably infer that there’s a big audience of parents looking for good content to keep their children occupied. We already sort of knew that, but you can be sure we’ll be trying to figure out if the web site has a higher percentage of young parents in its audience than the physical libraries. Are stay-at-home moms using the web site to avoid dragging the kids to the library? Should we be increasing the amount of kids’ content on the site? All sorts of good questions start to flow.
3. If someone’s doing a lot of searching for an item, we might want to make better links to it. The Library’s link to Tumblebooks is not terribly hidden; it’s on the “Books and Materials” page, which is already one of the top 5 most popular on the whole site. But even though it’s only a single click away from the home page, enough visitors miss it and resort to search that we might want to take a look at how the links are presented. And in fact the current Books page is a bit of a mess, with a lack of clear hierarchies. The number of “tumblebooks” searches is evidence of a design that’s not working.
4. Search terms reveal context. A search for “tumblebooks” clearly marks the user as a child or someone who’s caring for a child. When we return this search result, not only should we be returning the Tumblebooks link as the first result, but we should be suggesting secondary links to children’s programs, other online storybooks, etc. Our upcoming search redesign (much more on this in future posts) will take this notion into account.

Finally, the popularity of Tumblebooks itself is instructive. It’s a really good web site. Once you follow the link from a library, it’s simple to find a book, it downloads quickly, the usability is excellent (as it should be when your target demographic is four years old), there’s no login or other restrictive administrative overhead, there’s a great variety of storybooks and the content is fun and engaging.

There’s something to be said for design so simple a four-year-old can grasp it intuitively. It’s not an easy trick to pull off.

The New York Public Library is updating its earlier request for the development of widgets for our homework resources (posted Feb. 27, 2009).  Rather than building several widgets at all at once we’ve decided to simplify the process and build them one at a time, learning from the successes and problems of each before we build the next.   Our first widget is going to be a List Building Widget that will include platform integration for iGoogle, Facebook, MySpace, blogs and web pages, and/or desktops.    The widget will allow users to:

• Build lists of favorite book, movie, music, game, etc. lists
• Build lists of materials needed for homework projects
• Share lists with friends

We are looking for open source designs that can be made available to and repurposed by other organizations seeking to engage young people. The widgets will be developed as part of a 2008 National Leadership Grant from the Institute of Museum and Library Services titled Homework NYC Widgets: A Decentralized Approach to Homework Help By Public Libraries.

Read the RFP.

The project team will accept and answer questions about the proposal via comments on the NYPL Labs blog.  Proposals for the List Building Widget should be sent as an email attachment to Josh Greenberg, Joshua_Greenberg@nypl.org,  by May 1, 2009.

As you may have heard, we’re currently in the process of redesigning NYPL.org from the ground up - a huge undertaking that seems to get bigger the deeper we get into it. We in the UX team have taken the redesign as an opportunity to implement new guidelines for best practices in web design that will be used as standards in future projects. The purpose of these guidelines is to provide a consistent experience for all users regardless of platform or browser capabilities, while ensuring that the site is flexible enough to incorporate new features and functionality in the future.

Here is a quick overview of some of the new guidelines we’re putting in place:

XHTML 1.0 Strict will be the standard Document Type Definition for all generated web pages, and all pages should validate. All content will be structured using semantic XHTML markup, with layout and presentational properties specified in external CSS files (see below). Presentational markup (e.g. use of <b>, <i> <u>, etc.) will be avoided. Class and ID names applied to content elements should be descriptive of the element’s function and not specific to presentational attributes (”title” or “subtitle” rather than “bold” or “red”).

All CSS rules will be defined in external files – use of embedded and inline styles should be avoided where possible. To best support users accessing the site with Internet Explorer 6 (currently about 25-30% of our overall traffic), use of CSS2 and CSS3 selectors and declarations will be avoided where practical as these are not supported in IE6. CSS2/3 can be used to enhance certain aspects of the design for browsers that support it, but care will be taken that the overall design and user experience is not significantly compromised in IE6. Browser-specific rules and hacks will be avoided whenever possible.

Javascript will be utilized only in cases where its use provides a significant improvement to the user experience. Where it is used, Javascript should be unobtrusive, with scripts contained in external files and implemented in such a way that there is no loss in basic functionality for users with Javascript disabled.

Many of the guidelines above, in addition to representing best practices for web development, also serve to ensure that the web site is accessible to users with disabilities. Our goal is to fully comply with Priorities 1 and 2 of the W3C Web Content Accessibility Guidelines. In this effort we are fortunate to have the input of the staff and patrons of the Andrew Heiskell Braille and Talking Book Library, who have provided very useful insight into practical issues faced by users who rely on screen reading and enlarging software to view web content. While the W3C guidelines are important, having insight into real user behavior is invaluable.

There’s been a trend in web design over the past few years towards increased usage of Javascript. For you non-techies in the audience, Javascript is a “client-side” programming language, which means it’s used to write small programs that run on your computer when you load a web page. The “your computer” part is the important bit; it makes it possible to do some complicated manipulation of individual parts of a page without having to reload the whole shebang. Google Maps is the classic Javascript experience. You load one map, and as you pan around it loads just the new map images you need, adding them to the edges.

The upside of Javascript (and client-side programs in general) is a better user experience, with quicker responses to user input (both real and perceived). There is a downside, however, in that these programs run on the client’s computer, and everyone’s computer is different. It’s even possible (albeit rare) to turn off Javascript entirely.

We’ve been hearing the siren call of new Javascript features on our upcoming NYPL redesign, but before we can even evaluate a strategy for using it, we need to know how many of our users can’t see Javascript at all. This is trickier than usual; ordinarily, we would just head over to our statistics program, Google Analytics, and loook up browser information. Sounds easy, but Analytics uses Javascript itself to report stats! So not only is it helpless to answer the question, but also its stats are underreported by the number of non-Javascript users. So there’s another reason we need to investigate.

Fortunately, a little hacking and some spreadsheet work has given us a better answer. There’s a <noscript> tag in HTML that automatically serves up alternative content for browsers that don’t use Javascript, so for a couple of days this we we added a <noscript> tag to our home page containing a link to an tiny image on a different server. The image was just a single pixel, and of no importance, but we were able to comb through the server logs and find requests for that image, giving us the number of users whose browsers tripped the <noscript> code.

So here’s the number: Out of 23,704 total pageviews, 893 had no Javascript enabled, or 3.76%. If we remove those who looked at the home page more than once and look only at unique pageviews, the number drops to 374 out of 19,350 unique pageviews, or 1.93%.

That number might still not be perfect. There are many “robot” and “spider” programs that automatically visit web pages, and these usually don’t have Javascript turned on. Therefore, a good chunk of that 1.93% potentially doesn’t even have a human on the other end. But spiders usually don’t load images either, and our little test used an image load as the trigger. Jut to be safe, I ran the results through a list of known spider Internet addresses. It only flagged one or two.

So assuming that number’s relatively solid, we have 98% of our users with working Javascript. That’s great, right? Well, that non-script two percent still accounts for 1 out of every 50 of our users. So whatever new features we put in place, we should still make sure that they are enhancements to the experience, and not a necessary piece of the navigation.