Hello, everybody. I believe that some of you share a common issue with me. We have to deal
with many documents on different stages, especially when you're talking about big projects. Piles
and piles of documents spread off in many folders waiting for tagging, revision, approval,
or wherever it needs to be completed. There are workflow managers to tools available to
help us, but they are often too specialized and somewhat complex to use. So how can we
make them easier and more flexible? I'm here to present Inky's recent work on supporting
the creation of digital materials. We are using the concept of structure surface to
investigate both visual and interactive methods in order to make workflows more attractive,
flexible, and useful for scholars. First, I would like to briefly describe what is Inky
and what we do. Then I will give you a short explanation about workflow and how they have
been used. I will also explain what structure surfaces are and how the concept can be applied
to workflows. In the sequence, I will show you a prototype that we are working on, according
to the second version. Finally, I will point out some future directions for this project.
Implementing new knowledge environment, or Inky, is a seven-year Canadian research project
currently in the end of year three. Inky is led by Ray Simmons at the University of Victoria and
has two long-term goals. First, contribute to development of new digital knowledge environment
that build on past textual practice and extend them into digital age. Second, understand how to
combine the traditional strength of print and the advantage of digital environment in order to
produce and integrate digital reading tools. I need some water. So, back to workflows.
Many documents in digital humanities involve either digitalization or enrichment of existing
digital materials. The process usually is very similar to editorial jobs and can be understood
as a workflow. A researcher first enters the raw text, then encodes, proofs, and tests the results.
There is a process or a workflow to be followed.
Tools for workflow management often take the form of structure checklist composed of collection of
stages with transitions, including occasional decision points between them. These tools are
widely used in science and business to describe production of process models. Recent work in
computing science has focused both on workflow analysis and algorithm for automatic layouts.
The amenities 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 open monograph system. However, they are built specifically for certain tasks,
making them difficult to adapt and somewhat complex to operate.
There are different approaches to build a workflow. Some methodologies offer better
expressibility using graph-based models, other focus more on the complexity of model checking.
We are interested in producing a visual interface that combines workflow management
with an analytic tools that could be used by scholars. Based on our previous work,
we began to consider a workflow manager as a kind of structure surface.
According to Radskowska, a structure surface is a cognitive interface artifact that provides a
layer of meaning that supports the data imposed upon it. In a workflow manager, the process could
be represented by a structure surface and the documents as tokens that move over the surface,
similar to a casino roulette. This strategy could also be used to provide the user with a set of
analytic tools in the form of data visualization. The interface here seeks to retain the modularity
and flexibility associated with workflow systems while offering a rich prospect visualization of
the collection being managed. We propose that workflow as structure surfaces would offer an
easy tool to track information during the process of production, providing means for people to gain
insight into their materials, while also supporting them with some way to formulate an argument about
the data. So in the early stage of this project, we use a generic workflow from the world of
journaled stewardship, although there wasn't any real content with just placeholders at that time.
We choose to start with web standards technology such as HTML, CSS,
and JavaScript. So we start with a tool called D3.js, an open source JavaScript library for
creating data visualization. The goal was to launch the workflow from Jitter, a collection
management tool developed for such experiments. The surface for organizing the status of documents
is a pipe and flow type of workflow. The process is read from the left side where each document
must be accepted before beginning its life within the workflow. Each stage of the process represented
by a rectangle is a milestone such as decision points in progress work and standby moments.
The colors reflect the status inside of the workflow. Work in progress is the dark gray,
neat revision is the yellow, rejected, red, and accepted the green.
The articles are represented by tokens. The token's position within the workflow indicates where
along the process the article is located. The size illustrates the length of the documents in words.
A rollover in the token shows detailed information about the articles such as the title,
the abstract naming contact information of the reviewer, and the date when the article went to
the reviewer. What we found with this experiment was that too much information is contained in the
structure surface with very little in the tokens. In our next iteration, we explore placing more
information in the tokens which allow us to declutter our surface. In terms of technology,
we also identify a limitation. Whereas the 3.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 W3C recommendation websites,
scale vector graphics or SVG performs no automatic line breaking or word wrapping.
Since the 3.js use SVG to render graphics on the screen and we want to show multiple lines
of information, we decide to look for other options. For our second version, we are
experiment with Adobe Flash. Some people might argue that Flash is not the best option since
it's not supported by smartphone, mainly iPhones and tablets. Nevertheless, it is possible now to
recompile Flash apps in order to create mobile apps for iPhone, iPad, Android and even Blackberry
and Playbooks. Adobe built in this feature in Flash Professional and Flash Builder. Although
to create apps for Apple devices and put in the App Store, it's necessary to be part of Apple's
developer community that we have to pay like 100 bucks per year. Regardless of the technology used
to develop any application, we found that Adobe Flash is a good option to create interactive
interface prototypes, which is the main goal of this research, as we are not creating final
products, but instead we are doing experiments. We also decide to produce an experiment with more
meaningful data. So we partnered with Susan Brown and the Orlando Project. We used some of their
editorial jobs, which include the writing of XML encoded original materials for Orlando biocritic
entries for women writers. 54 biographic entries were used as sample for a purpose of this prototype.
Since we moved from a hypothetical workflow to a workflow predefined by Orlando Project,
we had to redesign both the process and the structure surface.
The workflow in Orlando has some particularities. For example, some stages are not sequential,
but required in order to let the documents continue in the flow. To illustrate this
characteristic, we grouped the steps in a cluster with a light grey background.
Another particularity is the existence of operational stages, which can occur independently
of the document stage. It is represented up there, disconnected from the mainstream.
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.
In the first, we tried to organize the tokens like one next to the other, but can be so many.
So in order to save some spaces, the token's position inside the stage is random. So they can
stand one at the top of the other. They are color code in order to show status information.
So instead of putting the color code in the steps, we put in the tokens. The white is when
the token begins a stage. The blue, when someone is working, works in progress. Incompleted tokens
are red and completed as green. A counter box shows the number of documents held by each stage.
As in the first prototype, I belong showing the type of documents pop-ups when the user clicks on
it. However, what happens in the second prototype is that more detail is available for each token.
A double click makes the token bigger, revealing a circular control panel and general information
such as title, collection, and the current stage and status of the document. The control panel
gives three options to the user. First, access the history log, which shows the document's progress
in the workflow. The logs are displayed in a reverse chronological order showing when someone
performs a modification and gives the name of the person. Second, access the status feature that
enables the user to change status information of the document. And third, a tag mark, which turns
on a star icon, making it easier to follow a particular token to the workflow. Another
functionality is the possibility to drag the token around. This version, the user can drag
the token to any stage in the workflow regardless of the sequence. By doing that, the user automatically
changed both the stage and status of the document. Every modification performed in the workflow is
autosaved and generates a new log entry in the history. The system also prevents tokens to be
released outside of the stage by automatically moving it back to the former position. Otherwise,
the stage, sorry, otherwise it could disrupt the workflow and confuse the users.
Some issues arose during the process of development of this version. The most important
is how to deal with high density of tokens inside the stage. Whereas it's easy to access
one document in a lightly populated stage, in those with high density, the fact of tokens
overlap each other can challenge the user to find or access information. Another issue is that the
distribution stages in a linear sequence seems to be a poor representation of 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 in different stages of the same article. How to represent,
for example, an article that has one person doing the lead review
at the same time that another person is digitalizing the data for exploration.
For the next versions, we are planning some features to enhance the user experience and
the awareness of the system, such as, first, implementing a zooming user interface using
semantic zoom, which is a form of detail on demand that lets the user see different
amount of information by zooming in and out. It's just like Google maps when we have a broad vision
zoom out, you can see the whole country, and you want to see more detail just zoom in and you can
see the street view. So the same thing here. It could solve issues regarding the high density
of tokens and make room for other functionalities such as filters and options and sort options.
Second, implement the collapsing stages that could simplify the flow chart and give the users the
options to hide some steps that might not concern them. And third, a notification center to help the
user to keep track on updates, just like iPhone does when you receive an email, you just make a
sound or something like this. On the analytics side, we are planning to connect the workflow
with Voyan, a collection of text analysis tools. An editor might be the site, for example, to take
a look at a quick concordance for a term in every accepted article in the current edition or
run a word cloud on all articles that have been accepted or rejected. The word cloud of acceptance
might provide some guidance in writing an introductory tutorial, for instance, why the
later might be helpful to the editor see whether there is a gap in the reviewer expertise at work.
Support for this sort 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 suggest some other future directions for this
project. One of the basic features in workflows is the dependencies between stages. For example,
an article should just be published after a peer review phase was done. Without rules to govern
the workflow, the whole system seems to be a guideline and could confuse the whole process
of production. One way to solve this problem is to prevent the tokens from being relocated to
stages that have dependencies if the work in the current stage is not done. This is one of the
first sketches that we are doing, the idea that if you move a token from one stage to a future
stage that has some dependencies, it just prevents you to move. And if you release there, the token
just moved back. Customization and automatic layouts could help users to produce and organize
their own workflows. In the current version, the workflow is pre-built in the system, but 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 stage status and the whole 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.
Again, this is just the first sketch of a screen that how we are imagining the
authority way of creating workflows. I think that we can start with just one step
and let the user click on the plus button and create the workflow.
Another idea is the shared workflows that 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. However, shared workflows pose questions about
authority to move talkings around the workflow as well as the information synchronization.
This screen, if you use Google Docs, it's almost the same idea that you invite people to
be part of your workflow as a viewer or as an editor.
At last but not the least, we also intend to extend the experiment to different devices.
In particular, much touch platforms such as smartphones, tablets, tables and walls. On the
one hand, the mobility of some of these devices could help project managers to keep up on projects
and take actions whenever necessary. On the other hand, big displays and much touch tables and data
walls may provide a better way to see, manipulate and manage the documents in big projects.
However, we have yet to perform usability tests in order to confirm or refute our assumptions
and the interface effectiveness which we are planning to start during the next semester.
In short, we have been using concept of structure surfaces to investigate both visual and
iterative methods in order to make workflows more attractive, flexible and useful for scholars.
It results so far in a series of sketches and prototypes of workflow interface for
editorial process management which the purpose is to offer an easy way to track information during
the process of production at the same time that provides means to gain insight about the data.
Thank you.