A new look: behind the redesign of OJS 3.0 beta

By Nate Wright

The look and feel of OJS 3.0 beta was completely overhauled in the final months before release. In this post, I’ll dive into a few of the principles which guided this work, explaining how we used visual hierarchy and consistency to improve the focus and clarity of the UI.

Where we started

When I joined the PKP team, I was dying to take a crack at the UI. Here’s what the OJS dashboard looked like at the time.

OJS 3.0 dashboard before the redesign
OJS 3.0 dashboard before the redesign

We could nab a few easy wins by increasing the color contrast, and improving the size and legibility of the text. But there were also some bigger, structural concerns.

The UI felt cluttered and messy.

There were a few problems going on here. One was that there was inconsistent spacing and sizing used for the elements on the page. This made it difficult for the eye to organize and distinguish elements on the page.

Another problem was the lack of focus. There was very little indication of which part of the page was the most important.

Reducing clutter with a new site architecture

The first step we took was to mockup a new “scaffold” for the backend. This was the initial mockup.

The initial mockup of the backend layout.
The initial mockup of the backend layout.

The goal was to create a separate layout for the backend which would trim out extraneous elements, improve focus on the task-based behavior in the workflow and recover some screen real estate.

Clearing out unnecessary elements
We ditched the sidebar and footer in the backend, which were directed at readers, and even stripped out those navigation links which weren’t relevant to the administrative or editorial tasks.

Improving clarity of sidebar vs content
We more clearly distinguished between contexts by employing strong color contrast between the main navigation on the left and the main body area (on the right).

This approach also allowed us to recover a lot of space on the screen for page-specific tasks. In future iterations, we’ll be able to tuck that sidebar away on small devices so that editors and authors can more easily work on their mobile phones or tablets.

Consistent spacing
Since this was our first mockup, it was also the right time to lay down consistent spacing and alignment standards. We chose a 16px baseline and ensured our navigational elements, padding between content and other UI components all aligned to a 16px grid. (Actually, if you look closely you’ll find lots of errors — but this was just a mockup!)

Improving focus through visual hierarchy

The next step was to take this new site architecture and start integrating it with the administrative forms and editorial workflow in the backend. Here’s 3.0 beta’s dashboard today.

The dashboard in OJS 3.0 beta.
The dashboard in OJS 3.0 beta.

To complete the redesign in time for the release of 3.0 beta, we needed to establish a visual hierarchy that would work across all of our pages. We couldn’t be micro-managing content on every page if we were going to finish this in time.

Lift the primary content off the page
The first step was to lift the primary content panel off the grey background by giving it a white background. This put the primary content at the top of our visual hierarchy, so that the eye will unconsciously jump first to the area we think the user is most likely interested in.

This step also had the benefit of providing a clear organisation of content. Tabs are widely used in the backend of OJS 3.0 beta. By grouping the tab title with it’s content, we’re able to clearly indicate what is “in scope” and what options are available “out of scope”.

On a more compositional level, this gives us a neat hierarchy of scope that we hope will help users more intuitively navigate the interface. The white panel represents the here and now context — typically a submission stage, an area in the dashboard, or a sub-category of settings. The grey background represents a higher context — the submission itself, the whole dashboard, or a top-level category of settings. And these local contexts contrast sharply with the global context of the sidebar.

Clear link and button targets
Next we implemented a more consistent and clear set of UI components for links and buttons, so that actions stood out clearly from information in the system. In the workflow, we used the visual prominence of buttons over links to push focus towards the primary or final actions of a content panel. Links were retained for many of the internal activities of the workflow, where they often spaw modals.

Improving legibility and internationalization

We also took the opportunity to improve the legibility and internationalization of our fonts. Font sizing was increased across the board. We’re using Noto Sans, a font developed by Google that is designed to achieve visual harmony across different languages. It is also a digital-native font, which means it’s been designed like many of the most popular Sans web fonts to include wider character glyphs for better clarity on various screens.

All the stuff we couldn’t do

There’s a lot we weren’t able to tackle in time for beta. Here are some of the things we want to improve as we move towards a production release of OJS 3.0.

Accessibility
We’ve made big strides on this front. There are many more we can make.

Frontend
Our reader interface is better, but we still have lots of content to integrate and update.

Clarity and organization of forms
Let’s face it, many of our settings pages are big and scary.

Actual UX
Almost everything we’ve done to date has been improvements to the user interface (UI). We can now tackle more comprehensive UX problems, like improving the help text and cleaning up some of the usability hurdles in the editorial workflow.

And here we are

That’s how the new design for OJS 3.0 beta came about. We’re busy integrating these changes with the next version of OMP and fleshing out some good ideas for the reader frontend.

What do you think?

Facebook
Twitter
LinkedIn