Jorum Blog

Coming improvements to the Jorum User Experience

Posted by on 12th December 2011

Over the past five months, JISC has been funding Jorum to engage in extensive technical work aimed at bringing a better user experience to Jorum’s users. This post describes some of this work, a later post will describe new work on single item deposits and bulk uploads (and see also this recent post on using RSS for bulk upload)

The improvement work divides into several parts that cover user experience concerns, including some related internal technical improvements.

Rapid gains: Work on the existing Jorum interface

One of our immediate concerns is to achieve some rapid gains with improvements to the existing Jorum user interface, simplifying and cleaning it up. Here our initial concentration is on two things:

  • Working out if we can simplify all pages by removing redundant menu items from the standard page layout for logged in users.
  • Changing the resource pages, redesigning them to limit the information on them to the more useful information, and making it easier to download materials, particularly if the resource consists of only one file.

Providing a new Jorum user experience

We have been working towards a new Jorum user experience by, in the longer term, discarding the existing user interface and providing a new interface.

Importantly, the new user experience will be designed as a result of extensive user feedback: The Jorum team has been analysing and synthesising the wide ranging feedback that we have received over recent years, and has extracted all the comments and suggestions pertaining to the Jorum user interface and Jorum’s underlying functionality.

We will draw on this feedback to inform the new user interface development. As time progresses, please expect a very clean user interface and good first-level user experience; later we will, as time permits, move to new functionality, for example, stored searches that reveal if particular kinds of items have been recently uploaded.

Supporting a new user experience

The endeavour of providing a totally revamped user interface and new user experience requires considerable internal ‘re-plumbing’. In fact, the internal work that we are doing on Jorum is carefully designed to realise three aims:

  • As above, to provide a new user experience for Jorum, by providing a better user interface and added functionality.
  • Allow for specialist front-end services to utilise Jorum’s repository services.
  • Allow us to upgrade the DSpace repository software that is at the core of Jorum’s functionality.

So what is going on under the hood? There are two key concepts, firstly of a (web) service – quite simply put, a program that runs on the web. For example, Jorum is a service on the web. Some things, which appear to be a unitary service, are in fact made up of multiple services: When you use Amazon about eighty carefully co-ordinated services work together to supply services to you.

The second thing to know about is an Application Program Interface (API), something which enables one service to talk to another. This is illustrated in the first diagram on the right.

In this, service A can make requests of service B, typically for some functionality offered by service B, or for some data held in service B.

What we are doing is ‘bolting’ an API onto Jorum so that other services can use Jorum. The first use of this will be to provide a new user interface for Jorum, as the second diagram here.

This new front-end service for Jorum will provide users with a cleaner user interface via their browsers, new Jorum functionality, and better user experience. All Jorum’s OER resources will be held in the existing Jorum service, just as they are today. Typical requests that the new service will make of the existing service will be for particular resources, and for the results of searches over Jorum’s holdings. This is illustrated in the second diagram here.

Later, we and others can use the API to build a variety of different front-end services for Jorum, for example to provide special collections or institutional holdings. In fact, Jorum is increasingly being asked to host special and institutional collections; the arcitecture outlined above is one way of providing customised user interfaces for these collections. See the third diagram in this post.

Upgrading the core Jorum software

To complete the picture of internal improvements being made to Jorum, we need to talk about what Jorum is based on. Jorum is a customisation of a standard repository, DSpace. DSpace is one of a small number of open source repositories, or software systems that store documents of various kinds.

In fact, Jorum is a customisation of an old version (1.5.2) of the DSpace repository. It is becoming pressing that we upgrade DSpace, to gain many benefits from later DSpace releases. What currently prevents us from doing so are the modifications that Jorum has in the past made to the DSpace, and the new API will allow us to move these modifications into the new Jorum front-end service. This will return DSpace to its original standard form and allow us to upgrade.

User collaboration

Of course, in a user-focussed endeavour such as Jorum, software cannot be developed in isolation from its users. Work based on user feedback was mentioned above. In the new year we’ll be running an online user consultations obtain feedback on our plans, and later we’ll be asking for users to trail our new user interfaces and new functionality. We also anticipate a period of interface development informed by eye tracking data.

If you are interested in this work please get in contact, via the comments, or via

«Back to the blog

blog comments powered by Disqus