2015-01-05-my-real-top-10-technical-writing-trend-predictions-for-2015.html

---
layout: post
title: My *real* top 10 technical writing trend predictions for 2015
date: 2015-01-05 08:00:35.000000000 -08:00
categories:
- api-doc
- technical-writing
tags: []
status: publish
published: true
---

{% include toc.html %}

<p>On New Years day I posted a <a href="https://idratherbewriting.com/2015/01/01/top-10-technical-writing-predictions-for-2015/">spoof of trends</a> because I think trends posts get to be a bit ridiculous. During this time it's like the Mardi-Gras of free and wild speculations.</p>
<p>However, I did receive some great comments on the post. One of my favorites was <a href="https://idratherbewriting.com/2015/01/01/top-10-technical-writing-predictions-for-2015/#comment-143902">this one</a>:</p>
<blockquote><p>Wow and Wow. At age 76, as a recently minted Journalism major, with a minor in geomorphology, and  with a $103,786 education debt, (no matter mostly from gambling) your obviously well researched and analyzed predictions have left me with no choice but to commit Harry Carey. Despite the well known fact that you are a "Thought Leader" in this archaic industry, followed by "millions" at last count, I will leave a notarized statement for my estate Executor not to sue your ass for wrongful death. You are cc:
</p></blockquote>
<p>While I had fun writing the trends spoof, I can't help but follow it up with an actually serious prediction about technical writing trends. I'll try to add some reasoning for the trends as much as possible, but I admit that these trends are, like many other posts, speculations from my own experience and perspective, without any real research to back them up. (Welcome to the blogosphere!)</p>
<h2>1. More authoring tools and CMSs accept Markdown.</h2>
<p>In 2015 more authoring tools and content management systems will parse and process Markdown as a commonly accepted format. Markdown excels particularly for developer doc in part because developers like working in text formats. Rich text editors (even in WordPress) mangle code samples, but not text formats like Markdown. Markdown allows you to keep your code samples intact while also providing easily readable text. Developers create the tools we use, and I think more developer solutions (like <a href="https://pages.github.com/">Github Pages</a>) will cater to Markdown.</p>
<p>Note that while I do think Markdown will continue to be popular, I don't think the many static and flat file CMS platforms (Ghost, Jekyll, Docpad, Kirby, Pico, etc.) will oust WordPress, Drupal, and other database-driven solutions. See this post for details: <a href="https://www.ostraining.com/blog/general/2014-static-websites/">2014 Will Not Be the Year of Flat File Websites</a>.</p>
<p>Will Markdown catch fire within the tech comm community? Probably not. Here's the problem with Markdown. As soon as you start authoring something with real complexity, such as a list with tables, bullets, code samples, links, and more, the once-simple Markdown starts to get just as complex as XML markup. Technical writers swim in more robust content, so I doubt they'd ever swap a robust publishing solution for a simple Markdown syntax. Still, more and more online tools will accept and parse Markdown simply because it's the syntax preferred by the tool builders.</p>
<p>When a lightweight, static file CMS comes along that handles re-use, attribute filtering, and parses Markdown, I'll totally jump on board.</p>
<h2>2. Increased focus on API documentation among technical writers.</h2>
<p>We've seen incredible interest in API documentation in the field of tech comm during 2014. The fact that any <a href="https://idratherbewriting.com/2014/01/01/upcoming-api-workshop-in-san-jose-on-feb-8-2014/">API workshops we've done</a> in Silicon Valley have sold out is one indicator. (There are 100+ people on the wait list for <a href="https://idratherbewriting.com/2014/11/28/upcoming-api-workshop-with-sarah-maddox/">Sarah Maddox's workshop</a>.) I've also been contacted by numerous chapters asking me to <a href="https://idratherbewriting.com/presentations/">present on API documentation</a>, and the STC Summit will have a full day dedicated to API doc sessions. Remember that 2014 also had a full <a href="https://idratherbewriting.com/2014/09/10/stc-intercom-issue-entirely-dedicated-to-api-documentation/">Intercom issue dedicated to API documentation</a>.</p>
{% include ads.html %}
<p><a href="https://idratherbewriting.com/category/api-documentation/">API documentation</a> is a hot topic now, and it will get even hotter in 2015. The <a href="http://programmableweb.com">programmableweb.com</a> directory lists 12,000+ open web APIs, and the number is only growing. Tech writers recognize that they can play a key documentation role in the API market. Especially amid a declining demand for GUI-only documentation (as user interfaces get more friendly and intuitive), technical writers will move in the direction where there is high demand and high salaries. Although API doc is painfully technical, it is also a rewarding and highly sought-after skill.</p>
<h2>3. More demand for specialized skillsets and specialized domain expertise.</h2>
<p>This comes as no surprise, but I think the demand for specialized skillsets and domain expertise will only increase as technology becomes more diverse/fragmented/specialized. Employers will want candidates who not only know a specific language and tool, but who may already be familiar with their existing API!</p>
<p>I think the time when you could say "Well I don't know X but I know Y and therefore I can learn X" (whether referring to tools or programming languages or domains) is not going to cut it. To thrive, you might consider specializing in a particular domain.</p>
<p>This brings up the question of breadth versus depth. Is it better to be a specialist or generalist? I'd say the former may give you more of an advantage if there are a sufficient number of jobs in the area. Still, this is a question I wrestle with, and I'm not totally sure on this one.</p>
<h2>4. Confluence becomes the default internal architecture in software departments.</h2>
<p>I think Atlassian Confluence will grow in popularity as a platform for internal information sharing and collaboration among IT groups. As much as I <a href="https://idratherbewriting.com/2014/09/24/two-major-confluence-problems-poor-content-re-use-and-no-wiki-markup/">dislike Confluence for its poor re-use capabilities and lack of wiki syntax</a>, it does a great job at enabling engineers to author and collaborate. The popularity of Confluence will put added strain on tech writers who will be expected to integrate their docs for review on Confluence prior to publishing them out.</p>
<p>Especially as information becomes more specialized, the need for more collaboration will increase, and writing platforms that create silos between authors and contributors will create a divide between IT groups and technical writers.</p>
<h2>5. XSL:FO dies out in favor of CSS when creating PDFs with DITA</h2>
<p>If you need to publish a PDF from DITA, the traditional method has been to use XSL:FO. This cumbersome and complicated language will die out when oXygenXML formally integrates support for <a href="http://www.princexml.com/">Prince XML</a> into their editor. Right now there is some integration but <a href="http://www.oxygenxml.com/forum/topic10901.html">it's buggy</a>.</p>
<p>Prince XML allows you to customize the look and feel of the PDF output using CSS. This is better than XSL:FO not only because CSS is easier and many of us are familiar with it, but because you can use the same styles that you're probably already using in your webhelp output. In other words, you can literally single source your CSS styles.</p>
<h2>6. Higher design expectations for help outputs.</h2>
<p>In 2015, people will have higher expectations for documentation's look and feel to match the modern web (see my <a href="https://idratherbewriting.com/2014/10/16/api-doc-presentation-slides-and-recording/">slides from my SF STC chapter</a> for examples of sexy doc sites). People are growing accustomed to what websites look like, and how information is presented online.</p>
<p>Given that you can stand up a good-looking website with a free or inexpensive WordPress theme in half an hour, customers will expect documentation to have a similar standard when it comes to the web. This means antiquated tripane help outputs based on frames and other 1990-looking "designs" will be met with suspicion before customers even start reading the content.</p>
<p>Similarly, people will simply expect sites to render well on whatever device they're using -- responsive site designs won't be anything special.</p>

<h2>7. New cloud authoring tools will replace old HATs and editors.</h2>
<p>I've seen quite a few cloud-based authoring solutions appear in the past few years, and I expect 2015 will continue the trend. Although offline editors are fast and powerful, they belong to a model that is dying out. <a href="http://easydita.com/">easyDITA</a>, <a href="https://readme.com/">ReadMe.com</a>, <a href="https://readthedocs.com/">ReadtheDocs.com</a>, <a href="http://www.corilla.co/">Corilla.co</a>, <a href="http://www.paligo.se/">Paligo</a>, <a rel="nofollow" href="https://clickhelp.co/">ClickHelp</a>, <a href="https://cloud.author-it.com">Authorit Cloud</a>, <a href="https://www.atlassian.com/software/confluence/pricing">Confluence Cloud</a>, and more are just a few of the cloud-based solutions that are emerging.</p>
<h2>8. Increased tool diversity among tech comm.</h2>
<p>I bet that in 2015 you will walk into a tech writing meet-up of some kind, and of the 15 people there, every one will be using a different tool or authoring process. The days when there was an industry standard for tech comm authoring tools is over. This <a href="https://idratherbewriting.com/2014/08/07/benefits-tool-diversity-part-ii/">tool diversity</a> fits into the growing diversity of tools on the web and allows people to use the right technology for their situation. Even among DITA users, the editors and publishing platforms will all be different.</p>
<h2>9. Doc portals that combine documentation with knowledge bases will become popular.</h2>
<p>Most documentation solutions are siloed from help center knowledge bases, but I think this division will fade away, especially with the emergence of more cloud-based authoring solutions. Doc portals that allow users to search documentation, knowledge base articles, and other content in a neatly organized way will become increasingly popular.</p>
<p>A good doc portal provides helpful navigation to documentation for various product sets, and helps users search within each space or browse by facet. The doc portal may be the killer feature that drives technical writers to abandon their offline authoring tools and use an online solution. Right now most doc portals are custom built, but I bet we'll start seeing more out-of-the-box doc portal solutions appear in the cloud.</p>
<h2>10. More sexy doc sites that help sell the product spring up.</h2>
<p>I'm not sure how I manage to end up in jobs where my help is restricted from general access on the web, but it seems that 90% of all tech comm projects I've worked on have been behind a firewall. However, I think (and hope) that companies will begin to relax their policies about firewalling documentation and instead start to use doc sites as a means of selling their products.</p>
<p>As <a href="https://idratherbewriting.com/2014/12/17/getting-a-job-in-api-documentation-podcast-with-andrew-davis/">Andrew Davis noted in a recent podcast about API documentation</a>, good documentation helps sell the product, especially for startups. Interactive, sharp looking doc sites that sizzle with good design, visuals, video tutorials, well-organized reference material, etc, will be leveraged as an asset to sell the product. This will cause technical writers to think about SEO practices for their help content, which will influence doc platforms, style guides, and analysis.</p>
<p>This trend toward building doc sites that help sell the product fits in with the mergence of technical communication and content marketing that we hear so much from Scott Abel.</p>
<h2>Non-trends</h2>
<p>A few things I didn't mention include the following: a continued (or even increased) demand in PDF, more frenzy over supporting the proliferation of devices, the buzz of "content strategy", more flexible telecommuting policies, and non-collaborative solutions like DITA.</p>
<p>Once again, I just want to reiterate that my predictions here are based on my own perspective. I haven't conducted research or surveys to come to these conclusions. While I know that many predictions turn out to be wrong, I hope at least a few of them are on target. What do you think? What trends will we see with tech comm in 2015?</p>