Ugur Akinci

The following is an interview with Ugur Akinci, a technical writer for Honeywell Corporation. Ugur asked me these same questions for an interview on this site. After answering them, I was curious about how he would answer the same questions, so I asked Ugur to respond to the questions for my site as well.

(1)   How long you’ve been a technical communicator? Where do you work right now? How would you characterize a typical day at work?

I’ve been a technical communicator for over 13 years, lucky enough to be working for Fortune 100 hi-tech corporations. Currently I work for Honeywell Access Control Systems.

A typical day would mostly consist of writing user, installation, and configuration manuals and drawing illustrations that go with such manuals. Communicating with my colleagues, managers, and SMEs through email, phone and in person and participating in meetings, teleconferences and webinars are also a part of my typical day in office.

(2)   How did you become a technical communicator? Did you start out as one or did you switch to it from something else? What was the reason?

I was originally trained as a sociologist but things happened and I never worked in academia.

I started out my career in the late ‘80s as a Desk Top Publishing expert of sorts. When the first Apple Macintosh came out I’ve spent all my savings to buy a Mac SE and a dot-matrix printer and started to design and produce magazines, brochures, flyers, whatnot. I enjoyed that very much. That led to my still continuing interest in page layout and graphic design. In the ‘90s I found myself writing more and designing less, and eventually I became a full-time copy writer.

Between 1994-1998, I worked as a journalist in Washington D.C. for a daily paper, covering the U.S. State Department and the U.S. Congress. Very exciting and busy four years those were but at the end I was forced to look for something else because journalism was not paying much. So like quite a few other tech writers that I know of, I’ve made the switch from journalism to tech writing in 1998 and never looked back since then.

(3)   What is the single most important change that you see in the technical communication sector since you first became a technical communicator?

Emergence of structured authoring and single-sourcing;  the relentless push to automate and standardize the document production process while dropping the unit costs. I think in the future technical writing will be a lot less about writing and a lot more about coding, mapping, and transcribing.

Also, I think the role of technical illustration will steadily grow in this age of multinational products and services catering to a multicultural customer base, all speaking different languages. Words are not universal but images are. Writers who can also draw have a clear job-market advantage for that reason.

(4)   In your judgment, what is the best and worst thing about working as a technical writer? 

For me the most satisfying aspect of technical writing is the way it forces me to make sense out of chaos and bring order to not-so-orderly processes. That workflow forces me to face my own deficiencies and motivates me to understand my thought process better while trying to describe the object of the same thought process.

As a secondary note I can also say that this is the best-paying writing job I ever had. If you love writing but you’d like to take care of your family as well, then by all means you should think about becoming a technical writer. I tried journalism, poetry, copy writing, screenplay writing, political commentary, and freelance article writing – but nothing comes close in terms of the material security that technical writing provides.

The worst about technical writing is that it’s by definition not an emotionally expressive genre. It’s not creative in the sense a screenplay or a poem is creative. It’s not designed to move others emotionally but to direct, instruct, and train others. I’m the son of a singer and a painter and was raised at a home full of music and art. I still have a deep interest in artistic expression of all kinds. Thus from time to time I balance the scales by taking a break from technical writing and doing something else, like watching a movie or writing a poem.

(5)   What’s your advice for those who are just starting out their careers as technical writers today?

Try to bring to the job as many side skills as you can. Don’t go into the battle with a single handgun on your hip.

For example, if you like to draw and paint, that’s great since technical writers who can also draw illustrations will be in great demand in the future. For employers it’s a clear two-for-one deal.

Same goes for programming and all kinds of engineering skills. If you have a knack for network administration, so much the better since most of the systems that I’ve documented required a good understanding of the way client-server systems are networked together.

If you know HTML, Javascript, PHP, SQL, or a traditional programming language like C++ or Java, those are all the kinds of skills that will propel you to the head of the queue in your job search. Don’t let such skills become dormant thinking they have “nothing to do with writing”. On the contrary — in technical communication those are all big plusses.

Lastly, you should seriously consider specializing in structured authoring in general and DITA as a specific single-sourcing platform. In the future I believe such “technical writers” (I wouldn’t even know if it’d be appropriate to call them “writers” any more) will become highly-paid corporate “content design” consultants and form a new niche of documentation experts. If you’re just starting out your technical writing career you might as well start specializing in that direction.

(6)   What’s your views on globalization, out-sourcing, and the way it affects technical writers in the USA and abroad?

Globalization and out-sourcing are the result of two relentless forces in capitalism: (1) The imperative to minimize production costs; and closely linked to this: (2)  The imperative to replace labor-intensive methods of production with their capital-intensive counterparts.

Out-sourcing won’t go away. If anything, the trend will become even more pervasive. Whenever India (for example) reaches a wage-level approaching that of the West, other labor-markets will appear overnight and the job-migration will continue unabated. Don’t be surprised if one day India starts to lose documentation and call-service jobs to Mongolia, for example.

