[OPEN-ILS-GENERAL] Mobile catalog?

Dan Scott dan at coffeecode.net
Thu Nov 8 11:24:38 EST 2012


On Thu, Nov 08, 2012 at 10:46:53AM -0500, Kathy Lussier wrote:
> 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.

Thanks for the concrete suggestions. Almost all of this can be achieved
via CSS, possibly with some changes to the underlying HTML (e.g. tables
to divs or whatever so that "Place Hold" appears under the bib info
instead of way over to the right). I don't see anything that suggests a
need for two distinct versions of HTML in your wish list.

Geolocation functionality could be supported for desktop browsers too,
but be careful in how you implement it. If you go to branch1.example.com
in your browser and get redirected to automatically searching branch2
instead of branch1, that's probably going to break user expectations.


More information about the Open-ils-general mailing list