FEATURE
BookMeUp: Creating a Book Suggestion App
An Experiment With HTML5, Web Services, and Location-Based Browsing
by Jason Clark
Most readers of this publication will appreciate the fact that a reader’s advisory service has been a core component of public library reference services dating from the beginning of the 20th century. This practice of conducting a reference interview to find people’s interests and tastes and then offering them pertinent books to read has wavered as traditional reference services have become less about guiding readership and more about focusing on research needs. But in thinking about how we could provide better discovery services to our library patrons, I became interested in the ways we might move the classic practice of reader’s advisory services into our digital library environment.
The rise of apps and mobile devices has opened the door to small, dedicated software programs that are focused on singular tasks. From my perspective as head of digital access and web service manager at Montana State University, these apps offered an opportunity to build a focused digital service aimed at allowing someone to enter a search for a title or subject, match an item, and then receive a list of suggested related items. In essence, it would be a user-mediated reader’s advisory. The result was BookMeUp, a web app prototype incorporating many of the emerging features of HTML5 to work across smartphone and tablet platforms as well as on the traditional desktop.
Going the Way of HTML5
As I worked through the idea of a book suggestion app, I started to sketch out a few requirements. The following is among the top-level functional requirements:
- Compatibility with existing skill sets in the organization
- Ability to rapidly iterate and prototype
- Access to the internet for using web services and APIs
- Access to geolocation hardware or settings on desktop computers and mobile devices
- Ability to scale the app into multiple design environments: desktop, smartphone, tablet, etc.
With these basic requirements in place, it became clear that an HTML, a PHP, a JavaScript, or a CSS solution could work and might even be the preferred option. First, this solution took advantage of the common web development skills in place at our library, as HTML, PHP, CSS, and JavaScript are required, core skills of our digital team. There wouldn’t be any need to invest time in learning the Objective-C (Apple) or Java (Android) programming languages or software development kits.
Additionally, the instant publishing model of an HTML-based web app allowed me to work live and to rapidly develop using only a web browser and an internet connection. During this development phase, I could test and work through bugs immediately and wasn’t subject to Apple App Store restrictions, laggy patching, or software deployments. The web app option also gave me access to the network on which my app could make continual HTTP requests for remote web service data and other dynamic data for page views.
The JavaScript and the geolocation API (related to the HTML5 spec) enabled a location-based facet for the app. And finally, the use of CSS with an eye toward responsive design would allow the app to scale into multiple environments such as those for smartphones, tablets, and desktop computers.
With all of these advantages, I looked to push at what was possible and looked to some edge cases that could make web apps behave like the native apps you might find in the App Store. Voice input with Google Chrome and some simple HTML were included in one of these experiments.
Once I started to grasp some of the possibilities with the device APIs coming from the HTML5 spec, the argument to build the app using common web development techniques became even more compelling.
It’s the Algorithms That Make Suggestions Possible
Data mining and machine learning algorithms have been around for quite a while. Finding ways to personalize user experience by filtering a view of data as it relates to a particular person is just one application of data mining and algorithms. More recently, similarity algorithms and the “More like this” relations paradigm have become commonplace in search and browse interfaces.
Until recently, libraries have been using very simple ways to describe and define similarity relationships between items. Tags, Library of Congress subject headings, even simple related keywords have been used to build a network of related items. These methods often rely on matching related patterns of strings, and they work by associating exact alphanumeric strings from one record to another. This model can hold up on a very generic level, but eventually, the nuances of the relationship break down. And here’s where similarity algorithms can be applied to pick up the slack. Consider the uncannily accurate Amazon recommendation system, which suggests similar products that customers have purchased as related to the current product.
Netflix uses association learning models to suggest related items for users. Association learning models work to re-create the intentions of the user by recording and learning similar behaviors between common items and the people who browsed these items. The move away from simple pattern matching to intention recording and learning the relationships between similar users are what make these newer forms of recommendations compelling.
Why Reinvent the Wheel? Just Apply Web Services
Fortunately, these association algorithms are not completely hidden. In fact, many internet companies and organizations are making pieces of their service data available via web services. The Amazon Product Advertising API is one of these web services that can be used under certain terms of service (http://goo.gl/Vmhll) to collocate related items using Amazon’s data. Another feature of this API is the rich amount of book data related to each item returned; standard metadata such as ISBN, cover thumbnails, author(s) names, and prices. Using this API requires registering as an Amazon Associate and acquiring a developer key that allows Amazon to identify you and your application. (Note: Additional cover images, used when there are gaps in thumbnail coverage, can be retrieved from the Open Library Covers API at http://goo.gl/p529z.)
Once registered as an Amazon developer, I was able to build a PHP script that made a call to Amazon’s web service using the search form input on the main page view of the BookMeUp app. When the results are returned to the BookMeUp app public interface, the user is given the option to check within WorldCat to find the location of the item. The request from the PHP script to the Amazon API has the following parameters:
<?php
…
$parameters=array(
“region”=>“com”,
“AssociateTag”=>“jasonclarkinf-20”,
“Operation”=>“ItemSearch”,
“SearchIndex”=>“Books”,
‘ResponseGroup’=>‘Images,ItemAttributes,EditorialReview,Reviews,Similarities’,
“Keywords”=>“$q”);
…
?>
One thing to note is that the programming in the BookMeUp prototype app is specifying that only books within Amazon’s catalog are to be searched. SearchIndex is the parameter controlling this option, and you could set it to look at other indexes or everything in the Amazon catalog. A successful call to the Amazon API returns formatted XML, which is used to create the display for a specific book item and the related books that the app uses as suggestions. Here’s an excerpt from the XML file that has the suggestions:
…
<TotalResults>27</TotalResults>
<TotalPages>1</TotalPages>
<Item>
<ASIN>B0007MZV3C</ASIN>
<ItemAttributes>
<Manufacturer>Back Bay Books</Manufacturer>
<ProductGroup>Book</ProductGroup>
<Title>Me Talk Pretty One Day</Title>
<SimilarProducts>
<SimilarProduct>
<ASIN>0316777730</ASIN>
<Title>Naked</Title>
</SimilarProduct>
<SimilarProduct>
<ASIN>0316078913</ASIN>
<Title>Holidays on Ice</Title>
</SimilarProduct>
<SimilarProducts>
</ItemAttributes>
</Item>
…
Within the XML file returned by the Amazon API, the SimilarProducts tag is where the BookMeUp app gets the suggestion info, and that info is the key behind the whole BookMeUp app. I don’t mean to trivialize the workings of the PHP script, because there is a whole lot going on. To see all the details, please have a closer look at the code by downloading or forking the BookMeUp source code available from my site (www.jasonclark.info) or on my GitHub account (https://github.com/jasonclark).
Building Location-Based Recommendations Using APIs and Cloud Services
Another feature I had sketched out in my requirements was a location browse point. Part of my logic here was that an important part of a reader’s advisory was context. That is, where a person was standing in time and space could be used in determining what he or she might want to read. To this end, one can write JavaScript that can be used to call the geolocation API (a spec related to HTML5) and get some information about where a person is located. The BookMeUp JavaScript geolocation call is as follows:
if (navigator.geolocation) {
navigator.geolocation.getCurrentPosition(getSubjects);
console.log(‘geolocation done’);
} else {
alert(‘Error: Your browser doesn\ ’t support geolocation.’);
The results returned are geographical coordinates (latitude and longitude) based on where a person’s device is located on the network. Once you have these location values, you can start to use them to create some interesting relationships between someone’s current location and items related to that location.
In the case of BookMeUp, the coordinates are used to make a call to OCLC’s mapFAST service, an experimental web service that matches geographic subject headings to latitude and longitude values. An example request from the BookMeUp JavaScript to the mapFAST service might look like this:
http://experimental.worldcat.org/mapfast/services?geo=“ + lat + ”,“ + lon + ”;crs=wgs84&radius=100000&mq=&sortby=distance&max-results=25
In the example, “lat” and “lon” would be the retrieved values from the previous geolocation request. Here’s the real power of mapFAST: The request shown returns subject headings in the form of structured data that can be used to create an HTML display of subject headings. Using this information, the BookMeUp “Where?” page (www.lib.montana.edu/beta/bookme/index?view=where) prints out links of subject headings that can then be passed to the search of the Amazon Product Advertising API, and recommendations based on subject headings of the user’s current location are returned.
Next Steps and Future Plans for BookMeUp
With the prototype for BookMeUp in hand, I brought the demo version to the public services team members to see if they thought it had any legs and, if so, to get their suggestions for refining the app. In my experience, pitching a project always works better if you have a working prototype to help shape the discussion, and this case was no exception. Comments focused on the design and inter face with specific suggestions for integrating the service into established library software. Among the highlights of the discussion, the team suggested the following:
- Integrating the service to point at item-level records in the local library catalog
- Opening the suggestions scope to include a wider range of items such as movies
- Introducing and promoting the project through library channels such as the library blog and Facebook
As the discussion ended, I started to think about places where the technical pieces of the app could be improved:
- Caching the most commonly used files in the app to help with performance (cache manifest file)
- Using CSS3 media queries to create unique displays for multiple environments
- Using CSS3 to create “touchable” buttons that work better in handheld environments
- Creating search suggestions to help guide users to successful queries
- Providing the ability to share and bookmark book recommendations
- Encoding book recommendations in common formats such as BibTeX, EndNote, and RefMan
- Setting up SMS and/or texting capabilities to allow the app to push recommendations to cellphones
Since there was sufficient interest within the library for developing the service, the next step will be to create a working group to collaborate on the final development of BookMeUp.
Where we go with it remains to be seen. But the most empowering aspect of the approach so far has been the way that HTML5 and common web development techniques have opened the door for simple prototyping. As we continue with the full development work, these same capabilities promise to help us quickly and efficiently build out a service across the multiple platforms people are now using every day.
|