This forces the technical writers in the traditional tech-comm countries like the US, UK, and Europe to diversify their skills, on the one hand, and move up to more capital-intensive niches like structured authoring, on the other. Both moves will maximize the competitive advantage of a traditional technical writer. But those writers who continue to insist on “just writing” good-old user manuals will lose their jobs very quickly to outsourcing.

(7)  What is your greatest passion with respect to technical communication?

After all is said and done, I think my greatest passion is learning new things, sharing what I know with others, and teaching technical communication skills to others. I really enjoy that learning-teaching dialectics.

So I guess it’s not a coincidence that I do have a technical communication blog catering to all levels of communicators (http://www.technicalcommunicationcenter.com/) as well as two online technical writing courses (http://www.technicalcommunicationcenter.com/online-courses/). In 2012 I’m intending to add at least two more courses to that list.

I think education and training are very important not only for our profession specifically, but for our survival on this planet as well in this age of increasing population and threatened scarce resources. From politics to daily life to documentation, I forgot the number of times when I witnessed precious potential going to waste for lack of education. The quality of our future depends on the quality of education we provide for our children and youth. That’s why as long as I live I know I’ll try to play my humble part in that learning and teaching process.

Dr. Ugur Akinci is a Senior Technical Writer working for Honeywell corporation. He has ranked 31st  in MindTouch’s list of “400 Most Influential Technical Communicators”. He is the owner of Technical Communication Center, a blog dedicated to technical writing tips, tutorials, and trends.

Blog Sponsors

• Help Generator help authoring software
• Clarify
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Scriptorium
• Adobe Technical Communication Suite 3
• Webworks ePublisher
• Congree

I’m not a wiki fan myself — I’m a structured text guy bred in the bone — but I am fascinated by the trend, and by the variety reactions to it.

Wikis started more as a cultural statement than a technology. They were a tool for the democratization of content, the intent being to eliminate the distinction between reader and writer. In the wiki philosophy, every reader was also a writer, there was no ownership of content, and not notion of a final, finished, of blessed editions of content. The wiki was always open, always evolving, and blessed only by the consensus of the community. Today, it would style itself “occupy content”.

What wikis have become, largely, is an unstructured CMS with only one face. A traditional CMS has two faces: one toward the author, and one toward the reader. A wiki has only one: the same face toward reader and writer, with every page having an edit button on it. Except that today the edit button is locked or hidden from most users. The distinction between reader and writer has been reintroduced and enforced. The original wiki philosophy has been rejected.

Still, the stated motive of most people who adopt wikis for technical communication is to allow more collaboration and to open up authoring to a wider community. So some shadow of the wiki philosophy is still at work. That being the case, I think there are a couple of things that people need to understand about the wiki philosophy and its consequences.

The first is, if you want to crowdsource effectively, you need to be open. People need gratification. If the content they contribute disappears into a black hole of moderation and curation, they don’t get the immediate gratification of seeing their work published, and gratification delayed is gratification denied. You won’t get a lot of content from the crowd unless you let the crowd publish.

The second is a consequence of the first. The implication of the idea that there is no distinction between reader and writer is that the reader has to take more responsibility for what they read. The old contract between the writer and reader of technical content, that the published content had been vetted and could be relied upon uncritically, cannot be sustained in a crowd-sourced world. The reader of a wiki, like the reader of any Internet content, has to assume some responsibility for vetting the content they receive.

By and large, readers do understand this. It is the responsibility they accept every time they type something in a Google search box. The simple fact of the matter is that readers prefer unblessed content that addresses their task and is available now over blessed content that does not cover their task or will not be available until next year. Timeliness and coverage trump all other considerations most (thought definitely not all) of the time.

The question for tech writers is, is there a place in your hearts, and in your company’s relationship with its customers, for unblessed content that enhances coverage and timeliness?

I like Mark’s comment for several reasons. He brings up several key points with wikis:

• “[Wikis] eliminate the distinction between reader and writer.”
• “Readers prefer unblessed content that addresses their task and is available now over blessed content that does not cover their task or will not be available until next year.”
• “People need gratification. If the content they contribute disappears into a black hole of moderation and curation, they don’t get the immediate gratification of seeing their work published.”
• “The old contract between the writer and reader of technical content, that the published content had been vetted and could be relied upon uncritically, cannot be sustained in a crowd-sourced world.”

When we talk about wikis, it’s important to see them as more than just another authoring platform. As a reader, knowing that I can change the text alters my sense of the text. It is no longer the absolute word on the matter. I can be a part of the conversation; I can change the message. It is my content as much as another’s.

And making those changes immediately, seeing it published instantly, is gratifying. It’s empowering, almost to the level that the printing press changed the distribution of knowledge. Wikis take it to another level, allowing every reader to also be a publisher. Tapping into the knowledge that every reader has, inviting the reader to share that knowledge, and trusting the reader that he or she will shape the content responsibly, isn’t just a shift to another tool. It’s an entirely different way of thinking and interacting. It’s the 21st century interactive read/write web model. It’s a model that acknowledges that the sponsoring organization doesn’t have all the knowledge, but that individuals located in disparate regions also have important contributions to make — and that they should share those contributions. Wikis democratize the knowledge landscape, allowing everyone to speak without pre-filtering editorial control.

This is why, like Mark, I am also fascinated by wikis. In an organization like mine that is traditionally top-down, with careful filters on outgoing messages, a wiki is a complete anomaly. And yet, it is also not an anomaly. Latter-day saints have a history of volunteering, of consecrating their efforts for the community. In the nineteenth century, members would contribute their time, talents, and own funds to build temples (which took years), or to work in fields. In this sense, a wiki is a perfect fit. It is a knowledge project rather than a physical structure project.

Mark also brought up the fact that he is a “structured text guy bred in the bone.” I was talking with Scott Abel last week, and as Scott was explaining something about structured authoring, I brought up this question: Don’t you see wikis and social media as going in the opposite direction of structured authoring?

I know we need to put our content into structured forms so that it can be leveraged into other channels we need to publish to (ePub, mobile, web, print, and more). But it’s impractical to ask people in the community — who are not technical writers and who do not have your same toolset and knowledge — to write in structured formats. Taking contributions from the masses requires you to simplify your authoring model. You end up with an either/or choice. Either you can go the structured authoring route, or you can go the social collaboration route.

In response, Scott mentioned a point similar to what Mark says about content management systems. The only thing that really separates a wiki from a content management system is that the content management system hides the Edit button from the user. If I were to give you login information for my WordPress blog, for example, you would see an Edit link below the post title. You could log in and make changes to what I’m typing right now. With one flip of the switch, I could simply convert this WordPress content management system into a wiki-like platform, breaking down the division between reader and writer, and accomplishing the same end. Right?

What’s more, if the content management system stores content in XML, or relies on some other structured authoring interface for writing content (you can export from WordPress to DITA, for example), it would solve the problem that I describe above about the divergence of structured authoring and social media. Right?

Sort of. I would like to see more content management systems move in this direction. I’m not that familiar with all the various content management systems out there and the number of wiki-like interfaces they potentially offer. In my experience, many times the content management system is behind a firewall or has other security restrictions. Many content management systems may not provide the inviting simplicity that traditional wikis offer. And licensing is also another issue. As a result, more often than not, users cannot simply click an Edit link and start updating content.  However, I think that it’s only a matter of time before this becomes more normal.

What do you think? Do you agree with Mark’s observations about wikis? Are socially collaborative tools and structured authoring going in different directions?

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

In researching this, I stumbled across a goldmine of an article on the History of DITA. The article (mostly by Bob Doyle) traces the evolution of structured authoring from its earliest attempts in the 1960s through the present day. The history seems to encapsulate all the major innovations of technical communication, culminating in the formulation of DITA.

According to this history, DITA can be traced from the following previous approaches and philosophies: Quick Reader Comprehension (QRC), Sequential Thematic Organization of Publications (STOP), Information Mapping, Minimalism, SGML, Docbook, and other innovations.

Tracing this evolution is fascinating. I’ve tried to read through some of the sources mentioned inasmuch as I could find them online. I’ll try to retell the history with my own commentary along the way. At the end, I’ll explain my own method for help authoring.

Quick Reader Comprehension (1961)

Around 1961, T.J. Matthews, an editor/publisher at the West Coast Navy Laboratory, developed a Quick Reader Comprehension method (QRC) for reports to increase reader comprehension while also making authoring more efficient. To increase the comprehension, he invented a format in which he labeled each section with the main idea on the left, while writing the details are on the right, as shown in the image below.

Signposts in the marginalia facilitate scanning and accommodate both novice and advanced users because all users need "the gist."

Matthews explains the philosophy behind this format:

The recipients of an R&D report often differ widely in their subject matter knowledge, use for the material, time for study, and desire for study. They do, however, all have one thing in common. They all need to grasp the main points of the presentation (3-4). … the headings and marginalia that the scanner sees do serve as signposts that direct him to complete text descriptions. This provides a sort of random access effect. The report holder has an intelligent basis for deciding whether to study or skip any part of the material. (Quick Reader Comprehension, p.5)

In other words, the marginalia serve the more advanced user who only wants to quickly scan the material. The novice user who needs more detail can easily dive into more depth by reading the text on the right. Matthews’ technique tries to solve the problem of delivering the right amount of information to the audience given the variety of user needs and backgrounds.

Matthews also places a heavy emphasis on illustrations. Illustrations can serve the same purpose as the marginalia, allowing the reader to quickly scan through the document, reading the illustration captions and looking at the visualization of the information to grasp the whole of it. This is actually how most people read National Geographic magazine.

Matthews argues that “literary” (or text-heavy) approaches to technical writing often result from students graduating from English departments, where there is a constant focus on texts rather than graphic design. Matthews’ monograph itself is illustrated with graphs and other visuals to depict his ideas. He notes that students who want to enter technical writing need a solid background in graphic design, because “Art and science are not two things; they are two sides of the same thing” (Thomas Huxley in Quick Reader Comprehension, p.12).

To decrease the authoring time, Matthews creates a modular authoring process in which each section is a standalone topic that can be prepared and finished independently. This allows the authors to work on any part of the document at one time rather than proceeding sequentially through the material. Matthews explains:

“…each section or subsection is confined to discussion of a single topic. There is no cross-referencing. This permits the sectional topics to be prepared at any appropriate time and in no particular order. They are done piecemeal. This approach has several advantages over more usual methods. First, outlining is greatly simplified and relegated to one of the last, rather than one of the first tasks in reporting. Second, if the units are prepared during the course of the technical work, then large blocks of material are ready for use as soon as the problem has been completed. It is only necessary to arrange these blocks in logical sequence and write transitional sentences or paragraphs. Third, the reader benefits because the author is obliged to stick solidly to one subject at a time.” (Quick Reader Comprehension, p.6)

In other words, Matthews is moving toward a modular writing process in which you have a series of independent, self-contained modules rather than one long text. This speeds up authoring time and also increases reader comprehension because each section will have a stronger focus. This facilitates the reader who skips certain sections of a document and reads only specific areas.

STOP Storyboarding (1965)

The next major development comes from a publications department at Hughes-Fullerton Aircrafts. Walter Starkley explains that “the notion was to construct the proposal entirely of two-page modules, with text and any associated visual facing each other” (STOP, p.42). In other words, Starkley’s STOP method is probably the first quick reference guide.

The following image shows the STOP format.

The STOP method has a graphic on the right and text on the left. Content cannot exceed these two facing pages, and you must always have a graphic, even if you're only visually depicting your argument.

Starkley says some writers objected, noting that some topics called for more elaboration beyond two pages, and other topics don’t have visual potential for the required graphic. To address this, Starkley says research shows most writers switch topics after about 500 words anyway (the length of text allowed on one STOP page). For the graphic, they allowed the graphic to visually depict the argument or ideas instead of showing some object.

Because you had to write for a specific structure, the STOP method is one of the first instances of structured writing. The content could not be longer than two pages. The left facing page had to contain explanatory text, while the right facing page always showed a graphic. This consistent structure no doubt led to a predictable pattern for readers to follow.

The writers pinned these guides up on the wall for readers to look at. Because each two page module was self contained, “the reader [was] confronted with a self-contained and easily assimilated theme wherever he may open the document” (STOP, p.47). Again, this self-containment of topics is another instance of modular writing.

Notice the STOP method’s emphasis on illustrations combined with text. This emphasis on illustrations will be mostly forgotten by the time DITA develops.

Information Mapping

Robert Horn builds on some of the previous concepts of labeling and modular writing, but he also introduces something new: information types. Horn identifies seven major information types:

Blocks in the domain of relatively stable subject matter can be sorted into seven basic classifications, which we call ‘information types.’ The seven information types are:

• Procedure
• Process
• Concept
• Structure
• Classification
• Principle
• Fact

(Structured Writing as a Paradigm)

Horn then analyzes the optimal structures for each information type and develops an approach for each type. Horn also introduces the idea of “information blocks,” which are similar to paragraphs but more tightly focused on a single idea, and usually about 7 sentences (no more than 9, to fit with Miller’s Law of 7 plus or minus 2). These information blocks chunk the information into reusable components for “precision modularity.”

The following is an example of a document structured with Information Mapping.

Information mapping classifies information into seven main types and then recommends an optimal structure for each type. In Information Mapping, information blocks are used instead of paragraphs. These blocks are short, contain no topic sentences, are labeled, and are modular.

Information Mapping is still a practiced method for authoring, and there’s even an Information Mapping conference in Texas this week. However, reading about Information Mapping is somewhat difficult because Horn has trademarked the technique and restricted access to the material. However, you can see a before-and-after demo here.

Minimalism

The next major development is a concept called minimalism, introduced by John Carroll in his book The Nurnberg Funnell. The basic ideas is that learning takes place through action and exploration, not through reading manuals. The more information you can remove from a manual, the quicker you can get users into the application, exploring and learning for themselves.

Carroll has four main principles in his minimalism approach:

• Choose an action-oriented approach.
• Anchor the tool in the task domain.
• Support error recognition and recovery.
• Support reading to do, study and locate.

(See Application of Theory: Minimalism and User Centered Design, by Mary Lou Mazzara.)

In other words, minimalism isn’t just about reducing word count because people are busy and don’t like to read. Minimalism is grounded in learning theory: users learn by doing, not by reading. Get the user acting in the application. Focus your topics on real tasks the user wants to do. When the user makes errors in the application, provide ways to guide and correct the user.

It seems at this point that graphics and illustrations are no longer emphasized, because the application itself is the visual illustration.

In Managing Your Documentation Projects, JoAnn Hackos relates a story that illustrates how too much information can “get in the way of learning”:

In one case study, a publications group decided as part of a paper reduction goal to reduce the size of their hardware installation manuals from over 100 pages of text and illustrations to approximately 20 pages. They eliminated redundancy and cut unnecessary information in the process, but they never consulted the users. All the decisions to eliminate information and redesign the installation books were made by the technical writers and the developers.

The users, 98 percent of whom were trained company techniques, were asked to review the content of the new, shorter manuals for accuracy. They carefully corrected errors in the existing text. Finally, they inquired why anyone in their group needed 20 pages of text to install the hardware. Once they were asked, the technicians explained that all they needed was a picture of the board to verify that they had the right piece of hardware. (103-104).

In other words, by becoming familiar with user’s needs, we can often reduce the information in our manuals significantly, not just from 100 pages to 20, but down to 1 or 2 pages.

DITA

In the interest of time, I’ll skip past SGML, Docbook and go right to the more well-known cousin/successor: DITA, or Darwin Information Typing Architecture. DITA builds on some of the developments of these previous structured authoring approaches. For example, DITA emphasizes modularity of topics, with the idea that each topic is a discrete, self-contained unit that the user can read without requiring a larger context.

DITA also identifies structures for different types of information, but rather than identifying seven types, it simplifies it to three: concept, task, and reference. Each topic can be one of these three information types. The topics are then assembled through maps that can contain any number of topics.

DITA is also heavily minimalistic. The task types, for example, require a structure that limits content to just one short paragraph after the title, and also eliminates stem sentences that introduce the procedure sequences. So far, not much new.

Where DITA is different is in the emphasis on content re-use and the separation of content from format. Why the emphasis on content re-use? In DITA 101, Ann Rockley explains:

One of the largest impacts of technology on information development is the addition of so many new formats for delivering information. No one just delivers a user guide (book) any more. There is an increasing need for information to be delivered in multiple formats. (DITA 101, 114)

In other words, content re-use is important today because we have more deliverables to produce. This is particularly true due to the Internet, which introduce a need for web help, and with mobile devices, which require a mobile format.

Another strength of DITA is that its structure enforces consistency, so for every task type, readers will become accustomed to the same format. This structure is enforced through the XML architecture of DITA, which requires certain tags in certain orders. More consistency leads to greater usability in the document.

Most importantly, DITA allows you to re-use or single source topics into different deliverables. For example, you can create a guide focused on a specific role, or for a specific scenario; you can compile a lengthy guide or a short guide. Because you can select and compile topics at will, you can create a variety of deliverables that better address a specific user level, context, and need. Ann Rockley notes that this selection allows you to get the right information to the right user at the right time (DITA 101).

DITA's chief strength is that it allows you to re-use content easily. You can create myriad guides with different selections and combinations of topics. This allows you to address a wider variety of users, roles, scenarios, and other contexts. You can get the right information to the user at the right time.

(Image from Reuse strategies and the mechanisms that support them, ditaxml.org)

Because content is separate from format, DITA requires a rendering component to transform the XML (your tagged content) into an output. This is part of the beauty of XML — you don’t hard-bake the format into the content. You can apply a completely different style to the content without actually changing the content. However, customizing the stylesheets requires XSLT programming knowledge, so this also potentially a drawback of DITA.

Beyond DITA

DITA is an impressive format, so one might ask, what could possibly come next? Is DITA the most cutting edge approach to documentation, the culmination of years of refinement and adjustment?

Noticeably absent in DITA’s functionality is a collaborative, wiki-like component for working with non-writers, such as stakeholders, project leads, and end-users. However, Don Day, chair of the OASIS DITA Technical Committee, is working on a project that will combine DITA with wiki-like functionality so that DITA can be used as a collaborative tool for a wider audience.

Other developers are working on exporting DITA to a wiki format, and then back again (round-tripping). Lombardi software has developed a method for the export of DITA to Confluence wiki. This looks promising if you use Confluence.

Only Half the Problem

I like the idea of DITA. It should be the back-end technology behind nearly every documentation tool. It clearly has the potential to make authoring processes more efficient. However, DITA only solves half of the problem. Remember back in 1961 when T.J. Matthews tried to solve the problems he was facing with his QRC method? Matthews starts his essay by complaining how the scientist today entering the space era “faces insuperable problems in attempting to keep himself informed on what he needs to know.”

He then asserts:

The Quick Reader Comprehension (QRC) method of R&D reporting promises to make both writing and reading more productive. It is potentially capable of saving at least half the manhours that scientists and engineers spend in manuscript preparation, and of increasing greatly the amount of information that can be obtained in a given amount of reading time. (Quick Reader Comprehension, p.3)

It's equally important to increase user understanding as it is to improve authoring efficiency.

Matthews’ attempt is not just to create a more efficient authoring process, but to improve the users’ learning, their rate of information absorption and comprehension. DITA just provides more of the same content in different combinations — topics in long guides, short guides, role-based guides, scenario-based guides, online help, mobile help, and other forms. The ability to pull together topics in the selections you want is critical and a huge step forward, but remember it’s still the same topic content. And of course that’s the idea of DITA — same content, but wrapped in different packaging.

However, as a total help solution, we have to keep in mind the other half of the problem: helping the user understand the massive amount of information we’re giving them. DITA should be a component within a larger learning strategy, not the solution for learning. Users who look at DITA as the magic button for perfect user assistance are missing a key point. DITA does not significantly enhance learning in itself — it’s just an authoring efficiency.

Multimodal Learning

The innovation in technical communication today needs to focus more on innovation in learning techniques, not just efficiencies in authoring. As we know, users interact with help material in a variety of contexts. Sometimes they read to learn, other times they read to do. Some users are novices who can barely double-click a mouse; others can understand the code running behind the application. Some users are voracious scanners who turn page after page looking for information; others are visual learners who need to see in order to understand. Others need someone to explain tasks to them in person; others prefer interface tips and notes and they explore on their own.

No help material will provide a one-size fits all solution. Rather than simply regenerating the same topics in different outputs, what users need for learning is a multimodal help experience. Just as conferences that offer nothing but lecture after lecture bore their attendees, help material must also provide content in different modes. Not just help in different formats, but different modes entirely. These different modes will not only suit different users but will also reinforce learning with different senses.

The four categories of multimodal learning that help content might address are as follows:

Video (screencasts). Probably the single greatest tool for learning a software application is to see how to do it. Our minds are visually mapped. When we watch how something is done, we understand. No amount of descriptive text and screenshots can really communicate all the a user takes in by watching a two minute video. Lynda.com, a video tutorial site for hundreds of software products, is the probably most popular example of technical communication on the web.

Illustrations (quick reference guides). A user looks at an overview of the system to gather a holistic idea of how it works. A two-page quick reference guide (QRG) with an illustration fills this need. You can’t just extract this content from a topic in your online help, because the content is integrated into the illustration, which may only be a screenshot with callouts on it, but ideally it’s more conceptual. In my experience, the content has to be revised for the illustration. To make an analogy, a quick reference guide is to a reference manual as a poem is to a novel. It’s not just the same content — it’s compressed, it’s an overview. It captures the whole in a visual way rather than explaining the parts.

Text (wiki or online help). The user who wants to read the details, or who needs a quick answer to a “how-do-I” question, can consult the written material to find the answer. A wiki is often the best solution here in collaborative environments, because it takes advantage of collective intelligence. But an online repository of any help content also works as long as it’s searchable. DITA can provide a good format for this content.

Action (practice and exercises). As John Carroll rightly pointed out in minimalism, you only truly learn something when you act, when you do. Users need practice problems and exercises and if possible, a test system, where they can experiment and explore the ideas and techniques they are learning about. These invitations to act can be added as “suggested homework” at the end of videos or put into a training workbook.

There are other modes for learning, of course. For example, teaching. When you teach a subject, you learn it better than anyone else. But how do you incorporate this learning mode except in a classroom setting? Perhaps if your online help is a wiki, you can give every user his or her own space where he or she can make notes on key tasks. Or encourage forum participation to teach others. But since there isn’t a practical application, I omitted it from my big four above.

The acronym for these four main modes of learning is VITA. In Latin, this means life, which is appropriate for the balance of the approach.

VITA is an acronym for video, illustration, text, and action. These four modes of learning provide the right balance to optimize user understanding.

These four modes aren’t just the same content pushed out into other formats. They are modes of learning. Some might criticize my approach to say that it falls under training or instructional design more than technical communication, but these lines have always been blurry. Our purpose as technical communicators is not merely to communicate information, but to help users understand the information and to become power users of the application or system we’re educating them about.

DITA could be used in this multimodal learning solution. DITA might be a wonderful tool for pushing topics out as screencast scripts and training material, but in my experience, the same topic doesn’t work without significant alteration. Single sourcing breaks down when you switch modes in drastic ways — going from text to illustration, or from written to spoken communication.

For me, it’s less important to try re-using content as it is to create content in new modes. And that’s the key deception of DITA. DITA would have you believe that you can single source your way into every possible deliverable. In reality, you’re just making potatoes in a few different ways (scalloped, mashed, boiled). You’re still giving the user potatoes. VITA is a multimodal approach, giving the user a full array of nutrition options, so to speak. It educates and informs by touching almost every sensory input.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Sarah defines authoring as “a publishing workflow that lets you define and automatically enforce consistent organization of information.” Typical structured authoring models include DITA, DocBook, S1000D, ATA, and SPL. Flare, Robohelp, wikis, and other help authoring tools and platforms that do not enforce a structure aren’t typically considered structured authoring.

If you’ve been following my blog for a while, you may remember my brief interview with Sarah from the 2009 STC Summit.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

In this podcast, I talk with Anne Gentle about her forthcoming book, Conversation and Community: The Social Web for Documentation. Anne explains how we’ve transitioned from the Age of Information to the Age of Interaction, using social web tools to find the information we need. She builds on her experiences with One Laptop per Child, Book Sprints, and her experiences as a corporate blogger for BMC software. In her book, she talks about the future of documentation, the writer’s role, community and documentation, commenting and connecting with users, structured authoring with wikis, and more. The book will be published by mid-summer 2009. Keep updated about the release of Ann’s book by following her blog, JustWriteClick.com.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

In this podcast, Sarah O’Keefe of Scriptorium Publishing explains the results of their recent survey about the state of structured authoring in technical communication. In the survey, they found that 84% of respondents are either thinking of moving to structured authoring, are in the process of moving to structured authoring, have already adopted structured authoring, or are undecided. Only 16% of respondents said they were not moving to structured authoring. She also discusses other survey results, such as the adoption of DITA and mistakes people make in moving to structured authoring.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

In this podcast, I talk with Ricardo Amigo, a translator and podcaster in Mexico City and Costa Rica, about the field of technical writing. This podcast is more of a reverse interview. Instead of me asking the questions, Ricardo interviews me. The general topic is the field of technical writing, including all of the following:

• My path into technical writing
• Structured authoring
• XML and DITA
• Information architecture
• Usability — for documentation and software interfaces
• Publication formats for help material
• Breaking into technical writing
• Tools for help authoring
• The growth of technical writing
• Creativity and technical writing
• A typical day as a technical writer
• Translation techniques and tools
• Simplified technical English

Ricardo’s company is called Amigo Audio, and they principally do translation. For example, if you need your manual or software interface translated, Amigo Audio can help. You can contact Ricardo Amigo at sinpapel@yahoo.com. Additionally, you can read more about their translation services at Amigo Audio.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Ann Rockley

A few years ago, I wanted to better understand content management, so I picked up Managing Enterprise Content, by Ann Rockley, and read it through. It opened my eyes to a lot of new concepts.

Ann is one of our field’s leading experts in content management. She’s now expanding in to something she calls “intelligent content.”

Intelligent content is a concept that builds on other concepts you may already be familiar with. I think we’re going to hear a lot more about intelligent content. In fact, she and Scott Abel are preparing an entire conference exploring intelligent content. I caught up with Ann over email and asked her to expand on the concept. Below is our interview.

What is intelligent content?

We define it this way: Intelligent content is structurally rich and semantically aware, and is therefore automatically discoverable, reusable, reconfigurable, and adaptable.

Let me explain more what that means.

Structurally rich

“Structurally rich” means the content is structured content, and more importantly it is semantically structured content. For example, we can look at the structure and know what type of content it contains (steps contain chronological action-oriented information). DITA-based content is an example of structurally rich content, as is DocBook, XBRL, and RSS, though the content could have a custom structure as well).

