August 4th, 2011 Brian Herzog
My library just launched our long-overdue Facebook page. In the course of preparing it, we had a discussion about why we needed a Facebook page, what we wanted to use it for, and how it related to everything else we were doing online.
This led to the realization that no one really understood exactly what all we were doing online. We have a website, Twitter account, blog, email newsletters, flickr account, and now Facebook, but no clear policy as to what gets posted where, when information is duplicated, how things are updated, etc.
To help understand how our various types of information are represented online, I created the diagram below - it's probably not 100% complete, but it does cover most of our bases:
On the left are our different types of information (MacKay is our branch library), and the arrows show how that information flows through different electronic tools. There isn't necessarily a hierarchy at work*, other than perhaps the automatic updates necessarily come after the manual updates. Otherwise, the boxes are laid out just so they all fit on the page.
After discussing this, we uncovered two philosophies at work:
- use the different end tools - website, Facebook, Twitter - for unique content, so as not to duplicate things and essentially "spam" our patrons that use more than one service (for example, you can see above that no event information is posted to Facebook)
- publish all of our content almost equally through all of our channels, so we're sure to reach all our patrons regardless of which tool they choose to use
I don't think they are mutually-exclusive, but it does take a lot of work and forethought to do it well. I also think that more of what we do could be automated, as cutting down on the manual postings would save staff time.
Do other libraries have similar online information relationships? I imagine things range from very structured to a free-for-all to orphan accounts galore, but I'm curious to hear what other libraries are doing, to get ideas on how to do it better at my library.
*Something to note on the diagram is our "secret" Twitter account. We have a primary Twitter account
we encourage patrons to follow and we use for regular tweets. The secret account is one we use only to post messages directly to our homepage
. The reason for two, and why I don't really want anyone following to the homepage updater one, is that clearing the message off the homepage requires sending a blank tweet - it's not the end of the world if anyone follows it, but the blank tweets do look odd. Besides, everything posted to it gets posted through our primary account anyway.
Tags: blog, calendar, diagram, electronic, events, facebook, flowchart, info, information, libraries, Library, online, post, postings, posts, public, tweet, tweets, twitter, website
May 5th, 2011 Brian Herzog
I'm doing a few talks this year about how to build a mobile website for libraries - based, mainly, on my posts about the one I made for my library. This Friday is the first of those talks, for the New Hampshire Library Association's Spring Conference.
For a sneak preview, I put my slides and a few more "going mobile" type resources up at SwissArmyLibrarian.net/mobile.
I also posted there my first attempt at a downloadable template version of the site I made, that other libraries can use to build a mobile site for themselves. It takes a lot of customization (obviously, it all has to be customized with your information), but I tried to provide instructions. If anyone tries it, please let me know how it can be improved.
I've never been to NHLA before, but I have heard nothing but good things, so I'm looking forward to it. Besides, any time spent in New Hampshire is time well spent.
March 29th, 2011 Brian Herzog
I had a great time at the Computers in Libraries 2011 conference last week - I met nice and smart people, attended good sessions (read my notes), learned a lot, and hopefully helped a few people by giving a workshop with Nicole Engard.
After a week of digesting, I wanted to share the three main points I took away from the conference. Here they are, in no particular order:
1. Simplify your website
This was mentioned in multiple sessions (also good stuff here), and sadly it bears repeating - library websites should not be junk drawers, hanging on to everything everything everything just in case some might want it. They might, but it makes your site so cluttered that they'll never find it anyway.
Another related principle is Aaron Schmidt's idea gradual redesign - instead of just one day - boom - entirely changing everything, do things gradually. Consolidate content, reorganize navigation, etc, in stages - it's easier for users to adapt to a few things at a time, and staff get to see continual progress, rather than having to wait until the entire project is done. I want start implementing this approach for our redesign project.
2. Libraries are about the experience
You know how you hear something and read something again and again, and then you hear it one more time and you finally understand what it means? That happened to me at CiL with the idea of User Experience (UX). Again, Aaron Schmidt has been out in front on this for awhile, but I only every thought of it in the context of using websites.
What dawned on me is that, in the library, the patron experience is everything - to us and to them. People don't use libraries because they like the idea of libraries - people use libraries for the experience they can find there. Whether it is curling up a print book to experience a story, or attending a lecture, or a storytime, or using our free internet access, or idly chatting with the circ staff about new books, what people are after is the experience.
Perhaps this isn't too novel unless you think of it this way: libraries aren't about books, or information, or programming, or even community - libraries are about experience. Patrons can experience our community space or our content, but it's their emotional perception that is key. Of course, different patrons experience different services in different ways, but it's our job to make sure they are good experiences.
3. The only good DRM is no DRM
When I was babbling about the HarperCollins fiasco, I focused mostly on their ridiculous policy approach, and didn't talk much about DRM itself. It's the technology that makes self-destructing ebooks possible, sure, but I considered it just a tool - a misused one, but not the real root of the problem.
But the Librarian in Black's "dead technologies" talk changed my mind. I wish I recorded her to share here - everyone should see it. DRM is the main problem with ebooks - and not even in a technological way. The problem is that publishers who are afraid to let go of old models insist on using DRM to cripple the potential of ebooks. I love analogies, and here's a good one: does your refrigerator limit the kind of ice cream you can buy, or get rid of it after a certain amount of time? No, so why would we allow it with ebooks?
We should not stand to be treated like criminals - that's what DRM does. Any effective and robust ebook model cannot implement DRM. I am not remotely as passionate or as eloquent as Sarah, but now I'm just as motivated.
March 23rd, 2011 Brian Herzog
Bohyun Kim, Digital Access Librarian, &
Marissa Ball, Emerging Technologies Librarian, Florida International University
- Good information cannot make up for bad design
- Give people what they want, not what you want:
- read content on a website
- want to learn how to use their website
- visit your site every day
- return to sites that have failed them
But they are always on the move - design your website like a billboard that would appeal to commuters, because that's all the time you have to direct their attention
Designers Usability means "fit for use"
- intuitive - you don't need to think about how to use a hammer
- easy to recover from a mistake
- conducive to users performing tasks
- no need to learn to use it
Usability is difficult for libraries because we offer so much with so many options
- but most of our information in separate silos
- much of the terminology is jargon and foreign to users
- information is segmented by departments that is confusing to patrons
What libraries get wrong
- pre-conceived notions of important
- lack of research on user behavior
- belief that design can change user behavior
- design based upon a committee - this is slow, design lacks unity, and represents insider opinion more than the users'
- writing is unsuited to the web
Common usability problems and examples
- promote all things - nothing stands out
- user have no idea where to start/focus
- information overload = stress
How to fix
- improve by taking things out rather than adding
- be aware of clutter creeping in
- users are happy to click "as long as"
- it is mindless ("3 click rule" isn't true as long as clicking doesn't require effort or thought)
- they know they are getting closer
2. Dated look
- lowers credibility of the site
- users suspect outdated content
How to fix
- replace old icons, images, typography
- update a CSS file to give a new look
- as long as the site architecture is sound, serves the same group, and has a clear task pathway that work, no need for redesign - make sure you know what work needs to be done
3. Too subtle design
- users scan web pages like a billboard while driving at 60mph
- subtly in web design often backfires
- good web design is different than good print design, because people do things differently
How to fix
- make visually clear what's most important, valuable, popular
- provide a clear visual hierarchy on the page
- break pages up into clearly defined areas
4. Unclear terms/Library jargon
- test your site with new users
How to fix
- replace all jargon with plain terms
- do now use the product name or vendor names
- use a short description if name is not clear
5. Redundant and unnecessary content
- redundant content creeps in as time goes by (welcome, introduction, etc )
- unnecessary content = small talk (users have no interest in small talk)
- answer users' questions, not yours
- serve content that users can grab and go
How to fix
- remove small talk and explanations by using descriptive names
- make a content inventory
- review content by category & purpose
- remove overlapping, redundant, unnecessary content
6. Bad writing
- rewrite a page to be half of its length
- then cut more!
How to fix
- use clear headings
- make paragraphs short
- start with the key points
- make content easy to scan
7. Design against convention
- the best ally of usability is convention
- anything that prompts a pause and thinking is bad
- surprise, confusion, agony over choice (when there is no distinguishable difference), stress
How to fix
- don't underestimate the value of convention
- be creative without sacrificing usability
- convention implies:
- obvious and predictable
- clear paths to goals
8. Unintuitive navigation
- is it an information architecture an issue?
- if so, use usability testing method to find out what navigation structure or organization of content makes sense to users
User testing - quick, cheap and easy
- find out who your users are
- focus groups, surveys, and analytics data can all help determine which users to focus on
- it's best to test in small groups - three tests with five users is better than a single test with 15 users
- you will learn who your users are, what they want, and how best to get it to them
- you should use more than one, and make them simple
Focus Groups and User Surveys
- best to conduct early one, because they gather background information and overall opinions and desires
- sessions last 1-2 hours, and work best when combined with other methods
- put ideas on cards/post-its, and have users arrange them in a way that makes sense to them
- also helps correct terminology, because users need to understand the words on the cards
- sessions last 1-2 hours, can be done in groups or individually
Contextual Interviews and Intercepts
- based on observations of users in their environment
- ask questions, and be casual
- this is one of the best methods to use
- easy, disposable, adaptable, affordable
- allow your users to be creative
- create screenshots of various screens of your site for users to interact with
- easy to generate lots of ideas, because people are more willing to scrap ideas on paper than delete
- files they have worked on
February 1st, 2011 Brian Herzog
I don't know how I missed this before, but only recently Boopsie for libraries reached my radar screen - it's a company that will create a mobile version of a library's website and catalog.
There are other options* out there, but Boopsie seems like a great and easy alternative to creating your own mobile website. And even better, they also mobile-ize the catalog, which I couldn't do (although apparently non-catalog services are more popular with mobile patrons).
Pricing seemed reasonable (for what you get) - a library near me is in the process of signing up, and reported the cost is in the few-thousand dollar range (or, it would be roughly $10,000 for our whole 36-library consortium to sign up). Lots of libraries are already using them - Sarah has a good write-up on San Jose's experience, and WorldCat and ALA also use their app.
I'm not trying to pitch Boopise, so much as I'm pitching the importance of libraries having a way to serve mobile patrons - using vendors like this* are an option for libraries who can't do it themselves.
*Library Anywhere from LibraryThing
is another mobile website+catalog solution, and seems to be cheaper
Tags: app, apps, boopsie, catalog, devices, libraries, Library, mobile, phones, public, smartphone, website
December 16th, 2010 Brian Herzog
Remember a few months ago, when I was inspired by Steve Butzel's presentation at NELA2010 and created a mobile version of my library's website? I bet you have that date marked on your calendar.
Anyway, one lingering problem I had was some mechanism to automatically detect mobile devices when they visited our website, and reroute them to the mobile version instead of the full web version. I finally had some time this week and was able to accomplish that - aided by the fact that it was easier than I expected.
The ultimate goal is to redesign our entire site along the lines Brett suggested, by creating a stylesheet specifically for mobile devices. Brad pointed out that the Canton Public Library employs this, awesomely: visit their site and slowly make your browser window smaller, and watch the website flip from "full web" mode to "mobile" mode.
- Php is more fun, and I know our server runs php
The website offering the php method is http://detectmobilebrowsers.mobi, and very happily they make it available free for non-profits. Here's what I did:
- Read and reread their website
- Downloaded the main bit of code, and uploaded it to our web server
- Used their Function Generator to create the snippet of code to paste into the top of our homepage. I chose to treat all of their options as a mobile browser, and redirect them to http://www.chelmsfordlibrary.org/mobile - the resulting code looked like this:
(this should be two lines of code, but it wraps because of the width of my blog - if you use this code, make sure the second and third lines above are actually one long line)
- I copy/pasted that code into our index.html homepage. However, because this is php code, it had to go between php tags, (<?php and ?>), so the complete code I actually added to the top of our page was:
(again, see note above about line wrapping)
- Note that the path in the "require_once" line must match where on your web server you actually saved the mobile_device_detect.php file (downloaded in Step 2)
- Now, the last step was a little tricky, because it involves editing the .htaccess on the server. It's easy though, and one of their faq answers explains it.
Basically, .html files don't normally run php code - .php files do that. So if our homepage was index.php instead of index.html, I could have skipped this step. Instead, in order to make .html pages execute php, I had to add a few lines to our server's .htaccess file - which was no trouble at all - and then everything worked splendidly
That is, at least, so far. I've done some testing with mobile devices and (as suggested) with the User Agent Switcher Firefox add-on, and all of that has worked. But please, if you have a mobile device, visit our homepage (http://www.chelmsfordlibrary.org) and let me know if you don't get redirected to our mobile site.
A couple other notes:
- I also added a link to the mobile site in the upper-left corner of the homepage, in case the redirect doesn't work
- I only added this auto-detect to the homepage. I thought about adding it to every page, but our full site has a lot of information our mobile site doesn't - especially descriptions of our events. If I added the redirect to every single page, people with mobile devices basically wouldn't have access to any of that. So, my thinking is to provide mobile users with the (robust) basics, but if they want more than that they'll have to endure our not-great coding until we're able to redesign the entire site to be mobile-friendly
This was easier than I was expecting, which makes me think I missed something.
Update: someone pointed out a gap in my logic. On the mobile site, there is a link to "Visit our main site" which linked back to our full homepage. However, since the homepage redirected people to the mobile site, anyone clicking that link from the mobile site just got looped right back to the mobile site. So, I changed that link to go to our About page. Again, this is a good reason to just have mobile-friendly stylesheets like Brett and Brad suggest above.
Tags: auto-detect, cell, cell phone, code, coding, conference, detect, iphone, libraries, Library, mobile, phone, phones, PHP, public, redirect, smart, smart phone, smartphone, steve butzel, website