While some libraries have begun to offer customized mobile applications for their online public access catalogs (OPACs), little research has investigated the relative costs and benefits associated with developing such applications. To investigate this tradeoff, we have developed a prototype Mobile search application for the University of Texas library catalog (MUT). Our experience indicates that mobile applications for catalog access can be built at relatively low cost and effort, with MUT providing a proof-of-concept for developing similar mobile applications at other institutions. Overall, our findings suggest customized mobile applications have potential to significantly better serve patrons in return for a relatively small investment in development and maintenance.
With the ubiquity of today's sophisticated mobile devices, information access has shifted increasingly away from the desktop and into mobile environments. As part of this trend, a recent article has encouraged libraries to start writing strong proposals for mobile options in this age of mobile ubiquity (Bridges et al., 2010). While some libraries have already begun developing mobile applications for searching their Online Public Access Catalogs (OPACs), thereby helping to ensure they stay abreast of the latest access technologies employed by their patrons, the perceived cost and effort may still deter some institutions from pursuing such applications. What institutions would like to better understand, of course, is the degree of benefit such customized applications deliver, and at what expense.
Although mobile devices have been in popular use for some time, today's mobile devices boast large color displays, high resolution, multi-touch capabilities, significant computational horsepower, and high-speed connectivity. In combination, these features dramatically alter the possibilities and experience of mobile information access today in comparison to even just a few years ago. The rich developer tools available for today's mobile devices also make it easier than ever to build and deploy mobile applications. While these technological advances suggest a variety of promising opportunities, our community lacks a detailed understanding of the capabilities and costs associated with developing customized catalog access applications for this latest generation of mobile devices.
Consequently, we investigate the following questions:
What are the benefits and cost tradeoffs involved in providing customized mobile applications for catalog access? What advantages or disadvantages do mobile search interfaces offer compared to standard browser-based access on a mobile device? What resource expenditure is needed to develop customized mobile applications for catalog access?
What are typical users' search needs when searching a library catalog on a mobile device? Which OPAC features are most important when searing in a mobile context? What do users perceive as important features in general in using mobile search applications?
What are essential interface components for mobile library access? What features have other institutions included? Are there needs that have not been met in their designs? Are there standard mobile application layouts that should be honored in designing mobile search?
To explore these questions “hands-on”, we designed, built, and performed a preliminary evaluation on a prototype catalog Mobile access application for University of Texas library catalog (MUT) based on the Google Android mobile platform (Figure 2). Our experience suggests such an application can be built to provide basic functionality with relatively little effort and deliver a significantly improved user experience in comparison to a traditional browser-based OPAC.
The following sections begin by outlining how related work informed our initial sketches and ideas for MUT. We then survey similar applications and the standard features. Following that, we describe the MUT prototype. In the analysis section, we discuss the potential success of the prototype. Finally, we discuss future work and conclude.
Search has become a ubiquitous alternative to browsing, especially for mobile devices and information needs (Church and Smyth, 2007). A follow-up study of users' interaction with their results suggests that mobile phone searching is moving toward portal search that is application based searching for specific tasks rather than a one-size-fits-all application (Church and Smyth, 2008).
Similar trends have come forward in web search studies, and task-specific searching has emerged as an important research topic. Specific search is often referred to as a vertical and users may often get results that better match their need from using engines that cater to verticals or aggregate results from them (Arguello et al., 2009).
Due to the explosive growth of mobile devices library services on mobile device are growing in popularity. Many academic libraries now offer services and collection access via mobile interfaces. (ACRL, 2010)
Kamvar et al. (2009) stress the importance of personalizing the search experience for mobile phone use cases. Task specific searches can be better designed to serve a user's needs. Users are interested in built-in applications to support various specialized searches (Sohn, et al., 2008).
De Luca et al. (2005) stress that design for use on mobile devices must provide improved navigation and visualization of result sets. These methods enable a user to retrieve documents with fewer interactions and less data traffic. This means that mobile search application should provide a concise overview of the essential elements of a result set rather than a smaller version of everything on a web page.
A study of patterns among mobile search users showed that short queries of just over two words are still the most common, although the trend is toward longer queries. (Maghoul and Pedersen, 2008). However, users may not want to enter keywords at all according to Karlson et al. (2006). They use data filtering or “facets” to aid users in searching without needing too much text and claim that, “spatial arrangement and hierarchical structure of facets holds great potential for search.” They suggest users want text searching capabilities and facet navigation.
Table 1. Overall mobile catalog feature comparison
Notes about feature
Search box and button
Always on front page; Usually on same line
Search type options
8 of 10
Ball State use checkbox layout; all others use drop down menu
3 of 10
Only WorldCat, DCPL, NCSU provide the cover image
Author and title
Usually included on initial results list pages
Status of book
9 of 10
WorldCat did not provide unless clicking on the specific library page.
Call number and location
Usually included on detailed results page.
1 of 10
Only WorldCat provides a scan feature; it is a paid app only for iPhone users.
In researching prior work at peer institutions, we considered both academic and public libraries with applications focused on catalog access. We did not consider museum or exhibition-focused applications, or applications focused on library location finding. Our survey included ten institutions: The New York Public Library, North Carolina State University, The Washington DC Public Library, Nashville Public Library, Ball State, University of Richmond, University of Virginia, and WorldCat.
Overall, current applications are similar to one another (Table 1). The main difference is in the colors, layout and design of elements. One major difference was that WorldCat provided a picture of the cover of the retrieved book, while most other library applications did not. The following describes the trends we observed.
Search box and button: Typical applications surveyed included a search bar with a “go” button on the same line.
Search type options: Also, a drop down menu that had selection options for searching be keyword, title, author, or other standard library options was common (Table 1).
Cover image: Few applications included a cover image.
Author and title: These elements were commonly included and received a prominent place in both list and detail views.
Status of book: All applications except WorldCat included this, and it was usually prominent in list and detail views.
Call number and location: All surveyed applications included this metadata, but it was usually on the detailed page, and not the initial list of results page.
Scan: WorldCat was the only application that provided a scan option for the ISBN of books (a paid option).
Of the applications surveyed, WorldCat often took a different approach, perhaps because it is an aggregated search of catalogs rather than an institution-specific application. The features common across applications were that each one included a menu bar and at least three views: an initial search view, a results list view with basic information about the books, and a detailed item view that provided more information about selected books or objects.
The initial search view of the applications included the search box, which usually defaulted to a keyword search and often had; a dropdown with the search type options, a drop down with other options such as locations, and an advanced search option (Figure 3).
The results list view includes abbreviated information on the book list, most importantly author, title, and status. The detailed item view included the same information, as well as location (call number and library), publisher, and sometimes the cover image. As libraries increasingly provide mobile applications, using standardized features should help users adjust to the new interfaces. This means both adapting existing interfaces such as the current OPAC to the mobile interface, and honoring established designs.
Using the Android environment, we designed a test application for Android phones with the critical elements we had found in our requirements gathering. MUT was made up of three search views: the front page where the search was conducted, a results list page with the title and author of up to fifty results, and an item view with details about a specific result.
Designing MUT as a mobile website rather than an application, or using an iPhone platform were also possibilities; designing MUT as an application with Android allowed us to add a “scan” function using open-source software to access any built-in phone camera. However, tailored mobile versions of websites are generally more utilized in the United States (Kaikkonen, 2008), so more research is needed on whether the extra capabilities of a phone-specific application are worthwhile.
The Android Software Development Kit (SDK) is a Java based programming language for Android applications. Developers can download the SDK and an emulator at no cost. For implementation, we used Eclipse, an Integrated Development Environment (IDE) that is compatible with the Android SDK, for programming the prototype. Rather than classes, Android uses the terminology, “activity”, or “service”. Android uses XML for its layout.
Android applications are bundled into packages with the extension “.apk,” and can be easily downloaded and installed on Android enabled devices. Android instructions and several open source packages are available online in forums or on the official site. Our familiarity with Java, the free and open-source nature of the platform, and the availability of an emulator and a test phone (the Motorola Droid A855) made the platform an ideal prototype choice.
The first challenge we encountered was retrieving results from the data set. Since the UT library catalog does not provide a publicly available search API, we worked around this by accessing the UT library results page via an HTTP call and parsed the results book page, and a no result found page. We used the Java function indexOf to locate each element we wanted to return.
Lacking an API, parsing the HTML was the best solution for us, but may have had an effect on the execution time of our search. A more robust solution would be to utilize an available API. Providing APIs offers the additional advantage of providing the opportunity to crowd-source work as a community. In addition, the HTML source code, which MUT parsed, was likely to be different according to the results returned so is not extensible enough.
From the menu in MUT, users can also select “scan” option. This option uses the zxing package11 to scan the ISBN of a book and return whether or not the book is in the UT library. If it is, users can view details about the book in the same manner as if they had searched for the book. The detailed item page also includes four icons at the bottom that link to additional functions for the application: view the book on Amazon, email the book, place a hold on the book, and save the book to a personalized list.
Our experience suggests that in comparison to existing browser-based OPACs, libraries can build simple, well-liked mobile applications at relatively low cost and effort. In our case, two graduate students with minimal Java programming experience, working a combined 20 hours a week for four weeks were able to build a working prototype. We believe other institutions stand to similarly benefit by developing customized mobile applications, and we hope MUT and other similar projects can serve as concrete examples to generate ideas and proposals.
We anticipate that mobile application maintenance can be minimized by designing these applications as thin interface layers atop a regularly maintained catalog access API. Use of a free and open-source platform such as Android seems well suited to needs of libraries since it is easy to obtain, is highly customizable to meet local needs, can be maintained even if a company goes out of business, and provides an opportunity to leverage volunteer (crowd) developers.
Our future work on MUT will explore features such as allowing users to download electronic resources, providing self-checkout functionality via barcode scanning, and guided navigation from a user's current location to the location of a given physical resource via a library map. Also, more inquiry into the distinctions between platforms (mobile sites, iPhone, or Android applications) is needed.
We would like to thank Google for their generous support via the Android for Education program, Brandon Wiley for his programming suggestions, and Luis Francisco-Revilla and the anonymous reviewers for their valuable feedback.