|Buzzy Nielsen||Nov 7, 2012 3:58 pm|
|Dan Scott||Nov 7, 2012 4:28 pm|
|Buzzy Nielsen||Nov 7, 2012 4:42 pm||.png|
|Dan Scott||Nov 7, 2012 5:11 pm||.png, .png|
|Dan Scott||Nov 7, 2012 5:30 pm|
|Jason Stephenson||Nov 8, 2012 5:45 am|
|Ben Shum||Nov 8, 2012 6:06 am|
|Bill Ott||Nov 8, 2012 6:15 am|
|Dan Scott||Nov 8, 2012 6:34 am|
|Kathy Lussier||Nov 8, 2012 7:43 am|
|Dan Scott||Nov 8, 2012 8:24 am|
|Buzzy Nielsen||Nov 8, 2012 11:30 am|
|Aaron Zsembery||Nov 8, 2012 1:10 pm|
|Dan Scott||Nov 8, 2012 1:13 pm|
|Subject:||Re: [OPEN-ILS-GENERAL] Mobile catalog?|
|From:||Dan Scott (da...@coffeecode.net)|
|Date:||Nov 8, 2012 8:24:33 am|
On Thu, Nov 08, 2012 at 10:46:53AM -0500, Kathy Lussier wrote:
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.