Workflow
Workflow services will support flow construction and resource integration – tying together tasks and the resources needed to address them.
Libraries have always been eager to ‘fit in’ to their users’ lives. In a network environment, this increasingly means ‘fitting in’ with evolving network workflows.
Think reductively of two workflow end-points.
The first is demand-side: we are constructing flows and integrating resources in our own personal spaces. We are drawing on social networking sites, blogs, RSS aggregators, bookmarklets, toolbars, extensions, plug-ins. These are variably configured, stitched together by what I have called the intrastructure of RSS, bookmarklets, tags, and simple web services. Participation is also variable. Some are developing elaborate digital identities, a personal bricolage of network services. Others are less actively constructive, working with what comes straight out of the box. However, whether built into our browser or available from a growing number of network services, we will increasingly have rich demand-side flow construction and resource integration facilities ‘straight out of the box’. The advance of RSS and its integration with new Apple and Microsoft operating systems is interesting in this regard.
The second is supply-side, where workflow and integration have been pre-fabricated to support particular tasks. Think of a course management system, or a customer relationship management system. We will also see growth here, as processes are standardized and supported in applications.
One reason that supply-side customization and personalization services have not been more actively taken up is that it may be less important to me to be able to manipulate flows and resources within a supply-side environment than to be able to integrate them into my self constructed demand-side environment. So, for example the most important thing for me may not be to manipulate components within some user interface, or to have email alerts sent to me, it may be to have an RSS feed so that I can interact with a range of resources in a uniform way. The value may be in playing well with my aggregator, a central part of my workflow, of how I engage with network services.
Libraries and workflow
What does this mean for libraries? We have begun to realize more keenly that the library needs to co-evolve with user behaviors. This means that understanding the way in which research, learning, and consumer behaviors are changing is key to unerstanding how libraries must respond. And as network behavior is increasingly supported by workflow and resource integration services, the library must think about how to make its services available to those workflows. Many of our recent discussions have in fact been about this very issue, about putting the library in the flow. Think of the course management system. If this helps structure the ‘learnflow’ then the library needs to think about how to be in that flow. Think of Google. It has reached into the browser and the cellphone. It is firmly in the flow of user behavior, and as libraries and information providers want to be in that flow also they are discussing how best to expose their data to Google and other search engines. Think of the iPod. If this is the preferred place to manage my liquid content, what does this mean for library content?
Here are some examples I have come across recently which may make this more real.
The first is a general one. In the past month or two I have heard two presentations from public librarians talking about digital audio books, and suggesting that they will be popular. The reason given is clear: in an iPod world, digital audio fits nicely into the ‘commuteflow’ or, indeed, the ‘lifeflow’.
The second is from the very interesting work at the University of Rochester which seeks to understand research work practices in the context of the evolution of institutional repository services.
In the long run, we envision a system that, first and foremost, supports our faculty members’ efforts to “do their own work”–that is, to organize their resources, do their writing, work with co-authors, and so on. Such a system will include the self-publishing and self-archiving features that the DSpace code already supports, and will rely heavily on preservation, metadata, persistent URLs, and other existing features of DSpace. When we build this system, we will include a simple mechanism for converting works in progress into self-published or self-archived works, that is, moving documents from an in-progress folder into the IR. We believe that if we support the research process as a whole, and if faculty members find that the product meets their needs and fits their way of work, they will use it, and “naturally” put more of their work into the IR. [Understanding Faculty to Improve Content Recruitment for Institutional Repositories]
I hope that it is reasonable to read this work in this way: based on their investigations, Rochester staff recognise that they need to describe and deliver the service in such a way that faculty see it supporting their workflow. The library has identified a flow construction gap, to do with the writing and sharing of papers, which they hope to fill by providing workflow support through augmentations to Dspace. Looking forward we might surmise that future success will be more assured to the extent to which the new support is a natural extension of current workflows.
The final one comes from a presentation [ppt] by David Tosh and Ben Werdmuller which draws on their work modeling ‘learning landscapes’ in the context of the evolution of e-portfolios. They see the e-portfolio as a place where the student constructs a digital identity, which connects resources, experiences, and tutors. Connection is important, because learning happens in contexts of communication and exchange beyond the formal course structures. The VLE (virtual learning environment AKA course management system) which in the terms presented above is a supply-side workflow manager is one part of this landscape. A focus of this work appears to be to develop capacity for richer demand-side integration. Now, I do not have the context to assess this work in terms of its own discipline but I think it has nice illustrative value and is interesting here for a couple of reasons. One, the ‘library’ is not present in this iteration of the landscape. But, more importantly, how would one represent the library if it were to be dropped in? As ‘the library’? As a set of services (catalog, virtual reference, …)? If as a set of services, which services? And, if a particular set of services, how well would they ‘play’ in this environment? What would need to be done for them to be in the flow?
The importance of flow underlines recurrent themes:
- the library needs to be in the user environment and not expect the user to find their way to the library environment
- integration of library resources should not be seen as an end in itself but as a means to better integration with the user environment, with workflow.
Increasingly, the user environment will be organized around various workflows. In fact, in a growing number of cases, a workflow application may be the consumer of library services.
The message for libraries is clear: be in the flow.
Related posts:
Note: this post has been stewing in draft form for some time. While writing it I read Peter Brantley’s post on the ‘assembly’ of services. I like self-assembled and pre-assembled as ways of talking about some of these things.
Note: Cosmetically amended 7 April 2021 to improve spacing and to add headings and picture.
Picture: I took the feature picture of the Mississippi in Minneapolis.
