Post navigation

Although my job title is user experience librarian, I help out quite a bit with managing electronic resources in my library. Over the past few years, I’ve gone down deep in the weeds countless times trying to figure out what went wrong when a user reported being unable to access an electronic resource. Some times it’s just one article, some times it’s an entire database. The possible points of failure (or confusion) for the user are many. Here’s an exhaustive list (for me, at least) of what commonly goes wrong for our users.

A recent interview of UX expert Leah Buley by Jared Spool on Spoolcast included an interesting discussion of leadership and collaboration. Buley was expanding on ideas she covers in her book, The User Experience Team of One. In the interview, Buley talks about how it took her a while to get comfortable becoming that person that might get up in a meeting and start drawing on a whiteboard or using post-it notes to help move the conversation along. When you do that kind of thing, she notes, you command attention but in a helpful way that she calls “leaderly.”

I really like the sound of that word, as it seems more collaborative and non-egotistical than saying you are “showing leadership” in a meeting. It may be a subtle distinction that only works for me, but that’s fine. At my library, I’m the only person with UX as part of my job title and core job focus (which isn’t to say that my colleagues don’t do UX work, as they do but may not think of it as such). In meetings for various projects–some local to my college’s library and some for projects that are shared across the system of CUNY libraries–I find myself wanting to contribute in ways that draw on my UX perspective. The last thing I want to do when I speak up is make it sound as though I am the expert that all must bow down to. I think if in my mind I frame my efforts as being “leaderly” I’m more comfortable with speaking up or contributing in other ways.

This week, we turned on the kiosk that lets our students check out laptops to themselves. Here’s what it looks like:

The laptops can be checked out for the entire day by Baruch College students (our library is typically open from 7 am to 12 midnight). As you can see, there are 12 Macs and 12 Dell laptops available:

The units recharge in the kiosk (students can check out chargers if they want from the desk where we check out other laptops). Students will swipe their ID cards and then be asked to type in on the touchscreen their Baruch username and password:

As you can see, we’ve put a custom skin on the units, which are otherwise an unremarkable gray color.

It was nearly two years ago that a colleague from campus IT and I saw a demo of an earlier version of these kiosks from LaptopsAnytime. We’ve had the units next to the reference desk for a while now, something that attracted a lot of attention from students, who kept asking if the kiosks were ready yet. It’s exciting to have them finally on and available This pilot may lead to additional units on campus (maybe not all in the library!)

Since 2008, over 17,000 members of the Baruch College community have used [email protected], the college’s WordPress platform. It’s used inside and outside of classes, and hosts a range of projects, program and group websites, and student journals and magazines. This panel represents a cross-section of current users of [email protected], and we’ll show our work on the system and discuss how it has enhanced our ability to communicate with our classmates, colleagues, and the outside world.

Before the conference, I wrote out my presentation, something I do when I know that I won’t be using slides. Here is the text I prepared:

I’m Stephen Francoeur, a user experience librarian here at Baruch. Before getting started with [email protected] when it launched, I’d already been blogging elsewhere since 2003, primarily at my personal blog, Digital Reference. Today I want to talk about two ways that I’ve been using [email protected]: one for internal communication with my colleagues in the library and one in the courses that I teach.

In 2004, Louise Klusek, another librarian I work with, and I came up with the idea to create a blog to notify reference librarians about news they’d want to know, things like new databases our library just started subscribing to, changes to services and policies in the library, questions that were stumping some of us at the reference desk, etc. All the librarians who worked at various reference service points will encouraged to write posts and make comments (and many did over the years). In 2009, we switched over from using Blogger to [email protected] so that we’d have greater control over the look and feel of the blog and so that we could control its future (what if Google sold off Blogger some day to a company we didn’t want to work with).

We encouraged our colleagues to sign up for email notification of blog posts and showed them how to subscribe to the feed of posts and comments in a feed reader (including the one that is built into Microsoft Outlook, a program on the desktop of every librarian’s computer). Over the years, we found lots of our colleagues posting really helpful content. In the past year, we’ve seen the number of new posts go down somewhat, and I’m not sure why (but would like to know).

Over the past 10 years, I think we can safely say that these have been the advantages of using a blog for certain kinds of internal communication:

the messages as blog posts can be far richer than if they were transmitted simply as email messages (embedded videos, links, etc.)

searching for old posts is much easier on a blog than searching for old emails in Outlook

a number of times students have found our posts on their own and used them to solve problems they were having in their own search efforts

