Seminariet omkring vad de nya medierna kan betyda för teknikinformation har vi gett tre gånger vid det här laget: i Malmö, Göteborg och Stockholm.

Teknikinformation och nya medier (In Swedish) from Jonas Löwgren on Vimeo.

Nu kan man se mitt föredrag från Stockholm i april 2010, där jag pratar om hur folk kommunicerar och skapar tillsammans i de nya medierna, och varför de gör det. Jag talar också om vad utvecklingen inom nya medier betyder för teknikinformation.

Substrate is about collaboration and user participation around product information. But when established information producers look at Substrate, one of the key ideas is topic-based information production.

The step from producing documents to producing collections of topics, each corresponding to one question, can be quite daunting. Enter SmartShare.

The idea is to provide a lightweight tool for sharing information in work groups and on intranets. Initially, we expect it to be used mainly as a tool for sharing files. When you share a file through SmartShare, you can easily tag it and add some other metadata; access to shared files is through searching and faceting in a flat list, just like in the regular Substrate environment.

In fact, part of the point is that files shared through SmartShare are stored in Substrate as topics, and SmartShare users will also see Substrate-created topics appear and perhaps happen upon them when they search in SmartShare.

Thus, we expect to be able to support a heterogeneous production environment where most users stick with current information management practices and use SmartShare to coordinate sharing, but where some users make the transition to Substrate and become internal change agents for a more topic-based approach to collaborative information production.

Work is moving on to the detailed level of interface look and feel. Most, if not all, Substrate installations will have to be adapted to the graphical profiles of specific customers. Given that, it makes sense to think about the user-interface in terms of skins.

Here is a suggested dark skin that uses a gentle background pattern and semi-transparency on some widget borders to give an organic feel.

There are also some new interaction features in this set of sketches, including the dual-viewport mode that may come in handy for certain navigation and editing tasks.

For some demo purposes, it will certainly be necessary to have a lighter skin. Here is a sketch of a clean and basic treatment.

Is there nothing new under the sun? Are we merely re-inventing a sixty year old wheel?

As the package says, this is Substrat Pro: High Performance Filter Media, presented in a 60th anniversary edition of Quality and Innovation.

But I can’t really see how it handles user participation…

(Thanks to Jessica Lindholm for finding the can, and Mads Høbye for photographing it.)

The traditional approach in technical information is for the writer and producer to create the metadata, to markup information chunks and topics with keywords and categories. It is not uncommon for information producers to create a category structure, sometimes called a taxonomy or an ontology, and to use the keywords of that structure to characterize all the contents.

In the participatory media, in contrast, a practice has developed of collaborative categorization. It is most typically manifested in tagging systems of “user-generated content” sites such as Flickr and Delicious. The outcome of such collaborative categorization is called a folksonomy (from “folk” plus “taxonomy”; refer to Wikipedia for a good introduction).

Professional information producers are sometimes concerned about giving up control over the metadata, worrying that the resulting metadata structures will be less well-structured and perhaps even degrade into chaos. What if the users don’t understand the principles behind the information architecture? What if novice users spend a lot of time entering misleading tags? Why give up the benefits of hierarchical metadata structure for a flat namespace? What about redundancy and irrelevance?

It is tempting to ask the question of which approach is the best, which approach to choose — as if it was an either-or situation. I feel that would be a misguided question.

Instead, think of the two approaches as complementary.

In situations where an initial information set is created and deployed by an information producer, it makes all sorts of sense to provide producer-generated metadata as well. It helps structure production, it facilitates user search and access, it can provide users with overviews of a large material, and it can be used to handle customer regulations and other sorts of mandatory requirements on viewing the information set.

However, if there are openings for users to participate in the development of the information set (as intended in our ongoing work on next-generation DocFactory), then it seems obvious that the users’ categorization skills and socially constructed domain knowledge should also be tapped to create a more useful and meaningful information set in the long run.

There are several ways to create a hybrid approach.

Given the rough concept design described below, a rather participatory approach would be to implement a straightforward tagging system connected to the annotation function. Simply put, users could annotate contents with tags that they make up themselves or select from lists of already created tags. Since the user’s identity is stored with a tag (by way of the annotation function), this approach would support a rather powerful social search where you can, e.g., locate material based on tags created by selected colleagues. Moreover, the open tags would provide a good basis for computing clusters of related topics.

