– 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.