If we have a structure in our content, we can manipulate it. For example, we can automatically determine how to publish it to multiple channels (print, web, help, mobile), or we can filter out some content (e.g., tables may not work as well in the mobile environment).

Also, if it is structurally rich we can perform searches and narrow our search to the particular type of information we are interested in (e.g., look for all occurrences of the word metadata in conceptual information).

Semantically aware

The word semantic refers to “meaning.” Semantically aware content is content that has been tagged with metadata to identify the kind of content within it. For example, you might tag your content with industry, role or audience, and product. If the content is tagged with semantic metadata, it is possible to automatically build customized information sets based on audience or industry, for example.

As more organizations start to create personalized content (content which is dynamically assembled upon user request that specifically matches a users need or user profile), this type of metadata becomes extremely important.

In addition, as content is pushed to wikis, integrated through “mashups” or “pipes,” it becomes even more important to ensure our content is semantically tagged. Without semantic metadata, it’s difficult to automatically, let alone manually, find the content we need.

Discoverable

If the content has semantic tags and is structurally rich, it’s a whole lot easier to find exactly what we are looking for.

Reusable

Reusability refers to content we frequently use. If content is structured for reuse, and I know what type of content it is, I can either easily retrieve it for manual reuse or automatically retrieve it for systematic reuse (automatic reuse).

