Improving the effectiveness of information

I have an annual travel insurance. It is not that I travel a lot, but it gives me the flexibility to come and go whenever I want. It saves me the trouble of ordering a new travel insurance for every vacation and it guarantees me that I am always insured. You could say that it provides me with the suggestion of freedom to travel. But isn’t it strange that I need to take an annual insurance, just to avoid the hassle of ordering a new insurance every time I want to travel? And what about my coverage? Should I choose worldwide coverage just in case I want to travel outside of Europe? And why do I have to pay for the days that I am not traveling? I demand a personalized product that automatically adjusts itself too. And I only want to pay for what I use We are the ‘click and buy’ generation and these days, everything is getting personalized. In a series of articles on contextual intelligence and robotics, I want to give you insight in the state of the technology and it's appli...

I have bought a new coffee machine this weekend. Not that the old machine stopped working, I just didn’t like its coffee anymore. The old coffee machine was one of those Senseo machines, very cool 10 years ago, but not really living up to the expectations when it came to the quality of the coffee. Plus that you really needed to apologize up front to visitors for having such an example of ancient technology in your kitchen. But then the new machine: it is cool, it is white, it is small and it makes excellent coffee. Even better: by buying it I became a member of an exclusive society of coffee enjoyers, amongst who George Clooney is probably the best known. So with high anticipation I unpacked the machine. First came the exclusive black menu card holder, containing a menu card with an overview of all the special flavors that were now within my reach and an invitation to become a member of this exclusive coffee drinkers club. Next came the starters set with 16 exclusive coffee cups...

The new Healthkit app and the improved Siri in combination with HomeKit - introduced in the new Apple iOS 8 - are two perfect examples of how contextual intelligence enters our daily lifes. Although Healthkit seems to be focusing on monitoring, making it possible to share this data with your doctor, the next step could be that your phone advices you to go on a diet (or even tells you what to eat) or go to the hospital. Siri in combination with HomeKit is also interesting. If you tell Siri (your phone) that you go to sleep, the HomeKit system is able to switch off heatings, dim the lights and lock your doors. What I would find interesting to see is what happens if you add more context data to this system, like data from a video surveillance system in front of your door, or location data provided by your phone. Combine these with dynamic rules and you could have doors that automatically unlock in front of you and lights that follow you through your house (when it is dark). I have f...

In the previous episodes of this blog about writing effective articles, we have looked at two things: Defining your goal Defining your target audience Now that we have a clear vision of our goal and know for who we are writing this article, the next step is to create a conceptual model of the article. It is like creating the blueprint for your new home: starting as a sketch and in a number of increments it gets more and more detailed until you have reached the point that you can start decorating the house. Creating the overall plan for your article During my study in Linguistic competence, I learned to represent the structure of my text in an hierarchy. While this may work for informative articles, this is in my opinion not the best approach for goal-driven articles. For a goal-driven article the overall structure should in my opinion look like a process: a serial structure of steps leading towards a conclusion.  In this first rough sketch of your article, you start to defi...

Digital technology has allowed the documentation process to evolve from single document-centric to single source-centric: From creating individual manuals to creating re-usable chunks of information for a series of product and document types through various channels. Figure 1. Documentation evolved from document centric to single source centric Example A manufacturer of agricultural machines needed a complete line of documentation for its new type of harvester. In a document-centric approach, this would mean having one technical writer create the user documentation, another writer create the service manual and a third create the on-line help. In the best case they would copy chapters or paragraphs from one manual to the other. All of these documentation types would need to be reviewed by hand and individually updated when the harvester’s features changed, or new rules for its safe operation were implemented. In a single source environment, multiple writers work on discrete top...

"In engineering , a requirement is a singular documented physical and functional need that a particular product or service must be or perform. It is most commonly used in a formal sense in systems engineering , software engineering , or enterprise engineering . It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user." Source: Wikipedia During the Building Business Capabilities conference 2012 in Fort Lauderdale, we are going to develop a working model-driven business application, based on the input provided by the audience. And although this will be in a "lab" situation, we want to stay as close to a real life situation as possible. And then working with requirements is an essential element. Both requirements and the Be Informed modeling artifacts (models, profiles, custom meta models) are aimed at the same goal: allowing the stakeholders of the system to ...

In my last blog I explained how we can distinguish three phases in the development of documentation. The first phase was a very product centric one, while in the second phase we see a more process driven approach. Re-use gets more and more important as is collaboration with other writers. But what about the users? How do they benefit from this move to single sourcing? Sure, creating and translating documentation becomes cheaper and easier to manage, but having documentation in your own language is for most people normal and not seen as a usability feature. And then there is the issue with information overload. Maybe we should ask our users what information they need, instead of just providing them with everything we want them to know. To really help our users, we should move on from our process centric approach to a more customer-centric one. A customer-centric approach Documentation 3.0 is all about offering the right documentation at the right time. It is customer-centric, which mea...

The trends in documentation of the past 20 years are under heavy influence of the development of internet technology. Like with the web – where we distinguish between Web 1.0, Web 2.0 and 3.0 - we can see three phases in documentation. I will call them Documentation 1.0, Documentation 2.0 and 3.0. Where Documentation 1.0 is - like Web 1.0 - very much centered on individual products and information, brings Documentation 2.0 a process-driven approach with a focus on re-use. The customer-driven approach of Documentation 3.0 is a logical next step. But why should we change the way we create documentation? First of all the world is changing and so are our users! Things that seem obvious to one individual, don't make any sense to others. Take for instance this photo (shown to the left). It shows a young model holding a camera. In her perception, you hold a compact camera this way. Truth is that she is holding a 1970's Olympus Pen EE-3, a camera with a viewfinder instead of a LCD scr...