A more producer-controlled approach would be to see the user-generated tags as suggestions to be reviewed and possibly incorporated in the metadata taxonomy. A variation on this theme is to not create a parallel system for tags, but rather to open the facet structure and values to editing or editing suggestions by the users.

The general design guideline on the issue of taxonomy and folksonomy could be something like this:

Customer needs and contexts of information use can be expected to vary, where some cases would benefit from more user participation than others. Those cases are also the ones where a more open folksonomy approach to categorization should be explored. The platform should ideally support a range of categorization approaches from more to less participatory.

– a slightly long-winded post on the foundations for an integrated design in Substrate –

The heritage in many fields of information systems is to separate production and consumption of digital “content.” Historically, a video would be edited on a dedicated and expensive workstation, with specialized software that required specialized professional skills to operate. It would then be distributed for consumption through some sort of broadcast channel, most typically TV. The same goes for music, web sites, and even typeset text. The infrastructure for production and consumption matched the specialized nature of media production that was prevalent at the time of traditional broadcast mediascapes.

As we know, the mediascape is changing rapidly towards a situation where most people combine production and consumption, albeit in varying degrees. Ubiquitous tools for creation and distribution of digital media has meant that the ratio of non-professional production has grown massively: photos and videos from cellphone directly to Flickr, Facebook and Youtube; music made in Cubase directly to MySpace; texts via blog engines directly to the open web; and so on.

This development entails not only that many more people today enjoy tasks that used to be reserved for professional producers, but also that production becomes more collaborative. Digital material that is created and distributed becomes the raw material for further development, sampling, re-purposing and mashing up. The production–delivery–consumption life cycle becomes a drawn-out process of continuous development; it is not always easy to spot the “final products” in the digital mediascape.

So much for pompous introductions; let us now turn to Substrate. The existing structure of DocFactory is a traditional one in which the production tools for technical information (TI) are clearly separated from the viewer. This has two problems, in light of the developments outlined above.

First, and most importantly, it enforces a separation between information producers (“technical information writers”) and information consumers (“end users”) that makes it hard to think about broader participation in creating, assessing and refining the information. We know from research that, e.g., maintenance professionals oftentimes hold great amounts of specialized and contextual knowledge on how to operate certain equipment. For the information producers to try and elicit that knowledge, interpret it and distribute it back to the work context in the form of static TI documents is a cumbersome approach. It seems more powerful to create a platform where situated learning can take place directly in the workplace, where the more experienced professionals can share their knowledge with their colleagues in a more close-knit and contextually relevant structure. What this means in terms of system design is that certain production functions must be available not only to the TI writers but also to the end users, in order to provide means for engaging with the content rather than merely consuming it.

Secondly, the benefits of WYSIWYG (What You See Is What You Get) editing are nowadays taken more or less for granted. If you need to create or edit a piece of digital content, it is generally faster and easier for you to see immediately what it will look like and to make your changes directly in the final representation. In terms of Substrate, this would suggest that aspects like topic structure, topic contents and facet values should be accessible for editing direcly in the environment where they are viewed. This would encourage a tight loop between browsing, viewing and engaging with the technical information in the system.

This approach has some caveats, of course. There are settings in which organizational practices dictate that all information has to be formally approved. In some cases, security regulations may demand that certain information remains untouched.

Consider the three general concepts we designed for the Substrate platform. In the first one, the traditional roles of producer and user are essentially upheld. The third one is the most extreme in terms of making everyone technically eligible to produce content. The one we have developed further represents a middle ground in terms of production/consumption integration, where “users” can annotate topic content but not directly edit it or create new topics. A more sustainable approach would be to integrate content editing into the design and judge on a case-to-case basis whether access to the editing tools should be granted.

More generally, what this boils down to is to build a flexible privilege structure into Substrate to control access to various functions, and to study in each particular case how it should be deployed. What is important is to not routinely separate system actors into producers and users with default privileges. I am convinced that there are many cases where more involved and participating “users” will yield better TI quality and a better experience for the people using the information.

The first version of a complete interface sketch for interaction functionality and flow was made in early December. It covers pre-selection and a main interface state focusing on the topic list, from which the main user functions are available:

• faceting
• searching
• sorting
• viewing
• annotating

