Anatomy of a Library App

For past couple of months, I've shifted my design and development of the FRBR-Redis Datastore project to its Aristotle App Framework use. An important piece is coming up with a Tutt Library Django HTML5 template that other app developers can easily use in their own library apps.

This blog posting is longer (&TL;&DR version, the next iteration of the Aristotle App Framework simplifies library app developers with a standard UI elements as suggested by Apple's and Google's recommendations for iOS UI Guidelines and Android Design for mobile and tablet apps) but also includes more background and a small section regarding the system administration (as promised in last week's New Discovery Layer and Apps blog posting) of our library discovery apps.

Growing Importance of Mobile

As a recent TechCrunch blog posting, HTML5 Features Can Drive Up Mobile Websites' Usage By Up To 28%, notes, just by using geolocation with a mobile HTML5, app, users can shift their geolocation context to the app, increasing the utility and usage of a library's collection.

Another blogger I follow is Peter Warden's recent blog posting about Facebook's acquisition of Instagram, draw this conclusion about the significance of mobile app first approach:

Facebook is keenly aware of how important mobile is, but they're facing a classic innovator's dilemma where their core web business will suffer if they really prioritize phones and tablets. Bringing in the pioneers in mobile-only applications can't hurt as they wrestle with the changes they know they need to make.

This is why, our design approach to refactor and replace core library technology, including our legacy ILS, with a portfolio of library apps, makes sense given the current push by these large technology companies. Going an "app first" design means we can disintermediate currently embedded workflows in larger library systems into semi-autonomous HTML5 apps that improves the user experience for staff and patrons.

Anatomy of a Library App

I used an amalgamation of both Apple iOS UI Guidelines's and Google Android Design's user interface suggestions to simplify development of a standard library app in Aristotle. A Library App will usually be made up four sections labeled in this snapshot of the Portfolio app:

1. Navigation Action Bar

   The Navigation Action Bar contains the App's icon and name with the insitution's logo, followed by drop-down action button that can be replaced/overridden by the app designer.. Normally this view button should contain quick access to other important views, in the case of the Portfolio app, the drop-down options are the Discovery and Access view and the Productivity view.

2. Top Action Bar (Optional)

   The Top Action bar provides the app designer a place for secondary actions specific to the current app view. In the Portfolio app, the Top Action Bar contains the three different views; all of the apps, just the Discovery and Access view and finally the Productivity view.

3. Main Pane

   The Main Pane is the location for most of the display or actions for the app. If the app does not have a Top Action Bar. the Main Pane will fill that space. The Portfolio app's Main Pane contains a listing of apps for the user.

4. Footer Action Bar

   The Footer Action Bar is part informational and part action. There is a button to link directly back to the user's app portfolio, an about button and help buttons that the app developer provides content for, and a link back to the Home, however Home is defined for the app, in this case to the root Library App Django instance.

Redis, VMs, nginx, and uWGI/Django

For access and discovery apps, the Aristotle Django Apps will use the Redis access host running on our production Solr virtual machine (VM). We may need to increase the available RAM to fully support a fully-replicated Redis datastore of our master Redis datastore.

The VM hosting the master Redis datastore also runs our PostgreSQL databases that primarily support the Django administration layer. The PostgreSQL and master Redis datastore are accessed after the user authenticates through either the library ILS or in the near future, with their college LDAP network credentials. Only productivity apps should ever need to access the master Redis datastore. Any changes are immediately propagated to the access Redis datastore on the Solr VM.

Our forward facing Discovery server runs two separate Python Virtual Environments using virtualenv. The first virtualenv runs the dedicated Aristotle discovery layer, the second virtualenv runs the FRBR-Redis Datastore Aristotle App Framework. Information can be pulled from the Apps and be embedded in the library's new dotCMS website as well as in the Discovery layer itself.

One of the final steps I still need to figure out is how run each virtualenv in a seperate uWSGI processes and then use nginx's virtual hosts to correctly serve and route traffic from discovery.coloradocollege.edu to the discovery layer vitualenv and traffic from discovery.coloradocollege.edu/apps to the second virtualenv.

To better support uWSGI, I will need to migrate both Aristotle and FRBR-Redis Datastore Aristotle App Framework from Django 1.3 to Django 1.4.