Monthly Archives: April 2014

SNAP:DRGN consultation workshop

Last week we held the first workshop of the SNAP:DRGN (Standards for Networking Ancient Prosopographies: Data and Relations in Greco-roman Names) project, here in King’s College London.

As announced in our press release the SNAP:DRGN project aims to recommend standards for linking together basic identities and information about the entities in various person-databases relating to the ancient world, with a view to facilitating the production of a federated network including millions of ancient person-records, compatible with the Linked Ancient World Data graph. At this workshop (see Workshop slides and recap) we presented our preliminary proposals, data models and ontology for feedback to a representative group of scholars from both the classical prosopography/onomaastics and Linked Open Data communities. We also spoke to several people with large datasets that might be contributed to the SNAP graph.

It was decided that SNAP:DRGN will attempt to address recommendations to five key use-cases of networked prosopographical data:

  1. Putting prosopographical data online, including stable URIs and openly-accessible data and metadata in standard formats (not defined by us).
  2. Contibuting a summary of said data, including identifiers for all persons and a simplifed subset of core identifying information about each entity, to the SNAP graph to that it can be built upon and referred to by other projects.
  3. Annotating SNAP entities to establish alignment and identify co-references between related datasets.
  4. Marking-up online documents to identify personal names within them to persons identified in the SNAP graph and its constituent databases.
  5. Adding relationships between persons, both within and between databases: person X is the daughter of person Y; person A in one database was killed in battle by person B in another database.

The SNAP:DRGN project will continue to work on the “Cookbook“, the summary of recommendations and examples for these five use-cases, over the coming months, in the run-up to adding several new datasets to the graph. We are also experimenting in a modest way with tool and implementations for working with the vast graph of ancient persons created: named entity recognition (NER) workflows for finding new personal names in texts; co-reference resolution for finding overlap and links between datasets; search and browse tools and APIs. This work will be reported on the SNAP:DRGN blog, and in conferences and seminars throughout the year.

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.