Designing Practice-Oriented Interactive Vocabularies for Workflow-Based Virtual CoP
The author suggests that the research into virtual communities of practice are often vague on the "practice" elements and lean toward the topic of community management, which is a "distinct and different" are of concern. As a result, the need to support practice, itself, has largely been neglected.
To examine the concept: a "practice" is generally defined as a set of specific goals. The achievement of these goals requires individuals to undertake specific actions that are driven by knowledge, skill, and competency - but there may be significant differences in the actions undertaken by individuals in pursuit of the same objectives.
These differences in action present a challenge for those who would undertake the task of providing the means for practitioners to collaborate - specifically, in the vocabulary and actioons used by practitioners in the same community, as expressed in the collaborative tool-sets provided by communities of practice to facilitate collaboration among their members.
The present article will briefly review existing literature on this topic, and consider two case-studies, with an aim of providing guidelines that can be useful to developers of practice-oriented toolkits.
UNDERSTANDING PRACTICE IN VIRTUAL COMMUNITIES
It's noted that there is presently no "unified theory of practice", though theoretical consideration of the subject seems to be increasing.
The author regards activity theory as "particularly useful," particularly the work of Jarzablowski, who separates the notion of activities from practices: an activity is a simple action, and activity pattern is a sequence of actions that occurs repeatedly, and a practice is the consideration of activity patterns that are germane to specific set of related objectives.
It's also noted that practice is related to performance - in the sense that skilled actors rely on both codified knowledge and personal experience to determine what actions to undertake to achieve a desired outcome, or what deviation must be made from "normal" activities in order to account for the specific circumstances.
And on the rand scale, a community of practice is normative, in that it gathers the collective wisdom of practitioners within a community to define the most efficient and effective activity patterns for accomplishing the objectives within a profession (which are also subject to definition by the community).
It is suggested that the community of practice is subject to abstraction and misrepresentation: there is a difference between that which a practitioner does, and what they claim to do, whether this is the result of accident or intention, of happenstance or intention. Said another way, when discussing practices, practitioners tend to portray what they feel they should do, rather than what is actually done, in moments when they are reflecting on past action or projecting future action.
This is as true of physical communities (guilds and trade associations) as it is of virtual ones, though a virtual community has an added layer of abstraction, and since it encompasses a broad array of participants, it may be found that there are conflicts between local practices and community practices (consider a community that attempts to define marketing practices that involves participants from multiple countries and cultures).
This difference also has an impact on the choice of collaborative tools, as they may reflect the activities and needs the designer, informed by practitioners, believes to be necessary rather than those that actually are necessary - hence the tool becomes cumbersome and counterproductive to the degree that it does not reflect the actual needs or support the actual actions of practitioners.
DESIGNING TOOLKITS FOR COORDINATIVE PRACTICES
The design of toolsets for collaborating among practitioners involves consideration of the vocabulary and practices to ensure that the toolset is suitable to the task. By necessity, the tool will be designed to perform certain function and, by necessity, will accommodate only those functions, until such time as it can be upgraded to include other capabilities.
Part of this task involves the development of a practice vocabulary and the development of visual symbols that can be used and combined to communicate in the context of that vocabulary (though it is noted that "visual" is the typical approach, and not necessarily the only approach, though non-visual approaches are rare). As an example, consider the shapes in a flowchart and a method for combining them and showing their interrelations. Most professions have such a visual language that can be adapted to the online medium. For others, they may need to be invented.
Recently, there has been considerable effort placed on developing domain-specific language (DSL) for a variety of professions and purposes, primarily in engineering and technical fields, but also branching out into other areas of academic interest. However, DSLs tend to be very specialized to a specific task, and a given community of practice may utilize a variety of DSLs for specific tasks.
The author defines two purposes for tools - the first (mutual awareness) is the ability of an individual to communicate ideas to others in a method that can be easily and universally understood, and the second (collective practice) is the ability of individuals to work collaboratively on ideas.
Ultimately, awareness of others' activities enables members of a community to learn from one another, and to make collective progress rather than each member working redundantly on problems that have already been solved. There are, however, boundaries to awareness: The degree to which an individual is expected to disclose information to the community can become a concern for privacy or confidentiality. Likewise, the over-communication of granular information often becomes a nuisance that obscures information of value in a plethora of chatter.
CASE STUDY: MUSIC LEARNING COMMUNITIES
The author describes a collaborative tool developed by the "diamouses" project to facilitate communication in the context of teaching and studying music theory, leveraging the conventions of musical annotation and the sharing of "sonic artifacts" (audio clips), in an interface that provides the ability to play the audio clip, view and manipulate the score, and communicate comments via text. The author provides some details about the tasks facilitated: viewing and manipulating the score, using a "floor manager" to take and release control, and various annotations and markings to the score.
(EN: the author merely presents the tool, via screenshots and descriptions. I don't intend to duplicate them here. The key concept, I believe, is that the online tool leveraged the existing conventions of "sheet music" to provide a visual representation of a phenomenon that is experienced by other means, and because music students understand the vocabulary and conventions of musical annotation, I expect this to be a better approach than attempting to invent a new method to depict music in the online medium.)
CASE STUDY: PRODUCT DEVELOPMENT
The second case-study describes the "ekones" project (which is also discussed in chapter 21 of this book) as a method for travel agents to create vacation packages for their customers, which involves the analysis of customer preferences and the consideration of services available in the destination. This solution appears to involve two separate communities: one of travelers who share information with one another, and a second of service providers who assemble the vacation packages.
It's also noted that the solution entailed the development of a "package" to suit the immediate interests of the customer, not the creation of a "standard package" that prospective customers would consider as a single take-or-leave decision. However, by leveraging the information generated in the community, the provider could present a suggested package as a starting point, and the final package (which reflects changes made after discussion with the customer) could be used to improve the quality of the "starting" package presented to future customers.
Decisions about the components of a package can be schematized on an activity schedule, as all elements of a vacation package have a quality of time: transportation and events occur on a calendar schedule, and even things such as meals and lodging are consumed during a specific time and in a specific location. However, it's noted that each of these elements has unique characteristics (scheduling a bus trip has different information than reserving a table at a restaurant) outside of their common features (start and stop times).
The result was an "activity panel" that looks much like a calendar in Microsoft Outlook, with events color-coded to their type (travel, lodging, meal, event, etc.), each with start/top times and possible recurrence (three nights in the same hotel room), each with click-through capabilities to view information about the specific activity. Both the service provider and the customer have the ability, at different times, to add/edit/change items.
IMPLICATIONS FOR TOOLKIT DESIGNERS
The author mentions that there are community communication tools such as chat, blogs, wikis, message boards, etc., but restates that the focus of the present chapter is the development of collaborative tools that are not merely variations on text communication (though text communication may be a component)
Of importance: the toolkit should be designed to a specific "protocol" in the context of a virtual community. Just as a message board and a chat room are presented as options for communication that the members can use as appropriate, so should collaborative tools be an option for communication and collaboration (rather than the default "portal" of a community).
There's also the assertion that the practice toolkit should be made available to every member of the community, or every member. (EN: it's not clear to me what he's getting at here - whether he's suggesting that the members should not have to pay for the software, or the operator should not seek to prevent any of the members of using it. It would seem natural that a "community tool" would be used by all members of a community, but I'm not sure if the responsibility of paying for it always must fall to the operator. A community of designers should not be prevented from sharing Photoshop files, nor should the operator be expected to furnish a copy of the software to all members.)
Workflow management is also critical to design: deciding which "roles" have the ability to create a task or document, and how to manage the ability of multiple users to interact with it (making conflicting changes or overwriting one another's work) must be carefully considered. However, one must also consider the degree to which "control" is in conflict with the efficiency of existing practices, and sufficient flexibility is provided so that the toolkit supports, rather than limits, the actions its users need or desire to undertake,
The author also notes that the design of a toolkit for a community of practice must be domain-specific. It cannot be a "general purpose" tool such as a word processor that seeks to suit a wide range of possible uses, but one designed specifically to the needs of the community. For example, many word processors have features that will enable users to format complex mathematical equations, but they tend to be very clumsy and deeply buried among the various bells and whistles.
The author also includes several paragraphs to underscore the importance of designing user interactions, which fundamentally underscore the need for principles of usability and task design to be considered. (EN: there are other sources which provide more complete detail, so I'm not preserving notes on the author's discussion.)