Featured Collection Catalog

GitHub repo

• Why I chose this project
• Software design process
  • Planning
  • Implementation
  • Technical details
• Challenges faced
• Lessons learned
• Future development ideas

This mobile app is essentially a library catalog intended to feature subsets of a library’s holdings, allowing patrons to better discover lesser-known items.

Why I chose this project

The public library I previously worked for constantly added fun, unexpected items to its collection for checkout, including bicycles, GoPro cameras, Nintendo Switches and more. The library called these nontraditional items its Beyond Books collection.

We marketed these items to the public in a variety of ways, and they can all be found in the library’s catalog, but unless you know the library offers them, you wouldn’t know to search for them in the first place. That’s why I chose to pursue this project as a way of improving the discoverability of these nontraditional items by showcasing, isolating and organizing, in this case, the Beyond Books collection in a way useful to patrons.

Software design process

Planning

I initially planned for these features:

• Organize items into categories: The library currently does not do this, and I thought it’d be helpful to patrons as an entry point to the Beyond Books collection.
• Provide list of all items in collection: Some patrons, however, will still want to see the entire Beyond Books collection.
• Allow patrons to save items for future reference: Bookmarking capability for patrons to easily return to the records for their favorite items.
• Integrate with the existing library catalog’s API: Pull records for only items in the library’s Beyond Books collection, including description, status and library branch locations.
• Map which library branches have the item available: Display a map of which library branches currently have Beyond Books items available for checkout.

Implementation

Using the library catalog API didn’t work out (see “Challenges faced”) so I manually pulled data on the library’s Beyond Books items to populate my app.

I organized the Beyond Books items into categories (though they’re structured more as tags, since items can fall into more than one category). That way patrons can get a quick sense of the types of items on offer, particularly since the Beyond Books collection carries a wide assortment of unrelated things. For patrons who simply wanted to see everything, I provided an “All Items” list.

All item records have a heart icon that you can tap so that the item will display in your Favorites list. A subsequent tap makes the item disappear from Favorites.

Each item has an “Item Locations” button which, when tapped, takes you to a map of which branches in the library system carry this item. Tapping on a map marker bumps the patron over to Google Maps so the patron can get directions to the branch, as well as additional info such as branch hours.

Technical details

• App built with JavaScript and React Native framework.
• Collection data stored locally.
• Favorites data stored to Firebase.
• Packages useful to the project’s implementation:
  • Firebase
  • React Native Elements
  • React Navigation
  • React Native Maps

Challenges faced

Up to this point in my Mobile Applications Development class, the APIs we’d used were open to the public. So when I began this course project I had naively assumed I’d be able to hook into the library catalog’s API to extract records for Beyond Books items, their status (whether they were available or not) and their location. This did not prove to be the case since the API is closed to non-clients.

Since the project assignment required an API integration of some sort, I turned to the Google Books API and implemented manual keyword searches for related titles. Tapping a book in the Related Reading list takes you to the book details in Google Books.

In addition, lack of access to the catalog API meant I couldn’t pull live data on the availability of items and their location. My workaround was to manually extract the list of branches that carry each item and implement them into the map function.

Although most items (books, DVDs, music CDs, audiobooks, etc.) in the library’s collection float — i.e., they don’t have a home library branch; they are shelved at whichever library branch patrons return them to and transferred to whichever branch has need of them based on patron demand — the Beyond Books collection does not float: Beyond Books items must be checked out at, and returned to, their home library branch (and not all branches carry the same Beyond Books items).

As a result, my workaround was sufficient up to a point. This approach, however, risks patrons going to a branch thinking they will be able to leave with the Beyond Books item when, in fact, the item may already be checked out or on hold for someone else.

Finally, one feature that stymied me for quite a while was implementing the visual representation of the Favorites feature, the toggling between Favorited and Not Favorited and updating the state. After much trial and error and searching online, I finally settled on:

const [toggle, setToggle] = useState(false);

const toggleFunction = () => {
    setToggle(!toggle);
};

const renderHeart = (item) => {
    return(
        <TouchableOpacity onPress = {() => {
            if (toggle == false) {                
                toggleFunction();
                storeFavoritesItem(item.id);
            } else {
                toggleFunction();
                // Locate Firebase object with key matching key in favorites array
                let obj = favorites.find(element => element.itemID === item.id);
                deleteFavoritesItem(obj.firebaseID);
            }
        }}>
            {toggle ? <AntDesign name='heart' size={18} color='#DB6860' /> : <AntDesign name='hearto' size={18} color='black' />}
        </TouchableOpacity>
    )        
}

I am still getting used to using JavaScript’s ternary operator.

Lessons learned

Honestly, I think the main lesson this project taught me was to be flexible: A plan will only take you so far but as pieces start to become concrete and come together, between my burgeoning knowledge of JavaScript and React, external factors I can’t control (in this case, the library catalog API) and a hard deadline, I needed to be able to take detours when I hit a roadblock.

In this case, I adjusted by manually extracting item records, making that data static for the time being, and relying on an unanticipated API (Google Books) to further flesh out the app.

Without the constraints of the assignment’s requirements, I’d actually try a version that hides some of the functionality until that direct connection to the library catalog can be achieved. Otherwise, it’s confusing to patrons: They see a map of where these items are located, but they may not actually be physically available for pickup. Or they see a list of related book titles, but those titles are not necessarily in the library’s catalog.

That confusion risks outweighing the benefits of marketing the Beyond Books collection via the app by muddling patron perception and possibly weakening patron favor.

Future development ideas

• Ideally this app would have access to the library catalog’s API so it can pull live data on Beyond Books items. This would allow for a more accurate representation of the collection and a more seamless experience (i.e., patrons can log in and take actions like placing holds without having to leave the app and go to the library’s catalog).
• More consistent storage: Currently collection data is stored locally and Favorites, to Firebase. Ideally all data would be stored in the same place, most likely remotely.
• Staff-side interface to allow the library to choose and configure which subsets of its collection it wants to feature based on a variety of settings, such as format, genre, audience, language, etc.
  • Sometimes, due to library policy, items cannot be placed on hold at all. Staff should have access to a setting that allows them to hide the Place Hold button on these items.
• Ability to showcase multiple subsets of the library’s collection in separate discrete instances.
• A more robust Related Reading list that is directly integrated into the library’s actual collection that dynamically generates titles based on, for example, those with subject headings in common with the featured item.