The Mobile Library Ecosystem
•1 like•1,850 views
Report
Share
Download to read offline
Presentation by Stephen Francoeur at the 2012 SUNYLA conference, 7 June 2012.
Recommended
More Related Content
More from Stephen Francoeur
More from Stephen Francoeur(8)
Recently uploaded
Recently uploaded(20)
The Mobile Library Ecosystem
- 1. The Mobile Library Ecosystem Stephen Francoeur User Experience Librarian Baruch College SUNYLA 7 June 2012
- 2. Self- Maslow’s actualization hierarchy of needs Esteem Love/belonging Safety Physiological
- 3. Walter’s hierarchy of user Pleasurable needs Usable Reliable Functional
- 5. Uhm, OK.
- 8. Image Credits Slide 2: Chart adapted from "Maslow's hierarchy of needs." Wikipedia, The Free Encyclopedia, 3 Jun. 2012. Slide 3: Chart adapted from Aaron Walter, Designing for Emotion (New York: A Book Apart/Jeffrey Zeldman, 2011). Slide 4: arbyreed. “Pipes and Stuff.” 2007. http://www.flickr.com/photos/19779889@N00/6239083582/ Slide 7: “Miles Glacier Bridge, damage and kludge, 1984” http://commons.wikimedia.org/wiki/File:Miles_Glacier_Bridge,_damage_and_kludge,_1984.jpg
Editor's Notes
- Hi, I'm Stephen Francoeur. I'm a user experience librarian at Baruch College. Over the past year and a half, I've tested and launched a page for mobile databases on our library site and am working on other not-yet-released mobile projects. For my presentation, I'm expecting to focus more on asking provocative but still useful questions instead of prescribing a list of best practices. I have three overarching questions that generate sub-questions:- what do they want- what do we know they need even if they aren't aware of it yet- what are we capable of doingMy AssumptionsBefore getting to those questions, I want to mention at the outset that one of my basic assumptions is that libraries typically don't have the staff on hand or the time and money available to do all the mobile web development they'd like to. It's hard enough trying keep our services and resources functional and reliable on the standard web let alone the mobile web. We all get by as best we can knowing that if we only had a little more money and a few more people, we could do X, Y, and Z.
- I'm also going to mention here that I believe we need to aim high in all our work on the web regardless of the device displaying the content. In Aaron Walter's book, Designing for Emotion, he offers as a web designer his take on the hierarchy of needs outlined by psychologist Abraham Maslow in the 1950s.
- As you can see, he argues that users ultimately are looking for pleasure, for emotionally engaging and memorable interaction with the web. Yes, the functional is important, stuff has to work. Yes, it has to be reliable and not give us the fail whale. Yes, it also has to be usable and behave in predictable ways. But ultimately, if we really want to keep our users engaged, we have to create sites that give pleasure back to the user.When thinking about designing for mobile devices, I think we need to talk not just about library websites or apps but about the broader web ecosystem that we provide to our users: the catalog, our databases, remote authentication systems, link resolvers, electronic resource lookup tools, digital reference services, institutional repositories, etc. When we talk about developing for mobile devices, we need to keep in mind this crazy complex ecosystem that we've kludged together over the years. Using Walter's pyramid model, I'd say that library ecosystems are operating mostly in the realm of the functional, occasionally spiking all the way through the level of the reliable to the usable level. I'm not sure anyone has ever said that our web ecosystems are pleasurable, that they look forward to coming back again.
- To be fair, our standard browser based ecosystem is crazy complex. Over the years, as new standards and technologies have come onto the scene, we've adopted them one after another, done our best to jury-rig them together, and then struggle mightily to keep everything working and up-to-date. We use MARC for cataloging; OpenURL link resolvers and knowledgebases; discovery layers; APIs to pull in jacket art, LibGuides content, items in Google Books, recommended articles from bX; electronic resource management systems and ILSs; content management systems; chat/IM and text message systems; EZproxy for remote IP authentication; institutional repositories and digital collections; and so much more.What Do They WantThere's no need for me to bother with stats at this point convincing you that we need to address mobile options. I'm sure we're all agreed that developing for mobile devices is a given at this point. The real question, though, is what do our users really want to do with their phones and how can the library support them in that. Before we race off making mobile friendly sites, we should be asking our users what kinds of library/research related things they'd like to be able to do on their phones. And we should be asking them, "Do you really want an app or would you prefer a site designed for mobile browsers?" I've got this little LG Optimus phone from Virgin Mobile with a limited amount of storage on it. I have to be very choosy about what apps I put on it. In fact, I've got a musical chairs situation. There are more apps than I have storage for, so I regularly uninstall some on a short-term basis so I can re-install others that I might need for a particular short-term use (such as the ZipCar app on those once-a-month times I rent a ZipCar).Are our students big texters? Will they use email much on their phones? Do they expect to be able to do more than quick lookups for known items in the catalog? Do they really want database access? What is the relationship between their phone and the laptop they may have? When do they use decide to put down the phone and break out the laptop for some library-related task?What Do We Know They Need Even If They Aren't Aware of It (Yet)There's no reason that our users need to know about the complex ecosystem that we provide for them via the standard browser. Ideally, the systems should just work for them and feel seamless. Think here especially about technologies like link resolvers and OpenURL, remote authentication via proxy servers, etc. Do we really want to recreate that same ecosystem on mobile browsers? As compared to desktop and laptop computers, mobile ones (phones and tablets) offer some unique affordances. To what extent do we want to exploit those affordances to over new services or new ways of accessing existing services? We can help our students do clever things with the camera on smartphones, such scan QR codes that take them from a sign in the stacks to a relevant database or ebook, or scan barcodes of textbooks in the college bookstore to see if the book is on reserve in the library, or navigate the nooks and crannies of the library with the help of an augmented reality app. These are things that students might not know they want. How cutting edge do we want to be? Is it worth the trouble to wow them with some new technology that might never get the kind of usage we would like?What Are We Capable of DoingSome of us may be lucky enough to have staff and money available to develop cutting edge mobile services that users find compelling. Some of us may have a devoted soul in the library capable of kind of hacking together things but who also doesn't have level of support or ability really needed to do the job well.What about the technology under the hood? We're in a weird stage now where people have really embraced the functionality of their smartphones but find the points of connection between the mobile web and the traditional web disjointed and disorienting. Has anyone here had the experience of search a mobile web friendly database on your phone and found that the text of the article you wanted to read is mobile unfriendly PDF or displayed in HTML on a site that isn't optimized for mobile viewing?
- How many of our vendors offer mobile interfaces? From the experience I had last year of setting up access to all the databases that will work on mobile devices, I'd say half maybe, and that half is a mix of well done mobile web pages, crappy mobile web pages, slick apps, and crappy apps (hello, Gale AccessMyLibrary!) How well does OpenURL work? Will our link resolvers get us to the full text as they are supposed to? Will they still autofill the ILL forms? Is our ILL form even mobile friendly? For those services that use LDAP for authentication, will they still work properly in a mobile environment? Do we have an mobile friendly EZproxy page? What ways can users save citations found in mobile interfaces? Do they work with Zotero, Mendeley, RefWorks, etc.?As someone who is used to helping manage electronic resources in our library, I'm also wondering about the challenge of managing a parallel set of mobile optimized services and resources. Consider the challenge we have now of managing our subscription databases and e-journal collections. From time to time, the URLs for those services change, and we have to run off to update the URLs on our various web properties. Now imagine what happens if many of those vendors decide to offer mobile web versions that have a unique URL; now we have to maintain two sets of URLs for those databases. And what about the non-standard ways that database apps tend to deal with authentication. Are we prepared to support all of those, to create help pages for our users, to train our reference staff how to answer questions about them? To get the EBSCOhost app to work, you have to be in the web interface, look at the bottom of the page for the link for the app, bring up a screen where you type in your email address. EBSCO then sends to your email an authentication key you have to click on to activate the app.
- Emerald's app requires some sort of username and password be created but doesn't offer any help in the app about how to do that. Gale's AccessMyLibrary app requires that you input your email address, then go to your email to get a password that is sent to you, then you go back to the app and enter in the password; this app, frequently freezes up on me (at the moment, I can't get it to work).As you can imagine, if a vendor offers a mobile web interface, I promote that one over the app every time. But what are supposed to do about those databases where there is no mobile option at all? At my college, which is the nation's largest undergraduate business school, we rely on dozens of specialized business databases that may take years before they develop any sort of mobile interface. And our catalog, Ex Libris Aleph, has no mobile interface yet either. How long can we wait for the vendors to develop solutions for us? When should we invest time in developing our own mobile option for the catalog?
- In ConclusionWe're straddling an awkward divide between mobile and standard web right now. How long will our users wait for us to find ways to close those gaps is unknown. We're kludging together solutions and fixes where we can. But I wonder: if we can't provide a rich mobile ecosystem to them now, how much does that contribute to our increasing irrelevance to them, to negative perceptions of our value? Do they really expect it now? Or will they cut us some slack?