Reconfigurable

Knowing the structure of the content, we can output it to multiple channels, reconfiguring it to best meet the needs of the channel, or we can automatically mix and match content to provide us with the information the customers needs. We can even transform content (reconfigure it) from one structure to another, but only if we know what the structure is in the first place.

Adaptable

We frequently create our content for a particular need or audience, but content can be adapted (used in a different way), often without our knowledge, to meet a new need.

Is “intelligent content” a new term for our industry? If so, who coined it?

As far as technical communication goes, “intelligent content” is a new term. In some ways, it’s a new term in the broader content industry as well.

I coined the term, just like I did for much of the terminology used today for reuse because there wasn’t a term to describe something that existed, or there were too many terms, and talking about something or trying to explain something was difficult.

Technical communicators are very focused on producing high quality content that meets the customers’ needs, often in a very short period time and often with tools that won’t stretch to meet their needs. Many have begun to move to DITA and some are adopting content management, but when you have the conversation with management about why they should move to DITA and adopt content management, it is very difficult to get across the concepts and the return on investment. DITA is a standard, content management is a tool, but how does it help the organization to do what they need to do better?

I’ve heard some managers respond to a well-presented business case with, “So, why should I care, how does this really help us?” Let’s turn it around, let’s talk about the goal and what it gives the organization and the customer. Intelligent content allows us to do the following:

