All posts by David Little

Creating a UX design pattern library for Digital Humanities projects

Recently I posted some thoughts about how emerging trends in the field of user experience (UX) design might be embedded in our project design and development process. In this post I’m going to discuss this further, concentrating on the UX pattern library the user interface (UI) team are developing.

What is a UX pattern library?

Designers and developers in the DDH research team work on a number of projects with diverse design and development requirements but in terms of UI design we often find we have similar problems we need to solve. For example, these might include designing tools for surfacing content such as search and browse mechanisms, ways to facilitate collaborative editing of images or documents or managing a user’s workflow.

A pattern library is a way of describing the interaction methods we might use to solve common design problems. When faced with a problem on a project it can act as the first port of call for a designer or developer and help them understand which tool they should use to deal with the particular problem they are facing.

In addition to textual descriptions and images of various interaction methods the library can also contain example code snippets that developers can copy and paste, adapting them as necessary to the needs of their projects.

What are the advantages of a pattern library?

At its most basic a pattern library prevents the need for designers and developers to “reinvent the wheel” the next time they need to design or implement an aspect of a user interface. This saves time and reduces the need for developers to refer to design staff or to create their own untested solutions.

Beyond this, it also ensures consistency in terms of user interface design, not just within a project but across multiple projects. By using common patterns which are recognisable to users we reduce the cognitive load on them by not requiring them to constantly learn how to use new tools; in other words it enhances usability.

Inspiration for the patterns might come from previous projects we have worked on, or on solutions from beyond the field of digital humanities. For instance, when we were considering best practice solutions for faceted browsing we looked at both our previous implementations and examples from the field of e-commerce. Our key concerns are enabling our users to achieve their goals (e.g. locating relevant information in a search or browse) and doing this in a way that is intuitive and as simple as possible. Doing so removes the barriers to using resources and as a result hopefully promotes engagement with them.

Why another pattern library?

A number of UI design pattern libraries have already been published, including:

Some of these (e.g. BBC and Mailchimp) are focussed on a particular brand or product, others such as UI Patterns and the Yahoo library are more general. Although these have been useful as a starting point we felt we needed to have a library that reflected the kinds of issues we face in digital humanities projects—not just around issues of searching/browsing and workflow mentioned earlier but also ones which address the traditional concerns of humanists, such as reading long-form texts, comparing editions and viewing cross-references and footnotes.

Does a pattern library inhibit innovation?

A critique that might be levelled at pattern libraries is that they can stifle innovation or creativity in interface design. This only really becomes an issue if a library becomes a static document which is not updated to reflect emerging or even experimental patterns. The web in particular is an ever-changing environment: new trends and technologies are constantly emerging which can affect how user interfaces are designed and implemented; experimentation drives web design forward.

However, we should always be asking ourselves how a user interface element allows a user to complete her goals. For instance, does that whizzy data visualisation really help the user to make sense of a data set, or is it just a bunch of confusing overlapping lines? Do users really appreciate their browser scrollbar suddenly behaving in a different way on one website? If untested or implemented badly UI elements may run the danger of becoming “anti-patterns” that frustrate or actively hinder the user.

Next steps

We are currently in the process of identifying, describing and creating code snippets for the most common design patterns. We are creating descriptions on an internal Wiki and developing code snippets in a Github repository. Once we have a critical mass of patterns described and gathered feedback on them we plan to publish the descriptions on a publicly available website, linked through to an open source project containing the code snippets.

Lean UX in DH projects

As the user experience (UX) lead (and often sole UX practitioner) in a small team of software developers I’ve often had to adopt a pragmatic approach to incorporating a UX workflow into our project work. This has involved keeping clear of trendy methodologies and buzzwords, instead focusing on the key outcomes of creating the best possible user experience for the end-users of our products. To do this we follow a user-centred design process wherever possible, undertaking research with our target user groups, designing interfaces that allow them to achieve their goals and testing our designs with “real” users in the form of one-to-one usability testing.

Continue reading Lean UX in DH projects

Museums on the Web 2011

At the end of this year’s Museums on the Web conference at the Imperial War Museum (IWM) we were asked what our “key takeaways” from the day were. The presentations and discussions covered a wide range of interesting topics but I was most impressed with the work going on in the area of public engagement with creating and using digital resources; and the emphasis of the importance of user-centred design processes in enabling this.

365.162: Imperial War Museum

Mark O’Neill from the Government Data Service opened proceedings with a keynote speech highighting the challenges of improving user experience for the use of digital resources; particularly important given the commitment to “digital by default” for government services.

An interesting comparison was suggested: how are museums different from Ikea? Comparing a search across the Ikea website and a museum website (which will remain namless!) for an object, “vase” it was clear which one of these had a more seamless user experience: the commercial website was designed around the needs of users to easily achieve their goals (in this instance find a vase for sale) whilst the museum website lagged somewhat behind, its interface designed around the institution’s own internal language, not welcoming outsiders.

Subsequent speakers gave presentations on participatory projects initiated by their institutions. The Pallant House Gallery‘s  Outside In project provides a platform for artists with disabilities to display their work, uploading images of it via a web interface developed in an iterative manner during workshops with the artists themselves. The next stage is to develop a mobile app which removes further boundaries to involvement: direct upload via mobile involves fewer cognitive steps as images can be selected directly from the device that created them.