The image below shows the main state with a topic selected in the topic list. Facets are to the left of the topic list, global collections of topics are to the right.

(Click the image for a version at readable size.)

Compared to previous sketches, the most notable differences are that text search has been moved to operate on the current topic list, thus placing it on equal footing with faceting (since we expect searching to be a quite common strategy). Further, the whole idea of tagging has been lifted out of this version. We are concerned that tags may be too similar to facets in terms of what they do, and that users may be confused rather than benefit from them.

The emphasis in terms of user participation is rather placed on annotations — the following picture shows an interaction state where the user has read an annotation in a topic, then started adding a reply.

(Click the image for a version at readable size.)

Another important change is that there is no longer any notion of a pre-defined table of contents, since it becomes an illogical restraint in faceting. A similar, and probably more effective structure can be achieved by working with facet values corresponding to general groups of topics.

The current version is elaborated enough to form the basis for a prototype specification, as well as for user testing if that should be deemed important. The whole task of visual look and feel remains to be done, but we expect to be able to do it in parallel with functional/structural prototyping.

Finally, an interesting property of the current version (which corresponds to a bare-bones version of concept “Flickr” in terms of user participation) can be expanded in the direction of concept “Community” by integrating editing tools into the same overall interaction paradigm.

What we would get then is a WYSIWYG production system where the amount of editing functionality available to a specific user is determined strictly by that user’s privileges within the system. This is an approach that we believe has serious advantages over developing a separate production module using different interaction concepts and forms of representation, and we would like to explore it further.

One of the early activities carried out in the project was to start a field study. The first part, finished in mid October, aimed at making a survey of existing field studies conducted into how organizations and individuals inside organizations use technical information, such as manuals, but also in general how knowledge is produced, documented and used within professional contexts. One of the goals was, of course, to get a grip of state-of-the-art studies on the use of technical information, as well as to point to interesting design openings.The field study will be a continuous activity within the Substrate project; in time, the initial survey will be complemented with empirical work together with one of Sigma Kudos’ clients, and there will be increasing alignment with ongoing concept development. 

The survey includes more general aspects of organizational learning since it seems like problem-solving and learning through the use of technical documentation is increasingly being acknowledged as more than individual use at single moments. A specific emphasis is on the concept of situated knowledge, and on social and narrative dimensions of professional use of technical documentation. Some of the insights point to design openings in the form of blending of information types, using documentation as a collaborative effort, the need for coupling between users, writers and manufacturers, the technical communicator as an agent of change, social dimensions and narrative dimensions. 

The survey shows that the field of technical communication, and how professionals use technical documentation, is widening its scope. There is a move from a view where the documentation is seen as rather “self-contained”, providing the support to accomplish a task. It is increasingly recognized that learning from technical information takes place not only in the single moment of use, but also in a larger temporal span. This larger learning context includes a blurring between individual use of instructions and collaborative social and informal “talk” between professionals. 

It is a plausible conclusion that Sigma Kudos can strengthen their position as information provider by looking further into how these dimensions can be exploited as to further augment DocFactory. 

Some observations from the survey deserve particular mention:

The blending of information types. Users are becoming more and more skilled in using heterogeneous information formats. It is common (and expected) to use information outside of the traditional documentation.  From the studies reviewed it becomes obvious that visual material is highly valued in many situations, not the least in trying to couple verbal accounts to what is actually in front of you.  Schematics seem to be frequently used, but in complement one could well see that rich media, such as video or sound can be a rich resource. While some of it might be pre-produced as part of the documentation process, one could also well imagine that “lightweight” production can take place on the fly, for example using mobile phones, when for example a technician solves a problem he knows to be rather uncommon. The other way around, recordings could be made as part of a request to others, where a verbal account might be hard to articulate. 

Using documentation as a collaborative effort. The collaborative dimension of using technical documentation is becoming more acknowledged.  There are several ways to tackle this perspective. Some strong candidates include social bookmarking or ranking. Other possible collaborative efforts worth looking into might be wikis, blogging or mechanisms such as collaborative searching, where other expert searches are made visible, or where a simple notification of whom have searched for the same information may be valuable.

