User Experience, the Repository Browser, and the Local Fedora Object Store

Guiding assumption and use case

We conceived of the Bamboo Research Environment (RE) as a web site in which scholars would collaborate around the application of tools to digital objects. Which digital objects? Which tools? Collaborate with whom? That scholars would ask these questions in this order was in many ways the principal guiding assumption underlying the design of the RE user experience. A scholar would have objects, which in practice means storing them. She would apply tools to objects to produce analytical results or derivative objects. Any number of tools might be applied. She would develop and attach metadata to objects. She would share objects with collaborators. In each case, objects are the starting point, and everything else can be thought of as an operation on objects.

While we imagined that an RE could eventually be applied to digital objects of any type, our brief was to work with texts, and of these, with codex books in particular. We had modeled books as a hierarchy of containers with metadata attached to each container and with the innermost containers containing primitives. What counted as a primitive depends on the purposes of the analysis a scholar performs and, given the stage of her work, the raw materials with which she works. In the earliest stages of work on a book obtained from HathiTrust, the raw materials are page image files and the OCR for the text on the page. The innermost container at first, then, is a page, which contains two files representing its manifestations. Higher level containers include the book itself.

The principal, guiding use case for our prototype design of the user experience was a workflow that begins by obtaining a book from a repository such as HathiTrust through the Bamboo Collections Interoperability Hub, then storing the book locally, marshaling the book as a whole or in part to one or more tools, and finally storing or presenting the objects/data produced as the outputs of tool operations.

In casting about for a model for the user experience, it struck us that both Mac OS Finder and Windows Explorer provide an attractive way of displaying a hierarchy of containers (folders/directories) and primitives (files), a well understood means of moving objects (drag and drop), a means of previewing the content of a file, and a means of selecting a tool (program) to apply to an object. Because the primitives in our guiding use case are files, constructing a user experience that imitates the behavior of Finder and Explorer would help users orient themselves in a collection of books and the contents of books, and apply tools to objects. The RE equivalent to Finder or Explorer was dubbed the Repository Browser.

In imitating Finder and Explorer, our idea was to present users with tools based on the type of operations that could be meaningfully performed on the selected container or primitive. The underlying Bamboo Book Model type for the selected item acts as a kind of MIME type. Tools and workflows are mapped onto the Book Model types. The Repository Browser, then, would present users with a menu of sensible choices among the tools configured to run within the RE (or to be invoked by proxy through a web service call) for any selected object.

Implementation

The Repository Browser was implemented in Javascript, HTML, CSS, and PHP and follows the Model, View, Controller design pattern. The View is rendered in the browser using JQuery libraries, including the JQuery tree component and AJAX to communicate requests to the Controller. The Controller was implemented in PHP as was the Model, which was built on the Apache Chemistry CMIS client (see Bamboo Book Model - CMIS Binding and Fedora Repository Implementation {{ADD LINK HERE on migration to wikihub (sjm, 29 Apr 2013)}}).

In our first implementation, we wrapped the Controller in Joomla Component code so that the Repository Browser could be imbedded in HUBzero, a Joomla based scientific research collaboration tool. By embedding the Repository Browser in Joomla, we could ride atop Joomla's authentication and authorization context without having to implement this functionality ourselves.

We later ported the Repository Browser to Drupal by wrapping it as Drupal 7 Module. This demonstrated the portability of our design. The view code could be ported with no alteration beyond embedding it in the view delivery pipeline of the hosting environment. Ports to non-PHP languages and frameworks could be easily imagined, particularly if there exists a Chemistry implementation in the language.

Supported operations

1. Hierarchical navigation
2. Folder creation
3. Object upload
4. Zotero bookmark file upload and object retrieval/normalization in the CI HUB 
5. Side by side display of local and CI HUB repositories
6. Object copy from the local repository to the CI HUB 
7. Preview of leaf node files
8. Object copy from the CI HUB to the local repository
9. Object deletion in both the local and CI HUB repositories
10. Tool invocation one leaf node objects
11. Metadata display for any container at any level of the hierarchy
12. Metadata editing for any container at any level of the hierarchy
13. Permissions display and editing for any container at any level of the hierarchy

Screen casts illustrating these operations

Limitations

The operation for copying a Bamboo Book from the CI HUB to the local repository was quite chatty. Copying occurred recursively node by node in the hierarchy requiring a separate CMIS call for every node and data stream in the hierarchy. As a result, copy operations were painfully slow. One could easily imagine an optimization in which a copy request for objects of a predetermine type, e.g. Bamboo Book, could cause the repository to roll up the entire hierarchy into a single content package to be unpacked and its hierarchy reconstituted on the receiving side. Development ceased before optimizations of this sort could be undertaken.

By the time we had implemented permissions display and editing, we had made the decision to switch from HUBzero to Drupal. Development ceased shortly after this decision was made and the integration of permissions editing with the hosting CMS was not undertaken. We had planned to expose a list of principals gathered from Drupal to the Repository Browser model for use in permission management. The principals would have corresponded to Bamboo Groups (see Bamboo Group service API {{ADD LINK HERE on migration to wikihub (sjm, 29 Apr 2013)}}). The UI for the permissions management functionality had been completed but we had not completed wiring up principals lists when development ceased.

In our proof-of-concept implementation of the CI HUB, Zotero bookmarks were used to trigger a call to a remote repository to fetch a book. From within the Repository Browser, one would upload the bookmark file to the local store, then copy it the the CI HUB. The file receiver listener in the CI HUB would inspect the file to determine whether it is a Zotero bookmark file, and if it is, contact the referenced repository to fetch the book referenced in the bookmark. We had not implemented sanity checking on these files in the Repository Browser. Such checks would evaluate the file to determine that it is a Zotero bookmark file before making the copy-to-CI HUB operation available to the user.