• Automatically publish to multiple channels because the content is structured. Content structure can be recognized and automatically transformed to any format we like. This is not possible with traditional content.
• Customize our content for customers because we can identify what content is appropriate for what customer.
• Reduce the costs of translation because content is modular and designed for reuse, etc.

Why is it intelligent? Because it is structured, etc.

How do we support intelligent content? With DITA, component content management, etc.

Now let’s take the concept of Intelligent Content outside of Technical Communication. There are huge amounts of information in organizations being provided on websites. For a long time, metadata has been the way that most companies optimized content for retrieval, but now XML is beginning to make inroads into broader organizational content, and that brings all the benefits I’ve already discussed.

If you try and talk about XML, though, you’ll lose most managers because it is perceived as being too technical. However, you can turn it around and say we can create intelligent content that enables us to:

• More easily find it
• Deliver it
• Customize it
• Personalize it
• Automatically deliver it to multiple channels
• Simultaneously release content in multiple languages

And

• Reduce costs
• Speed up delivery time
• Optimize resources
• Do more with the same resources
• Increase customer satisfaction

We’re creating intelligent content that can be automatically discoverable, reusable, reconfigurable, and adaptable, etc. — we’re not just creating XML-based content.

What’s the role of the content creator in creating intelligent content?

The role of the content creator is crucial in intelligent content. It is not enough to just put our content in topics and push it out, although that’s a good start. We need to think about all the ways in which we can make our content adaptable. This means doing content analysis, customer needs analysis, and identifying an appropriate information architecture that sits above our content. Content creators are getting a good handle on DITA and structure, but very few use or understand metadata.