librarians at other colleges who help our students on our cooperative chat reference service know they can go to our blog to get news on databases that may be down or other timely information that only local librarians might know off the top of their heads

other librarians around the country have subscribed to our blog so they too can learn when a database has a new search interface or how to find some arcane piece of accounting information

Now I’d like to switch over to talk about how I’ve been using blogs in the credit courses I teach. I’ve refined how I’ve used them over the years and would like to mention what seems to work for me. It’s worth noting that my classes tend to be small (max of 25 students) and that nearly every class session features hands on activities in groups or individually, usually on the computers in the room.

The main ways I use my course blog are to have students write posts and comments as homework (this counts for almost a third of their grade). They are expected to write 5 posts and to write 10 comments on the posts of their classmates. They are free to write on any topic that relates in some meaningful way to the subject of the class.

The other use of the blog is to have students write a post at the end of class that is part of some in-class activity. If they are working in groups, then one person in each group writes the post while the others in the group look over that person’s shoulder and direct them.

And the other main use of the blog is a way for me to send out class announcements and do so in a way that are re-findable.

The benefits I’ve seen so far include:

creating a place for conversation for those students who are unwilling to speak up in class, even if I’m requiring it as part of their grade

I can more accurately assess what they’ve learned from in-class activities if I read all their posts written at the end of class (and it’s more efficient, because it takes less class time for them to all write a post then it would take to have each group or person report back verbally)

students are getting lots of opportunities for low-stakes writing in a medium that allows for a fair amount of creativity (links, embedded videos, images, etc.)

I should mention that the class I’ve taught for the past year, Information and Society, focuses a lot on exploring how communication tools have dramatically changed in the past decade because of the web. For many students, this is their first time blogging; by using the same tools we are discussing in class, they get a deeper understanding of the changes we are learning about.

Here are some practical tips I’ve found that help make the blogs successful in my class:

Blogging is part of their grade, and there is a specific quota about how many posts and comments

On the 2nd day of class, I have them all sign in for the first time, learn how to modify their screen names, write a first post (they write on “when I think of the library, I think about…”), and write a comment on someone else’s post

I set up JetPack so they can take advantage of the “subscribe to email notifications” feature

Every semester, there are always a few students who end up enthusiastically embracing blogging and write more posts and comments than are required. While I would love to see that happen with a greater percentage of students, I think it’s safe to assume that the current split follows the usual 80/20 rule we see elsewhere on the web (20 percent of the users account for 80 percent of the content).

At the end of the course, I always ask the students to discuss whether or not we should take the blog down or make it password protected. It’s a great opportunity to discuss what it means to be on the web, to weigh public vs. private personas. To my delight, the students always vote in favor of keeping the blogs up in perpetuity.

This year, some colleagues and I are doing a somewhat involved research project involving usability tests that will compare searching in the mobile catalog interface to the traditional web interface. One of our great challenges is finding a good way to capture what happens on the screens of the mobile devices (Android and iOS) of our test participants. For the Android users, we’ll be providing them one of our own phones to use during the test. I’ve been looking at using the GoToAssist app as a way to capture what’s on the screen of our Android (actually, it’ll likely be my own Samsung Galaxy S3) phone.

I thought I’d share what’s involved by making a recording on my desktop (using SnagIt) of what the screensharing looks like when viewed on a PC. This setup may work for testing we have in mind, although the video transmission from phone to my PC seems to be delayed by about 10-15 seconds. Also, if I scroll really fast on the phone, the screencapture from GoToAssist doesn’t completely capture that; instead you get kind of a snapshot effect in the transmission and not a smooth video. But this may work well enough.

For the iPhone we’ll be also using for testing, we are hopeful that the Reflector app will do nicely.

Recently, I’ve come to realize just how much a part of my daily work involves taking screenshots. The more I think about it, the more I see how knowing how to take screenshots, edit them, and use them is an essential computer skill, akin to knowing how to create a document in a text editor or work with a spreadsheet. I’m not saying that everyone must learn how to make them; instead, I just want to spotlight something that lots of people may want to start doing more of, especially if they are involved with

instructing others how to use the web

creating content for the web

marketing services and resources

maintaining and/or troubleshooting web-based services and resources

In this post, I’ll focus on using screencapture software to take static images–screenshots–and leave for another day the discussion of using the same software to make video recordings of what is happening on the screen.

Main Uses

It’s worth considering all the ways that a screenshot can help you out with various tasks if you are working in a library:

Advertising services and resources that are web-based

