An interesting New York Times story with a weak headline gave me a great opportunity recently to use my Twitter skills to tell the world about the story. In addition, the way my tweet was retweeted is a good secondary story, being an example of balancing Twitter retweet-etiquette with other priorities.

The screenshot at left shows a “what’s wrong with this headline” view of the story. The headline, as I’ve indicated with my highlighting, misses many of the important points of interest in the article, in my view.

The biggest problem with the headline is the dull, overused term “big data.” Apparently this is used to indicate the “12 million” items that are mentioned in the lead paragraph. But the “big data” concept has been used so broadly that “big data for books” could mean many things, from full-text to circulation. So I say mention the eye-catching “12 million” in the headline.

Admittedly, I may be library-biased, but I think it’s important to many people, not just librarians, that the library is centrally involved in this project. So the headline should say “Harvard Library” instead of “Harvard.”

Finally, the word “metadata,” which is used prominently in the story. Again, maybe it’s my librarian-centric view, but I think the term has become important for many people outside the library world, and would merit inclusion in the headline.

So, with the criticisms above, I “enhanced” the NYT headline in my tweet:

My enhancements worked — The tweet got several retweets. The way the retweets came is an interesting story in itself. My tweet was retweeted by Mathew Ingram, a prominent tech industry writer who I’m honored to have as a Twitter follower, and who has many more followers than I do. So I’m always glad when he likes one of my tweets enough to retweet it:

It’s clear that he got his tweet from mine, from the wording, which was original with me, and because he used the same bitly URL that I used. Usually his retweets follow the usual retweeting protocol of mentioning my Twitter name. But in this case he didn’t, because he wouldn’t have had room to include that and also the “pretty cool” comment he added at the head of the tweet. He no-doubt judged that adding his endorsement would draw attention to the tweet, and make people click it and retweet it, which is FINE WITH ME!

Priorities and the Art of Tweeting

The wider lesson here is that much of the skill of using Twitter is thinking about priorities. The 140-character limit on Tweets imposes a strict discipline, which requires constant consideration of “What’s important to include?” – Is it more important to give full credit to the writer of a tweet, or author of an article being linked, or is it more important to include a comment or a good quote from the article being tweeted that will draw traffic?

This all makes me think how far the fluid process of tweeting is from library book cataloging (that I experienced briefly in my early career), in which the catalog card is created from the title-page of the book according to strict rules. The only strict rule in Twitter is the 140-character limit — Within that, the canvas is empty, open to anything!

Eric Rumsey is at: eric-rumsey AttSign uiowa dott edu and on Twitter @ericrumsey

Before Google, search engine builders thought that the way to organize the Internet was like an index, or, to use the term that was popular at the time, a directory — A giant list of every link on the Internet. Librarians saw a place on this wave also, as Steve Coffman wrote recently:

Remember those heady early days when we thought we were going to catalog the web? …  Almost every library felt the responsibility to stuff its website with long and often elaborately annotated lists of web resources for just about everything.

As Matthew Reidsma says, the list-making urge is still much in evidence on library websites:

Libraries love links so much that most [library websites] look like spam link farms, designed to trick Google. Every other successful website on the planet gave that up in the late ’90s, but not libraries. We librarians like to see a big list of resources because it makes us seem more relevant.

As Reidsma has discussed in other works, the problem with the prevalence of link lists on library websites is that users ignore them, and don’t find the really important things on the website … or they just go to Google.

Why do users find library lists so unappealing? Neither of the commentators quoted above, nor anyone else that I’ve seen, has written about it, but the obvious answer, I think, may be … Alphabetical Order — Invariably lists of links on library sites are alphabetical — In the days of PageRank, how boring!

The “I’m Feeling Lucky” PageRank Revolution

Before Google, the only rational way to organize a long list of links on the same subject was alphabetical order. It’s almost hard to imagine back to those days, and to realize what a revolution Google’s PageRank was. It seemed like magic that Google gave us automatic lists of links, with the best ones at the top of the list. James Gleick wrote about this recently, in a retrospective look at the Age of Google [boldface added]:

PageRank is one of those ideas that seem obvious after the fact. But the business of Internet search, young as it was, had fallen into some rigid orthodoxies. … People naturally thought of existing technologies for organizing the world’s information, and these were found in encyclopedias and dictionaries. They could see that alphabetical order was about to become less important, but they were slow to appreciate how dynamic and ungraspable their target, the Internet, really was.

With this great new invention of PageRank, people soon came to assume that any list of resources worth looking at would, of course, have the best links at the top of the list. If they encountered an alphabetical list, their eyes would glass over. So, with most long link-lists on library sites being in alphabetic order, is it any wonder that they’re not very popular with users?

So what can libraries do? As Reidsma has been saying recently, we need to look at our websites like our users do, and change them to fit users’ needs — He says from his work with users surveys that this means greatly simplifying library websites. Link lists should be short, with someone’s idea of the “best” links at the top. As I’ve learned with my work on Hardin MD, no matter how long the list of links is, only the top 2-3 will get many clicks.