What kind of tools do you need to create intelligent content?

We can use the existing DITA tool sets and Component Content Management systems, but if we are interested in helping the organization beyond Tech Pubs, we should consider using XML content servers, and dynamic delivery engines.

What skills are needed for a writer to create smart content?

I’m always looking at where writers are today and where they can go to increase their skills and marketability, so this list reflects a growth curve. To start, writers should look at DITA, but in looking to the future they should gain an understanding of the following:

• Content modeling
• Metadata
• Reuse strategies
• Multichannel delivery strategies
• Mashups, pipes
• XPath and XQuery (not necessarily so they can code these, but so they know what they can do and specify requirements for them)
• Structuring content for marketing campaigns (the intricacies of campaigns are incredible and they are completely dependent upon intelligent content)

What organizations are employing tactics to make content intelligent?

We are seeing the beginnings of intelligent content with organizations that have moved to DITA, but organizations that are global or that have a broad product lines are really developing intelligent content. They are tagging content for region, product, audience, and more as well as automatically producing content that meets the needs of their customers. We have one client that creates 500 different pieces of content to reflect different products from the same content source, all automatically and all based on metadata tagging and DITA!

Next we are seeing intelligent content in organizations where their product is content (e.g., newspapers, magazines, publishers).

We are also seeing intelligent content in pharma, medical devices, intelligence, and financial industry organizations.

Ann Rockley is part of The Rockley Group, a content management company focused on intelligent content.

For more information about Ann Rockley, see The Rockley Group. You can also follow The Rockley blog.