In my article "How knowledge becomes usable" - published in the Winter edition of Communicator - I explain how you can incorporate knowledge-driven design in information products. The Communicator is the quarterly journal of the Institute of Scientific and Technical Communicators (ISTC). The article is a follow-up on my presentation at the ISTC Conference 2007 in Liverpool. If you are a member or a subscriber of Communicator, you automatically receive this issue. Otherwise, if there is something of interest to you, contact the ISTC Office to purchase a copy. The ISTC is the largest UK-based society for professional communicators. If you are a technical communicator and working in the UK - or Europe in general - I can strongly recommend membership of the ISTC. Look for more information on their website: www.istc.org.uk .

I mentioned in my last article of 2007, that as a technical writer you can expect to be asked for several kinds of documentation within your organization. Recently I started to structure the product requirements and product specifications of my customer's products. The intended audience consists of the product manager and product architects on the one hand and the developers on the other hand. The goal of my work is to create a knowledge bank in which the audience can see both the product requirements and the relevant specifications next to each other. At this moment there are two types of documents: A functional requirements document: This is a 27 pages long Word document, including some illustrations. It has a thematical structure. This document is written and edited by two product architects. Component design documents: These are detailed functional and technical descriptions of parts of the product, first written by developers and then edited by two functional designers. The co...

In an earlier post, I compared my work as a technical writer with Island hopping: going from one island to another. The truth is that to perform our job well we need information from different sources within an organization. And on the other hand people from different parts of the organization have a need for our skills when it comes to writing and presenting information. In a way we therefor function as information integrator within the organization: gathering information from different platforms and sources and creating output for different depatments (internal customers) and in different formats. As an example: When I created the documentation for my current customer, I gathered information about the product from different deparments and developed the on-line help. As a result, the Sales department became aware of my presence, noticed the quality of the information and asked me to create the Sales information. Currently I am working on a structure for the product specifications. In ...

In March 2008 my new article "The Flexible Intranet" will be published in Intercom, the monthly magazine of the Society for Technical Communication. In this article I will examine the typical problems found in a corporate intranet site and demonstrate how knowledge-driven design can improve the effectiveness of intranet sites. In the article I use the example of a helpdesk that delivers support for mobile phones. With this example I will demonstrate how an effective intranet site guides the helpdesk employee toward the information and presents the answers to the questions they are confronted with. Saul Carliner, an internationally known expert on technical communication, contributed to this article. Intercom, the magazine of the Society for Technical Communication , is published to provide examples and applications of technical communication that will promote its readers' professional development. Intercom is published for the benefit of STC members, each of whom receives...

You probably recognize this situation: You have to write a manual, product leaflet or text for a website and you need some information about this specific topic. The information about the topic is available within the organization, but you have to gather it from different people from several departments. And they don't like you messing with their content. They want to keep control over it. Sometimes our job as technical writer is like moving from one island to the other, building bridges and demolishing borders. If you - for instance - need to describe a product, you first travel to the island of the product developers to gather the product specifications. Next you can go to the marketing department to get some of their sales statements about the product and you might want to hop to the Service department to get the ins and outs of their servicing approach. Does this sound familiar to you? I have found this situation in all kinds of organizations. In some cases these organizations ...

In the previous entry, I demonstrated three types of knowledge models. These models can help us structure the information we acquire from functional specifications, subject matter experts, the marketing department and - in some cases - our own observations. When combined they offer us different paths to our information. We have looked at: Thematical models Taxonomies / concept models Composition models A fourth model is called the Attribute model . An attribute model shows attributes and values: colors, specific characteristics, etc. An example is shown below: With the attribute model we can describe all possible characteristics of a product range and link them to the actual products. This makes it possible to make an overview of all variations within a productrange. The models can help us choose between products. Example: You call the service desk of the manufacturer of your TFT screen Service desk employee: "Do you know the exact product type?" You: "I am not sure, I c...

Last time, we have discussed what the benefits of knowledge modelling are. Now it is time, to take a first look at knowledge modelling, starting with a simple hierarchical model: As technical writers we are used to work with these kind of content structures, as illustrated above. This is the type of structure we not only use in manuals, but also in most on-line help systems and even websites. In this example we see two levels of information. When we would put this content structure in a graphical model it would look like this: All content elements - we call them 'concepts' in a knowledge model - are related to the next level with a relation of the type 'Subtheme of'. This type of knowledge model is very suitable for navigating and is supported by a large group of documentation, Help and website tools. Another very common knowledge model is the taxonomy. This type of knowledge model shows classes of concepts and their sub-types. All relationships in the model are of the ...

In my article in ISTC's Communicator (Autumn 2007) I explained that developing more effective information products asks for a knowledge-driven approach to communication. This knowledge-driven approach requires first of all that we offer the knowledge needed in a usable and understandable way, in line with the user’s knowledge and level of experience. The second requirement is that we should offer our users the right knowledge - from the enormous amount of available knowledge – at the right time. New semantic technology provides us with the opportunity to support our users in interpreting information within their context. The most important characteristics of these solutions are: non-hierarchical navigation: presents a mind map of the information, with different types of links making it possible to browse quickly through related topics and offering different points of view to different types of users decision trees: help users to make complex decisions by asking them simple question...