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.
I hope that they’ve designed it so that it automatically detects whether you’re using a browser on a phone and then redirects you to the optimized interface. Some of the database vendors that offer mobile browser interfaces require the library to set up a unique of URLs for the mobile versions, which means the number of links you have to maintain and provide to your user has doubled. As anyone who has tried to maintain electronic resources for a library knows, keeping on top of URL changes for those resources is a major time sink, as the links are usually spread across a wide number of pages on a library website.
I really wish the publishing companies, scholarly societies, and database vendors that are exclusively developing apps for mobile devices would rethink their preference for apps over interfaces that are optimized to work on mobile web browsers. Ever since Apple launched its app store on iTunes, web developers have been debating whether it is preferable to do a mobile web optimized site or instead release an app. Now that the vendors that libraries rely on for databases have earnestly entered the world of mobile design, there seems to be a lack of uniformity of opinion about the best way to proceed. Some companies have only released apps:
Some notable vendors have yet to release their mobile service yet. LexisNexis Academic will have a mobile interface this summer, though I’m still not clear if it’s an app or a mobile browser interface. ProQuest’s new platform for it’s databases is supposed to have mobile browser interface, but I haven’t seen it yet (I’m not sure if it hasn’t been released yet or if it requires you to switch over to the new platform, which we haven’t yet done in my library). Having tried most of the apps and web interfaces for the products above and having thought about how my library will promote them to our students, I’ve come to the conclusion that for the moment, the mobile web experience is superior to the app one. Here are the reasons why I’m not a fan of the apps I’ve seen.
Apps have to be downloaded. The user who wants to find something has to first take the extra step of installing an app.
Apps have to be updated. I don’t know if the apps that the library vendors will provide will require as frequent updates as the other apps on my phone, but even having to do it at all is an extra annoying step for our users to periodically follow.
Clunky authentication. Users have to do things like fill out a form with their app and get an email back from the vendor with a special code to be entered into the app. Other apps have to be “paired” up while the user is on the library’s or college’s network.
Idiosyncratic authentication. It’s hard enough getting our users to enter some sort of user name/password combination for most of our databases they access via regular web browsers, but at least it is a consistent experience. With apps, we’re expecting our users to get used to a variety of authentication schemes that vary from app to app. Furthermore, each app requires you to authenticate. If you use a browser to visit library databases (on a regular browser or a web one), you authenticate once that session and use as many databases as you want without having to re-authenticate each time you try a difference resource.
Apps take up space. Our library has huge ecosystem of databases. Do we really expect our users will want to use up valuable screen real estate and space in the phone’s memory with all the databases they may need?
Eclipse other databases. It’s already challenging enough to get users to recall that there are more databases than the ones with the easy-to-recall brand names (JSTOR, LexisNexis). A user who has downloaded a database app or two is going to be less likely to recall that there may be other, possibly more relevant, database options for mobile search. If you are looking at mobile optimized web page listing all the library’s mobile-friendly databases (perhaps sorted by subject, by title, etc.), there’s a greater chance they’ll use a wider variety of databases than if they’d downloaded an app or two.
App names often differ from regular web versions. Why should we add to the mental burden of our users by asking them to recall that what we call IEEE Computer Society Digital Library (an ungodly name to begin with) is the same as IEEE Xplore Mobile Digital Library (the former is the regular web version and the latter is the mobile app version)? Or expect them to know that buried in the sprawling app from Gale called Access My Library are the mobile versions of Business & Company Resource Center, Gale Virtual Reference Library, and more?
No link resolvers. I didn’t see any link resolvers in the apps. Admittedly, it’s not clear to me whether the link resolver we use (SFX) works properly in the mobile browsers I’ve used. Assuming that link resolvers can be made to work in the browser, I like that we can recreate the ecoystem of databases and link resolution that we have on the regular web. I don’t see how that ecosystem can be easily recreated in a world of mobile apps for each database.
Libraries can’t customize apps. The admin options that libraries are given to tinker with the look and feel of their web-based databases are not available with the app versions of databases.
Vendors don’t offer apps for all mobile operating systems. Very few apps come in versions for all the major mobile operating systems: iOS (for iPhones and iPod Touches), Android, and Blackberry.
Developing apps is expensive. The wish list of things I would like database vendors to fix or improve is lengthy. Spending precious time and money to develop apps is not at the top of my list. The cheaper and, in my mind, better option, is to develop for mobile web browsers first, as that lets vendors get their products onto a wider range of mobile device more quickly than if they were to take the time to develop apps for each of the mobile OSes.
I recognize that the vendors, publishers, and scholarly societies are just dipping their toes into the world of mobile services. I hope, though, that they don’t get carried away with apps and can recognize the limitations that those apps have right now.
Before installing the official Google Reader app, I tried using the mobile browser interface for Google Reader (too cramped) and the My6Sense app (not as easy to use). I’m a hardcore user of Google Reader on the web (I’ve got nearly 900 feeds plugged in) and love to share some the gems that I find every day, so having the ability to chip away at that unread items list on my phone throughout the day is great. The sharing options are pretty much the same as on the web version (share and share with note). The send options are good too; I can pass along an item to Evernote (more on that app in a later post), Instafetch (more on that Instapaper knockoff app in a later post), Facebook, Twitter, email, etc.
I’m often amazed at how many apps are running in the background on my phone, sucking away precious memory. An easy way to see what’s running and selectively kill programs running in stealth mode is Advanced Task Killer. It also gives you quick access to any notifications (new email, new text, completion of any downloads or uploads, etc).
Last December, I finally gave up my ancient phone and got a Samsung Intercept that runs Android. I’ve been madly adding apps (and occasionally removing the ones that are better characterized as crapps). I thought that with this post, I’d begin writing up quickie reviews of the apps I’ve got, noting in particular those that might be interest to folks who work in libraries.
The first app I’d like to begin with is AppBrain, which improves on the default ways that Android lets you manage apps on your phone and the way your phone works with the Android Market. To get started with AppBrain, you’ll want to install the app on your phone first and then go to the AppBrain website and create an account there. What the website offers is a way to browse and search for Android apps, read reviews of them, and then record which ones you want to install on your phone. After you’ve selected an app in the AppBrain website that you want to add to your phone, you later go to the AppBrain app on your phone and sync it to the website account. After you sync it, you can then see an option in the AppBrain app to install that new app you just found. Being able to browse apps on the web is a much better experience than relying solely on the mobile interface in the Android Market app; being able to wishlist them for later installation is unique to AppBrain.
The other notable feature with AppBrain is that you can share your list of apps with the world if you’d like. This can be hugely useful if you’d like to show someone with a brand new Android phone all the apps you’ve got on your device that they might want to consider adding. Here is what is on my phone currently: