Visual workflow interfaces for editorial processes ............................................................................................................................................................ Luciano Frizzera University of Alberta, Canada Milena Radzikowska Mount Royal University, Canada ˜ Geoff Roeder, Ernesto Pena and Teresa Dobson University of British Columbia, Canada Stan Ruecker IIT Institute of Design, USA Geoffrey Rockwell University of Alberta, Canada Susan Brown Guelph University, Canada The INKE Research Group University of Victoria, Canada Correspondence: Luciano dos Reis Frizzera, Humanities Computing Office of Interdisciplinary Studies, 1-17 Humanities Centre, University of Alberta, Edmonton, Alberta Canada, T6G 2E5. Email: dosreisf@ualberta.ca ....................................................................................................................................... Abstract In this article, we provide a discussion of the concept of visual interactive workflows, how they relate to our previous work on structured surfaces, and how they have been adapted to experiments in managing articles for journal publication and managing biographical histories being written and tagged in XML. We conclude with a user experience study of the prototypes, which suggests that they are relatively acceptable at the level of reflective response, but might benefit from more iteration in their use of process and element metaphors. ................................................................................................................................................................................. 1. Introduction Collaborative scholarly writing and publishing activities typically involve many different types of documents divided across various stages. This is especially true in the case of big projects. Documents may pile up, scattered in many folders—both real and virtual—awaiting tagging, revision, editing, proofreading, approval, and so on. There are workflow management tools available to help, but they have often been designed with other audiences in mind, so they can be too specialized and somewhat complex to use. The goals of this project were therefore to make them less specialized and easier to use. There are several potential advantages of improved workflow management for document production and publishing. First is the reduction in general confusion, whether by one person or several, about the status of various documents within the system. Since both writing and publishing tend to Literary and Linguistic Computing, Vol. 28, No. 4, 2013. ß The Author 2013. Published by Oxford University Press on behalf of ALLC. All rights reserved. For Permissions, please email: journals.permissions@oup.com doi:10.1093/llc/fqt053 Advance Access published on 18 September 2013 615 L. Frizzera et al. be intermittent tasks, with irregular intervals between work sessions, a considerable amount of time can be spent just in getting back up to speed on where the work left off. Second is the increase in confidence, not necessarily about the status of a document, but about its location among the various people involved. This is particularly important in cases where the document may be in the hands of several people simultaneously, and it is important to track how long it is taking in each location so that bottlenecks can be prevented and the amalgamation of work carried out efficiently. Finally, related to reduced confusion, increased confidence, improved productivity, and other factors, there are possible benefits to the mental and emotional well-being of the people involved. In terms of the visual component, it is generally understood that visual representations of data and processes can have the advantages of providing an overview of the material, insights into the underlying structure and affordances, and benefits for non-expert or intermittent users (e.g. Ruecker et al., 2011). However, it is also important to avoid the many potential disadvantages of visualization. Bresciani and Eppler (2009) provide a preliminary taxonomy of >50 potential cognitive, emotional, and social disadvantages, which in each case might be designer-induced or user-induced. There are several ways in which such improvements might be subject to measurement, including comparisons between using a visual workflow and not using one for the following: time to create documents publisher hours spent per document published cognitive and affective reports from writers and editors. This project falls within the larger program of research set out by the Interface Design (ID) team of Implementing New Knowledge Environments (INKE), and in particular INKE’s recent work on supporting the creation and editing of digital materials, as opposed to their access and use. We have been exploring the concept of structured surfaces (Radzikowska et al., 2011) to investigate both visual and interactive methods to make workflows more attractive, flexible, and useful for scholars. We 616 Literary and Linguistic Computing, Vol. 28, No. 4, 2013 provide a summary of interactive visual workflows and how they have been applied, and explain what structured surfaces are and how the concept can be applied to workflows. 1.1 Workflows Many projects in the digital humanities involve either digitization or enrichment of existing digital materials. The process is usually similar to editorial activity and can be understood as an ordered checklist or sequence of events, or perhaps more accurately an ordered graph of events, as some can occur in parallel, or only after a decision point. A researcher first enters the raw text, then encodes, proofs, and tests the results. There is a process or workflow to be followed. Visual tools for workflow management therefore often also take the form of what is essentially a structured checklist, composed of a collection of stages with transitions, including occasional decision points between them. In effect, they are flowcharts. These tools are widely used in science and business to describe production process models; research in this area began as early as the 1970s (e.g. Aalst 2004). Contemporary examples range from managing earth sciences data at NASA (Berrick et al., 2008) to environmental performance monitoring (Versteeg et al., 2006) to modelling business problems (Virine and McVean 2004). There have, however, been criticisms both about the lack of visual standards and the poor visual decision choices that result: ‘Often, the construction of a layout for a possibly complex workflow is left to the user or the result is visually unsatisfying’ (Albrecht, 2010). The solution Albrecht proposes involves better algorithms for automatic layout (Fig. 1). In the humanities, workflow management tools have been used in the context of digital text production. For example, there are workflows in the Public Knowledge Project for its Open Journal Systems and its Open Monograph Systems. However, they are currently represented as a linear series of steps rather than a visual workflow (Fig. 2). There are different approaches to the construction, refinement, and comparison of workflows. Some methodologies offer better expressibility using graph-based models; others focus on the Visual workflow interfaces for editorial processes Fig. 1 Algorithmic improvement of workflow layout (from left to right). From Albrecht et al. 2010, p. 176 complexity of model checking (Lu and Sadiq, 2007). We are interested in producing a visual interface that combines workflow management with an analytics tool that could be used by scholars. Based on our previous work, we began to consider a visual workflow management system as a kind of structured surface (Radzikowska et al., 2011). A structured surface generalizes the familiar concept of a map with pins. The map provides a layer of information, and the pins provide another layer, which might be used for simple purposes such as finding restaurants in a city, or for more complex ones such as making a visual argument or providing evidence for an argument made elsewhere. If the map layer is replaced with any other form of data visualization, we refer to it as a structured surface. In a workflow manager, the structured surface represents the flowchart, while the documents are shown as pins. Once the pins are combined with the structured surface, the conditions are met for even further analysis or data visualizations. The resulting interfaces seek to retain the modularity and flexibility associated with workflow systems, while offering a rich-prospect visualization of the collection being managed (Ruecker et al., 2011). We proposed that visual workflows designed as structured surfaces could offer an easy tool to track information during the processes of production and publication, providing means for people to gain insight into their material while also supporting them with some ways of formulating an argument about the data. 2. Editorial Workflow In the pilot stage of this project, we used a generic workflow based on the processes involved in journal editorship. We did not work with any real content—just placeholders, and our model of the workflow was developed based solely on our own experiences in publishing in journals. Articulating workflows is also a non-trivial task, and journal editors are typically quite busy. The goal was therefore to get a prototype started, so that it could be used at a later stage to elicit iterative improvements from working editors. 2.1 Technology We chose to use web standards technologies such as HTML, CSS, and JavaScript. We begin with D3.js, an open source JavaScript library for creating data visualizations. The goal was to launch the workflow from JiTR, a collection management prototype intended to support experiments of this kind (Organisciak et al., 2009). 2.2 Design We began with the conventional understanding of a workflow as a kind of flowchart, with the surface for organizing the status of documents showing a pipeand-flow diagram (see Fig. 3). The process is read from the left side, where each document must be accepted before it begins traversing the workflow. Literary and Linguistic Computing, Vol. 28, No. 4, 2013 617 L. Frizzera et al. Fig. 2 This screenshot shows a typical workflow in the Open Journal Systems interface Each stage of the process, represented by a rectangle, is an activity such as a decision point, in-progress work, or even a standby moment. The colours reflect the status inside the workflow: work in progress (dark grey); needs revision (yellow); rejected (red); accepted (green). The articles are represented by tokens in the shape of bubbles. The token’s position within the workflow indicates where, along the process, the article is located; the size of the bubble roughly suggests length of the document in words. Moving the mouse pointer over the token shows detailed 618 Literary and Linguistic Computing, Vol. 28, No. 4, 2013 information about the article: title, abstract, name and contact information of the reviewer, and the date when the article went to the reviewer. 2.3 Development results What we found with this experiment was that too much information is contained in the structured surface. The result is a display that is fine for small workflows, but can quickly become cluttered and difficult both to design and to subsequently understand and use. As an alternative, it is possible to move some of the information out of the Visual workflow interfaces for editorial processes Fig. 3 The first version of the structured surface editorial workflow used D3.js to build the interface underling structured surface and into the pins. In our next iteration, we therefore explored placing more information in the tokens, which allowed us to de-clutter our surface. In terms of technology, we also identified a limitation. Whereas D3.js is a good option to create visualizations using web standards, it was not a good fit to create a fully interactive environment for our experiment. The main limitation has to do with line breaks. As described on the W3C recommendation website, an ‘SVG (Scalable Vector Graphic) performs no automatic line breaking or word wrapping’ (W3C, 2011). Since D3.js uses SVG to render graphics on the screen and we want to show multiple lines of information, we decided to look for other options. 3. Orlando Workflow We hoped for this iteration to produce an experiment with more meaningful data, so we partnered with Susan Brown and The Orlando Project. One advantage of this choice was that Orlando had recently been going through the process of formally defining its various production workflows using Unified Modeling Language (UML) (see Fig. 4). Although these are at a level of abstraction that still requires translation into a particular instance, their existence did mean that the Orlando team members had been giving recent thought to their own workflows. These had in any case previously been quite well articulated, as they were used frequently and also formed part of the annual training of new Orlando research assistants. In discussing the possibilities, we were also able to show the pilot prototype to the Orlando team members, which provided them with a sense of the direction we were heading. In the end, the structured checklist we used was provided to us by the Orlando Textbase Manager, Mariana Paredes-Olea. Another advantage of Orlando is that their workflows are predicated on well-defined roles within the project, so that it is only possible for some people, for example, to move a token to the next stage. In terms of data for the tokens, we used some of the previous Literary and Linguistic Computing, Vol. 28, No. 4, 2013 619 L. Frizzera et al. Fig. 4 The Orlando Workflow for research, writing, and tagging shown as a UML diagram Orlando document production jobs, which involved the writing of XML-encoded original material for Orlando biocritical entries on women writers. Fifty-four biographical entries were used as a sample for the purposes of this prototype. 3.1 Design Since we moved from a hypothetical workflow to a workflow predefined by the Orlando Project, we had to redesign both the process and the structured surface. The sample workflow supplied by Orlando has some interesting and useful features. For example, some stages are non-sequential, but are required at some point before the document is completed. To illustrate this characteristic, we grouped these steps in clusters with a light grey background. Another feature is the existence of optional stages, which can occur independently of the document’s stage. These are represented in the top of the screen, disconnected from the main stream (see Fig. 5). One feature we did not explicitly address is the restriction of certain actions to particular roles; this affordance would most likely be provided in future iterations through the development of rules that govern constraints on the system. The workflow loads the collection of documents and retrieves the metadata. Based on this information, the documents, represented by tokens, are positioned in the workflow. To save space, the position of tokens inside a stage is random, so they can be placed one on the top of the other. They are colourcoded to show status information: Starting a stage (White); Work in progress (Blue); Incomplete 620 Literary and Linguistic Computing, Vol. 28, No. 4, 2013 (Red); Completed (Green). A counter box shows the number of documents held by each stage. As in the first prototype, a balloon showing the title of the document pops up when the user clicks on it. However, we believed that this information would not be sufficient for project managers. So, we decided to make available more details about each document. A double click makes the token bigger, revealing a circular control panel and general information such as title, collection and current stage and status of the document. The control panel gives three options to the user: (1) Access the History Log, which shows the document progress in the workflow. The logs are displayed in reverse chronological order, showing when someone performed a modification and providing the name of that person. (2) Access the Status Switcher, enabling the user to change the status information of the document. (3) Tag Mark, which turns on a star icon, making it easier to follow a particular token through the workflow. In this version, the user can also drag the token to any stage in the workflow, regardless of the sequence. By doing that, the user automatically changes both the stage and the status of the document. Every modification performed in the workflow is auto-saved and generates a new log entry in the history. The system also prevents tokens from being released outside the stages by automatically Visual workflow interfaces for editorial processes Fig. 5 The Orlando Workflow is the second version of structured surface workflow moving them back to their former position. This constraint means that every token needs to be accounted for within the workflow, hopefully forestalling disruption and confusion. person is digitalizing the data for analysis, and a third is writing the methodology section. 4. Evaluation 3.2 Development results Some issues arose during the process of development of this version. The most important was how to deal with the high density of tokens inside a stage. Whereas it was easy to access one document in a lightly populated stage, in those with a high density the fact that the tokens overlap one another challenge the user to find or access the information. Another issue is that the distribution of stages in a linear sequence seems to be a poor representation of all but the most simple workflows. In digital text production, it is common to have parallel actions occurring at the same time. That is, more than one person may be working on different stages of the same article. We needed to accommodate, for example, a situation where one person is doing the literature review at the same time that another To confirm or refute our assumptions and the interface’s effectiveness, a user experience study of the two workflow prototypes was done. The following section provides a preliminary report on data collected from phase I of a two-phase study. In phase I, we recruited participants who had experience (either as editors or writers) with the editorial process in academic settings. One reason for this approach is that we are hoping that the strategies we design might be of use in the general context of large infrastructure projects, such as the Canadian Writing Research Collaboratory (CWRC), where users will have a good knowledge of their own work but may have had little or no prior training with the visual workflow system. These participants engaged with both the Editorial Workflow and Orlando Workflow; in phase II, which is underway, Literary and Linguistic Computing, Vol. 28, No. 4, 2013 621 L. Frizzera et al. we are recruiting participants who are involved in XML tagging with the Orlando project. Results of the full study will be presented at a workflow panel at JADH2013 in Tokyo. 4.1 Procedure During phase I, the prototype was tested with nine participants at the University of British Columbia. Participants engaged with the two prototypes on a MacBook Pro running the OSX 10.7.4 operating system. The users were first shown brief video tutorials that demonstrated and explained the functions of the prototype. After viewing the tutorials, the participants completed a short task list for each prototype. The task list provided a set of brief narrative statements followed by imperative sentences asking the participant to use the interface in a way responding to the narrative, as shown by the following sample task list item: SETUP: The author has sent the article back and you’ve reviewed it. The article requires further revision. INSTRUCTION: Please move the article to the appropriate box. A different set of version-specific narrative statements was provided for each version of the prototype. Participants were encouraged to talk aloud about their process as they completed tasks. A standard think-aloud protocol was modified in the following manner: researchers observed and interjected at times to invite participants to clarify particular comments or actions. This approach has been described as a side-shadowing interview (LuceKapler, 1996). All interactions during the sessions were recorded using the screen capture software ScreenFlow (Telestream, 2013). After completing each set of tasks, participants filled out an online survey that included Likert-scale questions such as the following: ‘In your experience as an editor, do you feel that the option to track and view the work history of a document in Orlando Workflow would enhance your ability to track a document through to completion?’ Finally, participants were invited to imagine and draw their own visual workflow process 622 Literary and Linguistic Computing, Vol. 28, No. 4, 2013 using a blank sheet of 8.5’’ by 11’’ printer paper. The study took 1 hour to complete. 4.2 Data analysis The audio-visual recordings were reviewed once in full by the investigators to delimit the shared areas of interest and concern among the participants. On the basis of these commonalities, partial transcripts of the areas of interest were produced. These transcripts and the survey data form the basis for a number of general findings from phase I of the study. We report these below. 4.3 Results The majority of participants found the structured surface workflow a pleasant interface. 46.2% of respondents to the online survey answered ‘Yes’ and 23.1% ‘Mostly’ to the question ‘Do you like the colours in this interface?’ To the question, ‘Do you like the layout of the boxes’, 30.8% of respondents answered ‘Yes’ and 38.5% answered ‘Mostly’. To the question, ‘In your experience as an editor, do you feel Workflow would enable you to track the progress of academic articles from submission through publication?’ 46.2% of participants answered ‘Yes’ and 30.8% answered ‘Mostly’. From this we conclude that Workflow provides an effective visualization of the progress of articles towards publication. However, there was dissatisfaction among the participant group with the smaller details of moving and tracking the details of texts. In an open-ended question asking, ‘What progress-tracking feature did you like least and why?’ participants raised a number of issues including the following: ‘It’s a bit odd that it’s being done manually. While the ability to move things manually would be incredibly helpful, being attached to a system that automates the workflow based on feedback from the editor/submitter would make more sense to me’ (Response #3). ‘The bubbles do not clearly distinguish which article / author they represent from an overview’ (Response #6). ‘I would like more information in the bubbles themselves, without having to double click on them’ (Response #17). Visual workflow interfaces for editorial processes Such problems are difficult to explore in detail using only survey responses. However, the side-shadowing interview procedure provided much data. These data, less structured than the survey responses, can be effectively sorted and contextualized by drawing on Barr et al. (2002), who proposed a taxonomy of interface metaphors based on Lakoff and Johnson (1980). Barr et al.’s taxonomy can form an effective theoretical basis for both further commentary on and mobilization of the user experience results. Investigators noted that the participants tended to adopt one of two stances in their engagement with the prototypes. The first was that of a critical viewer, a ‘reflective’ style of response; the second was that of an active user, a ‘directive’ style of response. These styles of response are pertinent to two distinct levels of the Workflow prototypes. Commentary in a reflective style informs the underlying structure and metaphor of the interface, whereas commentary in a directive style informs the moment-to-moment practicality and functionality of the prototype. Reflective styles of response occurred when a participant did not actively operate the prototype or seek for functionality, but instead held back and provided rich descriptions of the underlying process that the interface represents. Participant 6342, for example, does just this at [02:55] when he remarks: ‘It looks extremely simple on the one hand and useful on the other, because it is visually there. Like a rather complicated index card system but I think having the cards all laid out in front of me like in a flow chart way makes things look quite a lot simpler, and I do like organizing these kinds of things. Over the years, I’ve edited a bunch of books and I edited a journal for a few years as well, so I’ve had a fair amount of experience with the complexity of even getting people to review, to respond, to return revised manuscripts and all that kind of thing’ (Participant 6342). The directive style of response, on the other hand, occurred when a user put him or herself in the role of an actual user of the prototype. At these moments, users entered into the particular task-list items or sections of the interface as if they were active users of the software. They probed whether the movement and communication functionalities made sense on a logical level and tasks could be achieved as described in the task list. An example of this style of response arose from participant 2751 at [06:25]: ‘So, sometimes I am getting a mouse-over, sometimes I’m not, so you’ll notice there’s a nice little pulse when I go over, and if a hover for a very long time . . . nothing. Oh, actually no I can see that now. And actually I think it is happening there, but because the background is so dark I can’t actually view it. And, let’s see, and the red one . . . Okay, yeah. So sometimes, visually . . . the size of the bubble and the darkness of the background is making it less likely to see the effect. So the interesting about that is as a user, I saw that effect initially that reaction, and then I didn’t here, so I thought I was stuck’ (Participant 2751). Barr et al.’s model provides a means to distinguish what features of the prototype’s set of metaphoric meanings the two different styles of participant response are addressing. The reflective users contributed information related to what Barr et al. (2002) defines as the structural metaphor of the interface. Following Barr et al.’s (2002) model, we can interpret such responses as implicit comparisons the users are making on the basis of similarity between preexisting models for managing a workflow (such as other programs like Open Journal Systems or paper-based workflows) and the apparent functionality of the prototypes themselves. On the other hand, the active users provided feedback on what Barr et al. (2002) defines as process and element metaphors: ‘A process metaphor is used to explain some aspect of system functionality works [sic]. An element metaphor is a perceivable aspect of the user interface that is designed to aid the user in understanding what process metaphors are applicable’ (p. 28). Participant 2751’s remarks above on the bubble’s behavior can be accounted for as engagement with an element metaphor (the pulse) that was meant to cue a user’s understanding of the process of clicking Literary and Linguistic Computing, Vol. 28, No. 4, 2013 623 L. Frizzera et al. on and finding greater information about a given text (represented as a bubble). Within such a framework, we can draw additional general conclusions about the workflow prototypes. The reflective styles of response tended towards acceptance of and a favorable attitude towards the underlying structural metaphor of the workflow prototype. There were many mentions of attributes like ‘simple’ or ‘a good overview of the process’. However, much of the commentaries around the process and element metaphors were less positive. The process and element metaphors are an area of concern moving forward with new versions of the prototype. 5. Conclusion and Future Directions In summary, we have been using the concept of structured surfaces to investigate both visual and interactive methods to make workflows more attractive, flexible, and useful for scholars. The work has resulted so far in a series of sketches and two prototypes of different workflow interfaces. The purpose is to offer an easy way to track information during the processes of document production and publication, while at the same time providing means to gain insight about the data. For the next versions, we are planning to address the issues that arose in the user tests, and also to implement additional new features to enhance the user experience and the awareness of the system. We chose these features through a combination of user experience results, reflecting on the appropriate literature, discussing the system with our collaborators, and experiencing the shortcomings of the first two iterations of the prototype. The enhancements are: a Zooming User Interface (ZUI) connection to text analysis tools dependency control of workflow stages tangible interactions, and affordances for customization and collaboration. One serious problem we identified is the high density of tokens within a stage. There are several possible ways to address this problem, including 624 Literary and Linguistic Computing, Vol. 28, No. 4, 2013 reliance on a larger display, resizing stages automatically to reduce token overlap, and implementing a ZUI. Mandating a large display size is the simplest solution from the developer point of view, but the least useful from the perspective of the user. Automatic resizing of components would require a much more robust automated layout mechanism. We therefore settled on the choice of using some sort of semantic zoom or ZUI. A ZUI is a form of intuitive interaction in which varying degrees of detail are displayed on screen depending on the zoom level defined by the user. ZUIs are common in map applications such as Google Maps, and they have started to be implemented as navigation functionality in mobile operating systems, as well as in Microsoft Windows 8. With a ZUI, the user could zoom in on a particular densely populated stage of the workflow to see more clearly. Zooming would also make room for other functionality, such as filters and sort options. On the analytics side we are planning to connect the workflow with Voyant, a collection of text analysis tools. We feel that having analytics ready to hand could introduce some important changes for editors, making tasks that are currently not even within consideration a simple matter to carry out. An editor might decide, for example, to take a look at a KWIC concordance for a term in every accepted article in the current edition, or run a word cloud on all the articles that have been accepted or rejected (see Fig. 6). The word cloud of acceptances might provide some guidance in writing an introductory editorial, for instance, while the cloud of rejections might help the editor see whether there is a possible 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. Comments and questions from collaborators also suggested some future directions for this project. One of the basic features in workflows is the dependency between stages. For example, the publisher might intend that an article should automatically be published after a final peer-review phase was done, and this could be accomplished by a rule that guides the workflow, without manual intervention. Visual workflow interfaces for editorial processes Fig. 6 Connection between Voyant and workflows could help users identify issues during the editorial process Without rules to govern the workflow, the system is less useful as a guideline and could even potentially confuse the users, for instance by implying that some additional task is required after final clearance by reviewers and before publication. With the correct rules in place, this automatic adjustment can be possible. Similarly, the system might prevent the tokens from being reallocated to stages that have dependencies if the prerequisite stage is not done (see Fig. 7). Customization and automatic layouts could help users to produce and organize their own workflows (see Fig. 8). In the current version, the workflow is prebuilt in the system. However, ultimately we want to let the users create workflows for dealing with their own data. A supervising professor, for instance, could create a workflow to manage papers, conference presentations and student thesis proposals in their different stages. Thus, the stages, status, and metadata could vary according to the use of the workflow. For this reason, automatic layouts may be useful to enhance the readability by organizing the stages and reducing crossover in the pathways. Shared workflows could improve the collaborative work in digital humanities. By sharing workflows, partners and collaborators could follow the jobs’ progress and get a sense of how the projects are moving (see Fig. 9). However, sharing workflows poses questions about authority to move tokens around the workflow, as well as the information synchronization. Finally, we also intend to extend the experiment to different devices—in particular multi-touch platforms such as smartphones, tablets, tables, and walls. On one hand the mobility of some of these devices could help project managers to keep up on projects and take actions whenever necessary (see Fig. 10). On the other hand, big displays on multi-touch tables and walls may provide a better way to see and manipulate the documents. At this point, we have some experience with two prototypes and quite a few ideas for an improved third. However, one issue where we have not yet made much headway is the one perennially faced by software developers, and also by researchers creating experimental systems in the digital humanities. The issue is the socio-cultural one of technology acceptance and the diffusion of innovation. Scholarly writers and academic publishers are not Literary and Linguistic Computing, Vol. 28, No. 4, 2013 625 L. Frizzera et al. Fig. 7 Stage dependency is a fundamental feature that involves rules to control information through the workflow Fig. 8 Sketch showing how to deal with workflow authoring and customization 626 Literary and Linguistic Computing, Vol. 28, No. 4, 2013 Visual workflow interfaces for editorial processes Fig. 9 The sharing feature could improve collaborative work by indicating work progress Fig. 10 Multi-touch devices could help project managers to keep workflows updated Literary and Linguistic Computing, Vol. 28, No. 4, 2013 627 L. Frizzera et al. necessarily early adopters of technology, and even if we were able to produce a system that is generally applicable and easy to use, it is not likely that this will be enough to gain widespread acceptance and adoption. Of particular significance in this respect is the collaborative work with stakeholders in the community, which needs to be broadened and deepened. Revisiting our decisions concerning the core process and element metaphors, as suggested by the user study, will also be an essential aspect of the next phase of the project. Acknowledgments This work was supported by a Major Collaborative Research Initiative (MCRI) grant for the Implementing New Knowledge Environments (INKE) project, received from the Social Sciences and Humanities Research Council of Canada (SSHRC), and led by Ray Siemens at the University of Victoria. Additional support was received from the University of Alberta, University of British Columbia, the IIT Institute of Design, and Mount Royal University. References Aalst, W. M. P. (2004). Business process management demystified: a tutorial on models, systems and standards for workflow management. In Desel, J., Reisig, W., and Rozenberg, G. (eds), Lectures on Concurrency and Petri Nets. Berlin: Springer-Verlag, pp. 1–65. Albrecht, B., Effinger, P., Held, M., and Kaufmann, M. (2010). An automatic layout algorithm for BPEL processes. Proceedings of the 5th international symposium on Software visualization. Presented at the SOFTVIS ’10. New York, USA: ACM, pp. 173–82. Barr, P., Biddle, R., and Noble, J. (2002). A taxonomy of user-interface metaphors. Proceedings of the SIGCHINZ Symposium on Computer-Human Interaction, CHINZ ’02. New York, USA: ACM, pp. 25–30. Berrick, S., Leptoukh, G., Farley, J., and Rui, H. (2009). Giovanni: a web service workflow-based data 628 Literary and Linguistic Computing, Vol. 28, No. 4, 2013 visualization and analysis system [serial online]. IEEE Transactions On Geoscience & Remote Sensing, 47(1): 106–13. Bresciani, S. and Eppler, M.J. (2009). The risks of visualization: a classification of disadvantages associated with graphic representations of information. In ¨t Schulz, P.J., Hartung, U., and Keller, S. (eds), Identita und Vielfalt der Kommunikations-wissenschaft. Konstanz, Germany: UVK Verlagsgesellschaft mbH, pp. 165–78. Lakoff, G. and Johnson, M. (1980). Metaphors We Live By. The Production of Reality: Essays and Readings on Social Interaction. University of Chicago Press, pp. 103–14. Lu, R. and Sadiq, S. (2007). A survey of comparative business process modeling approaches. Business Information Systems, 82–94. Luce-Kapler, R. (2008). The sideshadow interview: illuminating process. International Journal of Qualitative Methods, 5(1): 1–16. Organisciak, P., Geoffrey, R., Stan, R., and Susan, B. (2009). ‘‘Mashing Texts: Supporting collections-level text analysis’’. Paper Presented at the Digital Humanities 2009 Conference. University of Maryland, June 22–25. Radzikowska, M., Ruecker, S., Brown, S., Organisciak, P., and the INKE Research Group. (2011). ‘‘Structured Surfaces for JiTR.’’ Paper Presented at the Digital Humanities 2011 Conference. Stanford, June 19–21. Ruecker, S., Radzikowska, M., and Sinclair, S. (2011). Visual interface design for digital cultural heritage: a guide to rich-prospect browsing. Farnham, Surrey, England; Burlington, VT: Ashgate. Telestream. flow/. (2013). http://www.telestream.net/screen Versteeg, R. J., Alexander, N. R., and Trevor, R. (2006). Web-accessible scientific workflow system for performance monitoring. Environmental Science & Technology, 40(8): 2692–8. Virine, L. and McVean, J. (2004). Visual modeling of business problems: workflow and patterns. In Proceedings of the 36th Conference on Winter Simulation. Washington, D.C.: Winter Simulation Conference, pp. 1839–46. W3C (2011). Text - SVG 1.1 (Second Edition). World Wide Web Consortium (W3C). Retrieved from http://www.w3.org/TR/SVG/text.html (accessed 20 January 2012). Copyright of Literary & Linguistic Computing is the property of Oxford University Press / USA and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use.