The need for coupling between users, writers and manufacturers. Participatory processes are called upon in most of the studies looked into. In many cases they are needed if innovative approaches are designed. We must also remember that the contextual conditions in specific cases might provide specific issues to address that are hard to understand “from the outside.”  This might also point to the need of instantiating experiments in joint efforts together with a client.

 Technical communicator as a change agent. It seems likely that most new interfaces and mechanisms for using technical documentation will be less than effective unless the existing methods of use are challenged as well. Sigma Kudos should reflect upon whether they would like to take a pro-active part in widened organizational learning attempts. In some of the studied cases success of the project was not the proposed concept as such, but rather the way the project engaged in instantiating processes where the concept was pragmatically tried out, thus instantiating new learning processes in the organization at hand. 

Social dimensions. Already we can see how social dimensions are tried out at organizational levels, as being part of problem-solving and learning. This overlaps very much with the criteria of collaborative efforts, and similar aspects could be explored (social annotations, joint searches, blogging etc). The main difference is perhaps that in many cases the informality of social talk is highly valued. Providing mechanisms for informal talk is something different than prompting for collaborative participation. 

Narrative dimensions. The blurring of formal articulations and informal narrative “talk” seems like a strong resource in problem-solving and learning as a complement to technical documentation.  In many cases the informal narratives could be “hard facts” for a person in need of someone else’s knowledge. Just as in the case of social dimensions, it could be a mistake to prompt for articulate descriptions. Rather it could perhaps be a case of providing a space for telling stories that could be of different character, ranging from “war stories” to explicitly articulated descriptions of fixes. Stories can take on different formats, and do not necessarily have to be understood as verbal accounts. Storytelling can also be done in videos, drawings, etc. It would be interesting to see examples which are not separate from the documentation (one manual and a separate forum), but to see it as part of the documentation, perhaps as a layer, view or facet.

The next topic for attention in late November was the detailed behavior of the dynamic faceting. The aim was to design a mechanism that was driven by the nature of the contents as much as possible. Faceting in situations where every topic has only one value in each facet was seen as fairly straightforward; we concentrated on two cases that we found slightly more complicated.

One case is where some topics are marked-up with multiple values for certain facets. What this implies is that a selection of a facet value during faceting may result in a set of selected topics that have also other selectable values for the same facet.

The other challenging case is where there is a hierarchical structure of facet values for certain facets. This case is often found in product data management (PDM) systems and we found it necessary to address it in order to provide a comprehensive production/use environment for technical information.

(Click image for a version at readable size.)

The sketch treats the two cases above in some depth. The first case shows how the user combines two facet values from the same facet. In the second case, the sketch shows how a hierarchical facet value structure is flattened through inheritance to provide a user experience similar to the first case.

Our general approach is to limit faceting to simple conjunctive selection. We expect this to be easy to learn for users without previous faceting experience, yet powerful enough in combination with text search and sorting to enable users to find the topics they need.

Facet values are selected as on-off toggles instantly shaping the current selection of topics in the topic list.

The first attempt to take the concept to screen designs was helpful in catalyzing a rather focused discussion in the development team.

The discussion highlighted a range of considerations:

• The main result to be shaped by, e.g., faceting should be a list of matching topics, rather than the contents of a specific topic.
• Text search is a selection strategy that can be expected to be as important as faceting.
• In some use settings, the number of topics may be too large to allow for dynamic faceting of the full contents.
• In some use settings, it may be necessary to require users to read certain topics before they can be allowed to start browsing the contents freely.

A revised version was developed in mid-November to address these considerations.

(Click image for a version at readable size.)

The new version introduces the idea of progressive refinement to handle large numbers of topics with acceptable performance. At login (state 0), session-wide selection may be performed of, e.g., the language version associated with the current user’s profile. In state 1, key facets, text selection and required topics are active in a modal screen. Once that step is completed, it is assumed that the number of remaining topics is small enough to allow for dynamic faceting.

The key facets and text selection box are collected in a top flap which animates out of view after the selection in state 1. The flap can be opened again at any point during the session to revise the state-1 selection.

Dynamic faceting, sorting and tag filtering are the user’s main tools for manipulating the topic list. (See states 2, 3 and 5.) The ideas of useful sorting orders are carried forward from the previous sketch:

• “Implicit”: Table of contents, Most used, Alphabetical.
• “Flickr”: Table of contents, Most used, Most annotated, Alphabetical.
• “Community”: Creation time, Most used, Most annotated, Alphabetical.

When a topic is selected for viewing, the user can add annotations to it. (State 4.)