BibIt: Choosing a UI Framework

When we were getting ready to build the BibIt application in late summer 2014, we had a few constraints—the sorts of constraints that are probably familiar to any app developer.

  • The project team had just two developers with only a limited amount of time available.
  • The project timeline was extremely tight, with the expectation of delivering a first version of the app in a matter of weeks.
  • The application was acting as a client for OCLC’s WorldCat Metadata API service and therefore would need to interact with OCLC’s Web Service Authentication system.

Those constraints led us to make some early decisions that heavily influenced other choices going forward.

  • Rather than investigate and test new software frameworks, we selected those that were most familiar to the developers.
  • For the web UI at the time, that meant using the jQuery JavaScript library and the Bootstrap front-end framework.
  • And for the web application, that meant using Ruby as the programming language to benefit from familiarity with the language and availability of a Ruby gem for the Web Service Authentication system.

Being Responsive to the Community

The Bootstrap framework remains a popular choice for web app developers, as it delivers a responsive, mobile-first solution with very little additional labor on the part of the developer. A responsive web design was important to us in any case, as we wanted the application’s users to have a satisfactory experience regardless of the type of device they were using.

But we had a particular interest in a UI framework that was designed around the “mobile-first” concept of Progressive Enhancement because of a very specific use case around which the BibIt app was designed. 

Imagine a library with an extensive collection of materials written in a language and script that the library’s cataloging staff has limited experience with. And imagine that the library has book buyers working in various locations far beyond the reach of the library, proficient in that language but without cataloging expertise. We wanted to build an application that this book buyer could use, via WiFi from a tablet, to quickly create a minimal-level cataloging record for titles that had not been previously cataloged, applying his or her familiarity with a book’s vernacular script. Once the title is added to WorldCat and the materials are shipped to the library, the cataloging staff could take over, editing the record to bring it up to full-level cataloging. A framework that was designed around mobile-first principles would help protect against the diminishment of functionality when the application was used on slower networks and on devices without keyboards and/or with limited screen real estate.

Concentrating on the Unsolved Problem

We had a range of front-end frameworks to choose from back in 2014, and there are likely even more choices now. At the time, we had already built a few other applications using the Bootstrap framework, so we went with that. But other choices, such as Foundation, would likely have worked as well. We found it especially advantageous that there was a strong community of other developers using Bootstrap, a community that has continued to add extensions and support. Other less widely used frameworks would have offered us a less active community to go to for answers to thorny questions or for Bootstrap plug-ins, which would have slowed us down. It’s also noteworthy that since we built the app fewer than two years ago, some other frameworks that were popular at the time are no longer in active development.

The way we looked at it, the problem to be solved wasn’t to come up with our own custom framework for the UI or to add bells and whistles to the user experience. The problem was how to give that book buyer a way to get a catalog record started as quickly and correctly as their potentially adverse conditions would allow. Any time we spent on writing HTML, CSS or JavaScript to make the interface custom or novel was time we weren’t spending on trying to bridge the gaps between the book, the buyer, the cataloger and the library. Until recently, we would have had to devote more time to custom UI development, as the frameworks were still maturing. But now, we’re liberated from that additional responsibility. And the application’s users arguably benefit by being given an app that looks and feels like a thousand other Bootstrap-based apps, as that pre-existing familiarity can help them get started more quickly. In particular for a utility application like BibIt, in our view, if you’re writing any additional CSS beyond what the framework provides, you should stop and reconsider.

file

Figure 1: Creating a record in BibIt

Putting the Pieces Together

Using this discipline of writing as little custom code as possible, we found ourselves taking pieces of software “off the shelf” and combining them in our app, with a little of our own code to wire it all together. Combining the Ruby Haml template engine with CSS references to the Bootstrap framework proved to be a simple way to connect the web application and its front end.

We added some additional JavaScript to help speed and to simplify data entry, including:

  • a method to quickly add or remove additional form elements,
  • a call to OCLC’s AssignFAST web service to auto-suggest subject headings as the BibIt app user types, and
  • a call to a JavaScript library that helps convert dates between Gregorian, Hebrew, Persian and Islamic calendars.

And wherever possible, we used content delivery networks (CDNs) to load the necessary Bootstrap, jQuery and other libraries. This potentially saves the user some time and data-service costs. If they’ve previously visited some other web application that used the same CDN to download the same library, it’s likely to be cached in their browser, and they do not need to get the same library again from our site.

That sums up our approach for the BibIt UI development. It’s certainly not a pattern that’s unique to us or this project, but it served us well, as we met our deadline with a functional application that could be tested and extended without our maintaining sole responsibility for anything but the pieces we couldn’t find already written by someone else.

  • Karen Coombs

    Karen Coombs

    Senior Product Analyst