The emphasis on simplifying our websites, of course, fits very well with the mobile revolution. The small screens of mobile devices beg for small, simple web pages, and trimming our lists is a great place to start.

Eric Rumsey is at: eric-rumsey AttSign uiowa dott edu and on Twitter @ericrumsey

Matthew Reidsma gave a presentation recently with the provocative title Your Library Website Stinks and it’s Your Fault [abstract]. In combination with that, he also wrote an article on the same theme, Bad Library Websites are just a Symptom. I’ll mention briefly some of the points that he made, but the main idea I want to stress here is that Reidsma has an answer to the problems he details with library websites, namely Responsive Design.

Reidsma’s predominant theme is that the way to build good websites, including library websites, is to listen to our users. Users think differently from us, so we need to spend a lot of time doing usability studies of our web pages. From usability studies at his library, Reidsma says that the overriding lesson he’s learned is that users want simple web pages — A big, fat, Google-like search box, with just a few good links.

Responsive Design

Serendipitously, about the same time I came across Reidsma’s ideas on library websites, I was reading about Responsive Web Design (RWD), a recently innovated way to make web pages so that they look good on any size screen, from smartphone to desktop. This requires that the basic page contents be fairly simple, and goes along with the “mobile first” idea that pages should be designed first for small-screen viewing.

I was becoming interested in RWD especially because our library is working on implementing it. So I was looking around to see if any other libraries were doing it, and, low and behold, the only other one I found was Reidsma’s library (actually a sub-section of it).

Interestingly (and surprisingly), Reidsma has not written anything about RWD, but he will talking about it at a work shop on it at ALA-LITA this summer. It fits in well with his ideas about library website design, and it will be interesting to see how he combines the ideas in his session in Anaheim.

Reidsma’s push for simple design on library websites goes along with the current mobile-first-RWD emphasis of modern less is more web design, that’s come with the Mobile Revolution. This is captured well in an article about designer Luke Wroblewski:

Wroblewski thinks the hard choices required to prune all but the most important features make for stronger sites. And, indeed, after they go through the mobile development process, companies often find that their desktop site looks busy, clunky and old by comparison.

What works for the dotcom companies of Wroblewski’s world can also work to the benefit of libraries. Actually, libraries have the great advantage over dotcoms that we don’t have to worry about where to put the ads squeezed out by mobile-minimalist design!

Matthew Reidsma’s Twitter – @mreidsma

Related articles:

Eric Rumsey is at: eric-rumsey AttSign uiowa dott edu and on Twitter @ericrumsey

Before the iPad came out in 2010, the working assumption was that web pages needed to accomodate only two screen sizes — Desktop/Laptop and iPhone/smartphone sized. Accordingly, many sites, including libraries, built separate mobile pages, sometimes called “mdot” pages because they often have the same URL as the desktop page preceded by “m.”

Mobile First

During this time, designer Luke Wroblewski (@lukew) proposed a somewhat different approach, that he called Mobile First. This is based on the idea that the best way to make web pages is to design them first for their appearance on mobile devices, and then to take into account the large-screen appearance secondarily. This approach has the great advantage that it eliminates having to maintain separate pages for small and large screens.

Enter the iPad … and Responsive Design

While there was a variety of tablet-like devices with screen sizes between smartphone and desktop before the iPad launched, they were never very popular. With the overwhelming success of the iPad, though, it quickly became clear that tablets of various sizes were here to stay (shown nicely in designer Brad Frost’s graphic below).

Before the iPad, the idea of having separate mdot-smartphone and desktop web pages was considered difficult but possible. When it became clear, though, that tablets of many sizes would proliferate, maintaining separate pages for every size was obviously impractical.

What was needed, thoughtful developers realized, is a way to code pages so that they look good on any size screen. So, soon after the iPad launched in April, 2010, Ethan Marcotte (@beep) — building on Wroblewski’s Mobile First idea — launched what he named Responsive Web Design (shortened to Responsive Design or RWD). This uses sophisticated coding (CSS media queries and fluid grids) to build pages that “flow” to look good on any size screen.

The RWD idea spread quickly with developers, who implemented it on their own sites and on smaller dotcom sites. In 2011, high profile sites began to launch RWD versions, most notably The Boston Globe and BarackObama.com.

On a desktop/laptop screen, a nice thing about looking at RWD sites is that it’s easy to see how they look on smaller screens — Just narrow the browser window, and the RWD site changes to the appearance it has on smaller screens – Try it out on a sample of RWD sites that have appeared in the last year: BBC, MinnPost, Center for Investigative Reporting, ProPublica, Univ Notre Dame, Arizona State U Online, A-W architecture, Jason Weaver (a small, exemplary developer site).

Libraries have been slow to adopt RWD so far. Our library system at Univ of Iowa has started with it (which is how I got interested) – We have it on the main University Libraries site and on the Hardin Library site. The only other RWD library I’ve found is Grand Valley State Univ (Michigan), which has implemented it on a sub-section of the library site.

Related articles:

Eric Rumsey is at: eric-rumsey AttSign uiowa dott edu and on Twitter @ericrumsey