A custom local OHMS front-end

Here at the Science History Institute, we’ve written a custom OHMS viewer front-end, to integrate seamlessly with our local custom “content management system” (a Rails-based digital repository app with source available), and provide some local functionality like the ability to download certain artifacts related to the oral history.

We spent quite a bit of energy on the User Interface/User Experience (UI/UX) and think we have something that ended up somewhat novel or innovative in an interesting way.

The Center for Oral History here has been conducting interviews with scientists since 1979, and publishing them in print. We only have a handful of oral histories with synchronized OHMS content yet, although more are available in our digital collections as audio without synchronized transcripts.

We aren’t yet advertising the new features to the public at large, waiting until we have a bit more content — and we might continue to tweak this initial draft of the software.

But we wanted to share this initial soft release with you, our colleagues in the library/archives/museum sector, because we’re pretty happy with how it came out, wanted to show off a bit, and thought it might be a useful model to others.

Here are some examples you can look at, that have OHMS content and use our custom OHMS viewer front-end:

Screen Shot 2020-04-21 at 10.18.04 AM

Consider checking out our interface on a smartphone too, it works pretty nicely there too. (We try to do every single feature and page such that it works nicely on small and touch screens; this one was a bit of challenge).

Also, before doing this work, we tried to find as many examples as we could of different UI’s for this kind of functionality, from other custom OHMS viewers, or similar software like Aviary. We didn’t find that many, but if you want to see the few we did find to compare and contrast as well, you can see them in our internal wiki: https://chemheritage.atlassian.net/wiki/x/AQCrKQ

Compare ours to the ‘out of the box’ OHMS viewer, for instance here:

Screen Shot 2020-04-21 at 10.21.52 AM

Note on OHMS architecture

The way the OHMS software works standardly, is there is a centrally-hosted (“cloud”) OHMS application for metadata editors, in which you enter and prepare the metadata.

This centrally cloud-hosted app (which does not have public source code) produces an XML file for each Oral History.

The OHMS project then also gives you an open source PHP app that an institution is responsible for running themselves (although there is at least one third-party vendorthat will host it for you), which you give your XML file(s) too. So the actual end-users are not using the centrally located OHMS server; this means the OHMS organization doesn’t have to worry about providing a web app that can scale to every institution’s end-users, and it also means the OHMS central server could completely disappear, and institution’s end-user facing OHMS content would be unaffected.  So it’s a pretty reasonable architecture for the organizational practicalities.

So that means we simply “replace” the “standard” PHP OHMS viewer with our own implementation. Which is integrated into our Rails app on the back-end, with some custom Javascript on the front-end, mainly for the ‘search’ functionality. The OHMS architecture makes it ‘natural’ to use a custom or alternate front-end like this, although it requires some reverse-engineering of the OHMS XML format (and embedded markup conventions) which isn’t always super well-documented. We’ll see how “forwards compatible” it ends up moving forwards, but so far I think OHMS has really prioritized not breaking backwards compatibility with the existing large base of PHP viewers installed.

It allows us to do some work to push the UI/UX forward. But perhaps more importantly, and our main motivation, it allows us to integrate much better into our existing web app, instead of using the iframe approach that is standard with the default OHMS viewer. Easier to get consistent styling and functionality with the rest of our app, as well as naturally include features relevant to our app and use cases but not in the standard OHMS viewer, like artifact downloads. And it also allows us to avoid having to run a PHP application in our Rails shop.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s