You may want to include a picture of a page from what is being advertising or you might just want to include a small portion of the page (e.g., the logo for the service, a portion of the page that is noteworthy, etc.) The screenshots might be for printed posters and handouts or for banner images or pictures in an image carousel on a web page.

Offering “how to do it” instructions for a web-based service or resource

I love being able to take a screenshot and annotate it with text in callouts that show you exactly where to look on the page and what to click or type (e.g., see this guide to searching for literature reviews in PsycINFO). This kind of screenshot can be be great for courses and workshops, online tutorials, for reference interactions (I sometimes make them in the middle of chat reference sessions and reference desk interactions to share with the person I’m helping), and for staff training and documentation purposes

Documenting problems found in web-based resources and services

Part of my job involves reporting various problems discovered in our electronic resources and helping to solve them. Being able to take a screenshot of a link resolver menu or of a listing for a journal in our electronic journal knowledgebase that doesn’t jibe with information we have about that journal elsewhere can save me a ton of time when typing out support requests to vendors and local help desks. It’s so much easier for the person reporting the problem and for the person receiving my report of the problem to have an annotated screenshot that points out the problem area on the screen than it is to type out laborious instructions to the recipient about where to look (“On the lower left corner of the screen, just to the right of where it says ‘Journals” there is an icon that should launch…”

Capturing design ideas found on the web

Although I’m not a web designer, I do find myself in the position of making recommendations often about how to tweak this or remake that on our library website. To help communicate my ideas, I rely a lot on sharing screenshots taken of other sites on the web (or more precisely, specific features or elements on a given site). I’ve been building a small pattern library in Evernote to turn to when I need ideas as well; each screenshot include a link back to the site where the picture was taken (while the URL may endure, the interface element that initially caught my eye may not, which is why I like to save my own copy as a screenshot).

For publications and presentations

Although there may be copyright considerations that may limit how and when you can share your screenshots when the images are of the work of others, adding screenshots to your articles, chapters, books, presentations, etc. is a great way to give your audience a break from text. For an interesting tale of how one author struggled to convince the publishers of her book that the screenshots she wanted to include would fall under fair use protections, see Jessamnyn West’s post, “On the Internet, with the Exploded Text.”

Getting Set Up

The basic set up you’ll need is some software to make screenshots and some software to annotate and edit them (often, screenshot software allows to do all that in the same program). If you want to get fancy (which I recommend), you’ll also want to figure a way to:

locally store and organize your screenshots (you’ll often find you want to re-use them or re-edit/re-annotate them again and again)

publish selected screenshots to the web so that each image has a unique URL (this greatly increases the options you have for sharing them)

I’ve been using SnagIt for many years because of its versatility (it’ll capture images and video; it can scroll as it captures so that long pages can be captured in full; the editing and annotation options are many and easy-to-learn; and it comes with one-click options to publish images to the web for easy sharing). It’s not free, though, which for many is a major strike against it. There are many free options for software you can install as well as options for addons and extensions that run in your browser.

For local storage of images, I find it useful to create a series of nested folders on my hard drive (or I could put them in Dropbox or Google Drive, I suppose). The main folder is just called “Images” and there are within that one sub-folders for each database, resource, etc. that I’ve taken a screenshot of. If I have to do a screenshot of the Factiva database, I’ll create a Factiva folder to save it in and given the screenshot some filename that includes Factiva and the focal point of the image (or it’s intended use).

For web-based publishing of images, I rely on the account at screencast.com that I set up as part of the installation process for SnagIt (here is an example). There are other options that would also work nicely if you are in need of a place to stick your images on the web for sharing purposes:

Some of these options will not only give you a unique URL for the image but will also give you an embed code so you can share the image on some other website without having to upload it to the website.

Some Caveats

In addition to thinking about fair use considerations before publishing or sharing your screenshots, also consider privacy issues. If I am making a screenshot to help a student, I may not want to make it possible for others to stumble on that screenshot; if I upload the screenshot to an image hosting service on the web, I will want to make sure that it can’t be browsed as part of a gallery of images I’ve previously uploaded. If there is personally identifiable information on the screenshot, I’ll want to use the editing features in the screenshot software (or in a separate image-editing software package like Paint, GIMP, Photoshop, etc.) to remove that info or blur it so it’s no longer legible.

For those of you who made it to the end, I hope you find this useful. I’d love to hear about any tips or tricks you’ve come up with.

On a mailing list that I am on, I recently chimed in on a thread about librarian bloggers with a mention of how I followed hundreds of blogs in my RSS reader. Someone asked what my system was for keeping up. Rather than burden that list with a huge reply, I’ve written it up here. I think I’ve found a system that is manageable for me, but I can’t claim that the regimen is for everyone. The short version is that I skim a lot, archive a lot of what I’ve enjoyed, and save a lot for reading later, not all of which I eventually get to. What follows is what I do pretty much every single day.
Check in Feedly Throughout the Day

There are a ton of reasons why I like Feedly as my feed reader. The main one is that it’s available to me in lots of places. The more places that I can check in to see what new items have turned up, the easier it is to keep up. I can get to it in my browser, on my Android phone and Android tablet, and the loaner iPad I have from work.

Each day, I check in anywhere from ten to thirty times a day to see what’s unread. Now that I’ve typed that, I realize how crazy it looks, but honestly, I wouldn’t be doing it if I didn’t find the stream of information in the feeds valuable. When I am viewing Feedly in the browser, I only use the keyboard shortcut of “J” to advance to the next item (or “K” if I realize I need to back up to a previous item). Scrolling and clicking is way too inefficient a technique for getting through the typical ten to twenty unread items that greet me when I log in. If I go more than eight or nine hours, there might be up to one hundred unread items if it is a weekday and thirty to forty if it is a weekend.

I do a lot of headline scanning as I click “J” and make lots of quick decisions about whether at that moment I:

am interested enough to way to linger and read the post right then

am happy enough gleaning what I can from the headline

want to read a few sentences from the start and then move on

want to save the post in one of two places (more on that in a moment)

On my phone, tablet, and iPad, I can swipe through posts almost as quickly as I can click “J” when in the browser.

When I Want To Save Something

I have two main places that I use to save articles and one more that is as much for saving as it is for publicly sharing what I think is interesting. If I see a post, maybe a longish one or one that requires more directed attention, I’ll save it to Instapaper, a service I dearly love. Once an item gets saved to my Instapaper account, I can download it to my gadgets for offline reading. The downloaded version is a clean, mostly text only version of the post, which makes it really easy to read and focus on. Once I’ve read a post that I had saved in Instapaper, I delete it from my account.

In the Feedly app, you can designate what “read later” service you want your posts to be saved to. I set it up to go to Instapaper. At the top of every post in the Feedly app is a save icon I can tap that will send that item straight off to Instaper. In the browser, when I’m plowing through posts, if I want to save a post to Instapaper, I have to use a different method; I click on the post title to open it up in a different browser tab (it opens the post on the blog itself, not in Feedly) and the use the Instapaper bookmarklet I’ve got set up on the browser toolbar.

Sometimes after I’ve read a saved post in Instapaper, (maybe half of the time), I decide that it’s interesting enough that I want to share it with the world. I find a quote from the post that’s caught my imagination (even if it’s something I don’t agree with) and post it to my Tumblr site (along with a link back to the original post). That Tumblr serves as my commonplace book as well as archive of blog posts that I may want to get back to later. By using Tumblr to maintain my commonplace book, I can make my private acts of discovery and reading public, thereby spotlighting in a very open manner something that I think other folks in libraryland might find interesting.*

There are a handful of posts that turn up in Feedly that I want to save that are not really work-related. These posts are typically very pragmatic things that I suspect I’ll want to return to later (such as posts from Lifehacker about the top 5 pieces of software for creating DVDs). Posts like these I save to Evernote in a special notebook just for such items.

Weeding the Feeds

Over seven to eight years that I’ve been using a feed reader (Bloglines, then Google Reader, now Feedly), I’ve been adding new feeds to my collection of subscriptions at the rate of about one to three a month. Every few months, I unsubscribe to a feed because I’ve giving up on it providing any items I care about or because I’ve noticed that it’s been dormant for at least a year. I’ve not been that assiduous, though, about weeding dormant feeds all these years, as a number of blogs that I had given up as dead have sometimes come back to life. Also, it’s really not worth my time to delete dead feeds, as they really don’t take up any mental space for me; they’re are invisible within my reader unless I go browse the complete list of feeds, something I rarely do.

So that’s my system. It may sound nutty to some, but I hope that the technique of passing items off to Instapaper and Evernote is useful to some people who are struggling with unread items. My final word of advice is don’t sweat it at all if you decide to declare feed bankruptcy; if your inbox overflows beyond all reason, just click the “mark all as read” and move on with your life. Chances are, someone in the near future will blog about that same topic or link back to one of those posts you skipped, offering you another chance at it.

* Using the IFTTT service, I’ve got it set up so that every post on my Tumblr site is copied into my Evernote account. That way, I’ve got all those posts backed up in Evernote and saved in place where I’ve got all sorts of documents, notes, etc. squirreled away (not to mention easily refound via Evernote’s great search capabilities).

This fall, I’m going to be working with some colleagues from other parts of CUNY to do some research that will allow us to explore the how perceptions of the web on mobile devices and on desktop/laptop browsers affect the user experience. Specifically, we want to look at an interface where there is a mobile web version that is notably different from the traditional web interface. How distinct can the interfaces be before the user experience is notably degraded? And which interface will suffer more in the way it’s perceived?

I realize that one way to get around the problem of forked interfaces (one for desktop/laptop browser dimensions and one for mobile browser dimensions) is to focus instead on a responsive design that shifts content around depending on the device being used. But I still wonder where the break point is for responsive design, too. How much shifting of content on a page in a responsive design can be done before the user who visits a site on different devices regularly gets thrown off by the altered layouts?

It may be the case that most users have minimal issues in adjusting themselves as they use different devices to visit the same site. I’m interested now in finding literature that addresses these questions and hopeful that the research my colleagues and I are about to undertake will offer evidence with respect to interfaces in library resources.

Today, we start the process of redesigning a page on our library’s website that details various services available to faculty members. I thought it might useful to document that process a bit.

Some History

The library here at Baruch College launched a redesigned website on December 26, 2012. Most of the work that went into the redesign focused on student needs. Now, we’d like to take some time to rethink how the services and resources of interest to the faculty are presented on the site. The text on the current “Faculty Services” page is mostly the same text we had on the old site.

The long version: Today, I meet with a five-person Committee on the Library, a body whose members are elected from departments across the three schools at Baruch (a business school, a school of arts and sciences, and a school of public affairs). To prepare for today’s meetings, I asked members to complete a three-question survey:

What are the top three tasks that you come to the library website for?

What other reasons or tasks bring you to the library website?

What brings you to the library website more: your own research needs or your teaching needs?

At the meeting, I intend to:

review the overall plan for redesigning the page

review the results of my survey and a survey administered last fall to the faculty that focused on the value of the library

do a card sorting exercise where I ask them to arrange cards featuring services and resources into piles that make sense to them (from this, I hope to discern a useful way to chunk the content on the page, to find better wording for that content, and to learn if there are any things I forgot or that I can forget)

After the meeting is over, I expect to do the following this semester:

work with our web design team to come up with a new layout and new text for the page

make individual appointments with members of the Committee on the Library to have them do a traditional usability test that will likely take them to the redesigned faculty services page as well as other places on the website

after analyzing the results of the usability tests, I’ll work with the web design team to further refine the faculty page

I expect that the process will be completed this spring semester. As I complete steps in the plan, I’ll try to return to my blog to write up posts about how it’s been going.

At my library, I’ve been asked recently to look into ways that we might create an e-resource ticketing system. The main goal is to have a system that makes it easy for librarians to report a problem and to check the status of efforts to fix the problem.

Here is a list of some of the key functions and features that I’ve come up with so far:

librarians can report a problem with an e-resource

a web form would be the main way to enter requests

email submission would be a useful though not essential additional way to report

librarians can browse previously reported problems to see if the one they want to report has already been reported

filtering and sorting options would be preferable

librarians can check status of previously reported problems

if a login system is required for the librarians submitting or browsing tickets, it should allow us to hook up with Active Directory (I don’t want anyone to have to remember any additional user name/password combos)

my supervisor, the head of collection management, should be able to assign tickets to me or others as needed

those of us handling tickets should be able to add data to an additional field if initial troubleshooting reveals that the problem is related to a different e-resource or system (for example, a report may come in that we can’t access a particular journal, but the problem may actually turn out to be one with SFX and not the database where the journal is found)

those of us handling tickets should be able to update the status of the tickets and to add notes about how the resolution is progressing

This system is meant to be for internal use only and wouldn’t be made visible to our public. It’s got to be web-based, as we don’t want to be messing around with installing software. I’m also hoping that we can find a solution that is free. It doesn’t have to be a really fancy or slick system. Here are some of the options I’m thinking about:

the IT unit on campus uses KACE already for its ticketing system; maybe we can get set up on it

Google Spreadsheet with a web form for intake

Google Fusion Tables with a web form for intake

After all this fuss, I may end up going with a boring but serviceable Google Spreadsheet/web form combination, as I can get it up and running for free in about 15 minutes. What free systems or tool would you recommend? If anyone has screenshots or a public view of some part of the system they use, I’d love to check them out.