We seem to agonize endlessly over how long content should be. Metrics are regularly proposed for the perfect length of a blog post or content marketing piece, and the move towards topic-based writing has tech writers worrying about similar issues. Keeping content short is certainly good policy. No one wants to read more than they have to to accomplish a given goal. So it makes sense to use content length as a metric for content quality, right? Not so much. Short is a great policy, but a lousy metric. Here’s why:
There is a fallacy that seems to have worked its way into the shared psyche, a belief that the next generation (whichever one that might be) will not read text at all but will demand video for everything. This seems to have produced a kind of fatalism in some tech writers, a belief that video will conquer all despite its obvious unsuitability for many technical communication tasks.
Here is one expression of this, from a recent discussion on LinkedIn:
I agree that videos can be frustrating, particularly when you know most of the information and you only need help on a small area of a product. But customers like them and the upcoming generation will require them.
The purpose of technical communication is not to translate complex information into simple terms, but to enable the reader to act correctly.
Tom Johnson has a great blog post laying out An argument for complexity rather than simplicity in technical communication. Many products, Tom argues, are complex, and to pretend otherwise is to do the reader a disservice. I have great sympathy with this argument, complaining, as I often do, about documentation that explains everything you could figure out for yourself, but nothing else.
Tom begins by quoting the revised STC mission statement, which defines technical communication as “the discipline of transforming complex information into usable content for products, processes, and services” Tom praises the STC for choosing to use the word usable rather than the word simple.
The best job I ever had spanned the full spectrum of technical communication.
In a response to a comment in a discussion related to my post Content Engineering is not Technical Writing, Scott Abel said:
Who cares what tech writers do. There’s no future (read: great paying careers) in documenting things. That ship sailed a long time ago. Now, companies pay top dollar for someone with a hybrid set of skills.
I’m not sure if I would go that far. I know lots of tech writers who still make a good living. And frankly, for anyone who wants to make a career as a writer, technical writing is a godsend, since there are few other writing jobs that provide middle class incomes.
Don’t just try to fit into development’s agile process. Create your own lean content development process.
Technical writers are increasingly finding themselves involved in the agile process of the development organization. The most common way this happens is that a writer gets assigned to the team for a sprint and is expected to produce documentation in the same sprint as the developers produce the feature.
This has one huge plus for writers: development cannot declare the sprint complete until the documentation is done. This means that it is in the interest of every developer to help ensure that the tech writer has what they need to get their work done. Given that getting information when needed is a major issue for many tech writers, this can be a very big win.
Everyone in the content industry seems to be trying to define their roles these days. There are a number of new roles and titles being described, and everyone wants to know where to draw the boundaries around them.
Commenting on my recent post on Content Engineering, Jonatan Lundin asked, “So is an information architect a sort of content engineer?” On LinkedIn, Bob Newman protests “I am the Technical Writer – NOT the SME!”. And in the first meeting of the nascent Content Strategy Collective, defining content strategy and content strategy roles was the first thing proposed as a goal for the group.
In the closing keynote of the 2013 LavaCon conference, Ann Rockley talked about the rising importance of content engineering in content strategy. A content engineer, Ann explained, is someone with one foot in the technology world and one foot in the content world. Last year I wrote a pair of posts on my hesitation about taking on the label of content strategist (Am I a Content Strategist?, I Am a Content Strategist). I have no such hesitation about the label of content engineer. I am a content engineer, and I have been one for many years.
Content jobs are never strictly defined because they are the mortar that holds the bricks of the enterprise together.
I’m attending LavaCon, and here, as everywhere, content people are debating the definition of their roles, the names of those roles, the boundaries and intersects between them, and the responsibilities and qualifications pertinent to them.
Newer fields such as content strategy and information architecture are newer to these debates, but they have been a staple of conversation between technical writers (or is it technical communicators, documentation professionals, or customer information specialists?) for decades.
We worry a lot about Search Engine Optimization (SEO). I suspect we don’t worry enough about Social Curation Optimization (hereby dubbed SCO). Social curation plays a large role in how people find content on the Web. Google’s Eric Schmidt was recently quoted as saying:
Social networking sites like Facebook and Twitter also allow users to leverage their social networks to find answers to their questions. Google is therefore competing with all methods available to access information on the Internet, not just other general search engines.
One of the samples of an EPPO topic that I included in my book was a topic from the WordPress Codex on the subject of Using Themes. One of the key properties of an EPPO topic is that it serves a specific and limited purpose. I identified the purpose of this topic as enabling the reader to use themes on their WordPress site.
One of the reviewers objected that the user’s real purpose was not to use themes, but to style their site. I can understand where the criticism comes from. Those of us who favor task orientation in technical communications are quite sensitive to anything that smells of its opposite: feature orientation. We don’t want people to be writing topics on the File Menu, for instance. We want them to focus on things that the reader is trying to do.