Tom Grinsted from the Imperial War Museum and Claire Ross from UCL department of Digital Humanities described an IWM project in development to make use of visitors’ commentaries of museum objects: Social Interpretation — bringing the levels of engagement and interaction that users experience with social media to the museum environment. The project is being run using an agile methodology at all stages: design, development and management to ensure that the outputs are produced iteratively and thoroughly tested with users at every stage. The project aims to develop interfaces to allow visitors to add their commentaries and interpretations via kiosk in the museum and web and mobile outside.

Another exciting participatory project run by the IWM is Lives of the Great War: using public involvement to recreate the stories behind those who served and died in the First World War. It aims to support this by providing direct access to the various information resources, currently dispersed across the web, some behind paywalls. It is also hoped that the data generated will be released under a “CC0” licence (the most permissive Creative Commons licence) and be archived permanently.

Interestingly, the IWM were shown to be pioneers in crowdsourcing: their earliest request for objects and memorabilia from the Great War took part at the war’s end in the form of a leaflet included with ration books!

Issues surrounding crowdsourcing received attention: namely questions of moderation of content and authority. Some basic moderation can be handled technically (e.g. via filters to remove swearing) but the community itself can also be a useful moderation tool (as it is currently on the Guardian website). Data release under Creative Commons licences (particularly “CC0”) can be more problematic in some areas than others, e.g. the performing arts.

Other presentations covered some very interesting areas I haven’t discussed here, including planning and measuring your digital strategy, refining your metadata and demonstrations of some very innovative software; it will be worth checking the MCG website for links to the presentation slides.

Overall I was impressed with the level of innovation — and collaboration —  in the sector; something I’m sure the digital humanities as a closely related area could learn from and share in.

You SPILt my code: a modular approach to creating web front ends

One of the projects I’ve been working on since starting at DDH in May is a review of the front-end development framework we’re currently using to build websites, sUPL or the Simple Unified Presentation Layer. The aim of sUPL was to be a lightweight markup scheme — lightweight both in terms of using minimal HTML markup and short class and ID names (commonly used to apply CSS styles and to trigger Javascript-based interactivity).

Whilst sUPL had served the department well for a number of projects I wanted to update it to reflect recent changes in the front-end development world and also to put the emphasis back on the “simple” in sUPL. After reading around and trying out a number of existing front-end frameworks (e.g.  as Blueprint,  YUI, HTML5 Boilerplate, OOCSS and 320 and Up) I felt our own framework should be updated along the following lines:

  • Be written it in HTML5, to make use of new structural elements and prepare the ground for the use of HTML5 APIs;
  • Move away from terse class names to longer but more “human readable” ones;
  • Employ the Object Oriented CSS (OCSS) methodology of maximising the reuse of CSS code by only applying CSS styles to classes, not IDs;
  • Using the OOCSS concept of “objects”, that is that is reusable chunks of HTML, CSS and Javascript code to build common design patterns.

Welcome to SPIL: the Simple Presentation and Interface Library

There are quite a few frameworks out there so why create another one? Most of the existing frameworks have been created for highly specific purposes (e.g. YUI) or they are more generic (e.g. the HTML5 Boilerplate). SUPL’s successor, SPIL (Simple Presentation and Interface Library) can be thought of as a toolkit (or Lego!)  for constructing web pages and applications, providing both a generic structure for page layout and the ability to “plug in” interface design patterns which will work “out of the box”.


SPIL makes use of the new HTML5 structural elements such as header, footer, section, nav and aside, loading in the Modernizr Javascript library to provide support for older, less capable browsers such as Internet Explorer pre-version 9. Of course relying on Javascript to provide this functionality may not always be appropriate, so SPIL provides some alternative markup in the form of reliable old-fashioned divs should you want to use XHTML1.0. For instance if we were marking up a primary navigation element in HTML5 we would use:

<nav class=”primary”> …. </nav>

But should we want to stick with XHTML we could use:

<div class=”nav primary”> … </div>


The development of SPIL has been heavily influenced by Object Oriented CSS (OOCSS) — both the concept and the CSS library. OOCSS encourages the reuse of code in order to enhance performance and keep down CSS file size (also approximating the DRY — Do Not Repeat Yourself  — concept in software engineering). One way to do this is to only style on classes — which can be used any number of times on a page — and not IDs — which can only be used once and also interfere with style inheritance. Class names can be chained together to combine styling effects, reusing predefined styles.

A useful concept in OOCSS is that of “modules”. Although SPIL’s implementation differs from that of the OOCSS library, the ideas are very similar. For instance, we can create a module object for a common design pattern, a tabbed display that can be plugged straight into a page template:

<div class=”mod tabs”>
 <ul class=”tabControls inline”>
  <li class=”tabControlHeader”><a href=”#tab1”>Tab 1</a></li>
  <li class=”tabControlHeader”><a href=”#tab2”>Tab 2</a></li>
 <div class=”tabPanes”>
 <section class=”tabPaneItem” id=”tab1”>Tab 1 content</section>
 <section class=”tabPaneItem” id=”tab2”>Tab 2 content</section>

The structure for this module within the identifying div is built around what jQuery Tool’s implementation of tabs would expect but the class names could also be applied to other implementations. To use this code with jQuery Tools we would simply include a line in our Javascript file, e.g.:

$(".tabControls").tabs(".tabPanes > section");

An advantage of taking a modularised approach to code is we can start to build a library of predefined code snippets that can be slotted in place by anyone involved in interface building, from UI designers and programmers wanting to create a functional prototype through to front-end developers working on the final site build.

Development of SPIL

SPIL is being developed iteratively alongside new web projects within DDH. We’re feeding the work straight into an open source project which we hope will be available for release soon. If you have any comments or if there’s anything you’d like to see in the framework, why not less us know via the comments?