Workflows as Structured Surfaces

At DH 2011 in Stanford, we introduced the concept of structured surfaces, where we extended the metaphor of interactive digital pins on a digital map into interactive digital pins on any data visualization (Radzikowska et al. 2011). We proposed that such structured surfaces would provide a means for people working with digital collections to gain insight into their material while also providing them a means of formulating an argument about the data.

More recently, in considering scholarly editions, we became interested in how the concept of the structured surface could be applied to the editorial process – in effect, producing an interface derived from the flowchart of activities that an editor can use to manage the movement of a submitted article or other item of text (such as a book review) through the stages from its initial appearance in the editor’s inbox to the final step where it is ready to send to the printer.

Accordingly, we have designed and are in the process of producing experimental prototypes of a series of these workflow interfaces for different kinds of editorial jobs, including the publication of journal articles, the writing of XML-encoded original material based on Orlando biocritical entries on women writers, and the editing of a scholarly edition (e.g. Figure 1). In these designs, the structured surface consists of the flowchart used by the editor, and the pins represent the articles, with size of pin indicating length of article in words.

Figure 1: This workflow diagram shows the movement of a journal article through the publication process from the perspective of the journal editor who is managing that process

Numerous other systems exist for managing workflow in the context of digital text production, such as that devised by the Public Knowledge Project for its Open Journal Systems and its Open Monograph Systems. The interfaces here seek to retain the modularity and customizability associated with such systems but to combine them with a rich prospect visualization (Ruecker, Radzikowska & Sinclair 2011) of the collection being managed than has hitherto been implemented. Recent work in computing science has focused both on workflow analysis (e.g. Schroeder 2009) and on algorithms for automatic layout (e.g. Albrecht et al. 2010).

However, a workflow management tool, as useful it might be to the editor who has not had the advantage of using one yet, is in itself not a particularly interesting object. It is essentially a structured checklist, composed of a collection of stages with transitions, including occasional decision points between them. But once such a concept is available for interrogation, it can begin to introduce additional considerations.

For example, why is the structure of the stages limited to a simple bucket? Would it not be useful to be able to distinguish different kinds of material moving through the system? It might possible, for instance, to automatically identify file types so that digital text is treated one way by the tool, while digital film is treated another. Or the editor may wish to produce a variant of the workflow for book reviews as opposed to peer-reviewed articles. So we have begun to experiment with ways of visually structuring the boxes that represent stages (Figure 2).

Figure 2: An initial attempt to turn the workflow stage itself into a kind of structured surface

Once we have the concept of the system automatically doing something to the documents, it is a short step to recalling that the original goal of the structured surface project was to provide the user with a set of analytics in the form of a data visualization and an argument made by the superimposition of pins. In that context, it seems reasonable to consider what kinds of analytical processes might be applicable to various stages within the workflow, and also what kind of information might be useful to the editor at each stage. For example, when an article is with a reviewer, the editor is likely to be primarily interested in the following information:

• the title of the article
• the name and contact information of the reviewer
• the dates when the article went to the reviewer and when it is expected back

A rollover of the pin within the ‘at the reviewer’ stage should therefore by default produce this list of information, with access to further information relegated to the ‘more…’ link. At the next stage, however, when the article is back from the reviewer(s), what the editor would like to know is the results of the review. A rollover of the pin while in that bucket should therefore produce the title of the article and the name of the reviewer(s), but also the contents of the review.

On the analytics side, there may be processes (like reviewing) where the article is passed to another person, but there may also be processes where the article is passed to some algorithmic treatment, such as an automated step of metadata enhancement where the system makes the first pass at named entity recognition for people and places. Since one of the affordances of the JiTR environment is that any collection or subset of a collection can be passed to a tool, perhaps the contents of the stages within the workflow could serve as subsets for this kind of treatment. An editor might then, for instance, decide to take a look at a KWIC concordance for a term in every article in the ‘accepted’ bucket for the current edition, or run a word cloud on all the articles that have been accepted or rejected. The wordcloud of acceptances might provide some guidance in writing an introductory editorial, for instance, while the latter might help the editor see whether there is a gap in reviewer expertise at work. Support for these sorts of curiosity-driven activities within the editorial process itself has the potential to change the nature of the task in a variety of ways.

Finally, the concept of an interface that combines workflow management with analytics is of considerable interested to the Canadian Writing Research Collaboratory (CWRC) project, which seeks to lower the bar to participation in online resource creation and enhancement by mainstream scholars without significant expertise in digital humanities, and in so doing lower the overhead of producing scholarly materials on the web. In order to ensure quality control within a system such as CWRC’s, a workflow process needs to be highly intuitive as well as modular, robust, and well integrated with other interface components. For these reasons, CWRC is experimenting with the structured surfaces interface and the JiTR environment as a major component of its interface, seeing the potential of it for managing everything from query results to worflow management to membership coordination. The CWRC project has presented the interface to Collaboratory members at two workshops this year and is extending the prototype to handle Orlando-like workflows and interact with an external workflow engine.

This presentation will outline the transfer of the structured surface concept to workflows, show the sketches and demonstrate the prototypes, and report on user feedback to date. It will provide an analysis of the implications of this approach to supporting the editorial process, suggesting that there are a number of potential new affordances that make the workflow a useful addition to the editor’s toolbox. An interface which integrates a tightly defined workflow alongside the ability to invoke other tools, we argue, can also encourage new kinds of thinking about possible improvements or additions to the workflow.