[OPEN-ILS-GENERAL] Mobile catalog?

[Kathy Lussier]

Hi all,

I don't know the best way to develop and maintain an Evergreen mobile 
site, but I wouldn't say the native catalog is particularly mobile 
friendly. The GRPL example is much closer to what I would call a mobile 
friendly site. I would expect the mobile catalog to be more stripped 
down than the native tpac skin. I visited some 2.3/master catalogs after 
reading the initial e-mail, and I still need to do zooming as soon as I 
reach the catalog to read the screen. What I would envision on a truly 
mobile site is:

1. On the main catalog page, I am immediately presented with a search 
box front and center, similar to what happens when I arrive at Google's 
mobile site. Font sizes should be bigger so I don't need to zoom. I 
would expect the filters to be below the search box to fit to the screen 
better, as we see in the GRPL mobile site. However, even on the GRPL 
site, I need to zoom to get that search box front and center. A 
prominent link to "My Account" would also be needed. Many libraries use 
the bottom space of their main page for graphic images, search tips, or 
other extraneous material. I wouldn't want to see that piece of the page 
displaying on a mobile site because it takes up valuable real estate.

2. On the search results page, I want to see a list of titles that, once 
again, is front and center without the need to do any zooming. I think 
the bibliographic information should be minimal on a mobile site and the 
"place hold" link prominent. I would also like to see the call number 
for the library I am searching here. We often think of users searching a 
mobile catalog from home, but, as a library user, I never use the public 
catalogs in my library anymore. I find it much more convenient to walk 
around the stacks with my iPhone in hand. I would either entirely 
scratch the facets on the search results page or find another way to 
provide access to them. For example, in a typical browser, Amazon 
provides limiters in the left sidebar of its search results. When I 
access Amazon on my phone, those limiters are located at the bottom of 
the screen, and I get a "Choose a Department" option at the top of my 
search results that brings me to those limiters.

3. The mobile catalog should also have the ability to link to the full 
version of the catalog (as I saw in the GRPL example) so that people who 
want to access added content or features can do so. In those cases, the 
person is actively choosing to do that pinching and zooming dance.

4. Geolocation would also be a great addition to the catalog, 
particularly for consortia and multi-branch libraries. It could identify 
the library that is nearest to the user and possibly set it as the 
default search location.

I don't remember where I saw them, but I recall seeing some screenshots 
last summer from the GSOC project to build an Evergreen Android app. If 
I remember correctly, the app did a lot of the things identified above. 
Personally, I prefer a mobile site over an app because I'm guessing some 
users won't want to go through the trouble of downloading an app to 
search the catalog. Also, as an iPhone owner, the Android app wouldn't 
be useful to me.

I'm curious if others have thoughts on what would make the catalog more 
mobile friendly.

Kathy

Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
klussier at masslnc.org
Twitter: http://www.twitter.com/kmlussier

On 11/8/2012 9:34 AM, Dan Scott wrote:
> On Thu, Nov 08, 2012 at 09:06:13AM -0500, Ben Shum wrote:
>> I think you're thinking of the Bill Erickson's "Beanstalk" simple
>> TPAC that was a sample mobile catalog. http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/beanstalk
>>
>> Also, I guess Bill Ott, GRPL took that code and ran with it some.
>> See http://catalog.grpl.org/eg/tinypac/home which is what I get when
>> browsing them from my phone.
> Yep. I will admit to deliberately not mentioning beanstalk in my initial
> response because I think the approach of carving out different sets of
> HTML for different browsers (whether mobile or desktop based) is
> difficult to test and maintain, versus defining the content that you
> want in your HTML once and changing the layout via CSS based on the
> display capabilities of the consuming browser. And it seems that Google,
> at least, agrees that responsive design is the best practice:
> https://developers.google.com/webmasters/smartphone-sites/details