I recently came across an interesting article by Jason Calicanis called Microsoft is interesting again -- very. It talks about why Microsoft has lost out on the last 5 major technical innovations, and how they are poised to make a comeback. Calicanis writes:
Microsoft has been largely dead to Silicon Valley because for the past decade they struggled in -- or completely missed -- the last five major technology movements. Those five movements, and who they lost to are:
- 1/open source (to Linux, MySQL, etc.)
- 2/search (to Google)
- 3/mobile (to Apple)
- 4/social (to Facebook)
- 5/cloud (to Amazon)
The basic premise is that Microsoft failed to compete because they returned dividends to shareholders rather than investing the money into long-term innovation. Calicanis argues that Microsoft should not only invest more money in long-term innovation, they should also buy startups and other innovative technology (such as Twitter) in order to compete with the other big tech companies.
What can we learn from Microsoft's failure to innovate? How can we apply it to tech comm?
I think Microsof provides a great example of the innovator's dilemma. The company on top must continually invest in developing the next innovation in order to stay on top. But spending money on research and developing innovation diverts resources from their current business edge.
Do any of these technological innovations (open source, search, mobile, social, cloud) apply to tech comm?
First, I think that the tech comm field hasn't really harnessed any of these five major technological innovations in significant ways, which is somewhat sad and puzzling at the same time. If we want to stay relevant to consumers, don't we need to be more savvy and up-to-date with search, social, mobile, open source, and cloud technologies?
Let's look at each of these major technology innovations and ask how the tech comm industry might leverage the innovations and why.
The DITA Open Toolkit is probably the technology that has made the most strides with open source in the tech comm world. The DITA OT processes the DITA standard, which is set by the OASIS committee. Different tech comm writers and vendors integrate the DITA OT into their help systems to process DITA. It is cool to see a lot of different platforms leverage DITA-structured content in different ways.
That said, the DITA OT's webhelp output isn't really usable. Oxygen and XMetaL's webhelp plugins (paid plugins) are much better, and other vendors also have solid web platforms. But in this DITA vendor-land, few are open-sourcing their webhelp plugins and platforms.
Jorsek LLC, makers of easyDITA, recently created a project called Better Webhelp, which is an open-source webhelp plugin for DITA. I'm kind of surprised I haven't heard more about it (maybe it's still being developed?). There might be other open source webhelp plugins besides Better Webhelp, but not too many.
As for other help authoring tools, pretty much every vendor keeps them under lock and key. From what I've heard, there's not much money to be made in developing software for technical writers -- the audience is too small. Maybe the audience of tech comm writers isn't large enough to drive an open source movement.
Search should be a no-brainer, but many technical writers are trapped by corporate policies to keep all documentation behind a firewall. This means many technical writers essentially miss out on Google's search capabilities and findability on the web.
But even when doc is the web, it's often not on platforms that are optimized for SEO. Additionally, many tech writers do not write with SEO in mind (especially if it's not even on the web).
Some years ago, I used to have a Joomla site where I published release notes, and a Flare webhelp where I published documentation. The Joomla site continually surfaced on the first page of the search results, while Flare's output was buried several pages down. So I think at least with some HATs, the whole architecture (with iframes and such) isn't optimal for SEO.
People carry smartphones everywhere, and they regularly search for information on them. Tech docs should have a strong responsive design to display well on mobile. Many tech comm leaders advocate that help should adapt to the device, and I've seen many presentations at tech comm conferences focusing on adaptive and responsive design.
Still, I think many help sites don't really address the mobile scenario. In part, many of the HTML outputs from HATs have poor responsive design. Even if you can override the stylesheet, simply adding media queries to a help authoring tool's output won't create the responsiveness you need. The TOCs are usually too elaborate and clunky to work well on a mobile device -- they're optimized for desktop display.
Additionally, although I continually hear how mobile is becoming the default way that people access the Internet, even analytics on my blog indicate that mobile traffic accounts for less than 5% of the visits. So yeah, I'm on my phone a lot, but not really surfing doc sites.
Although Facebook is listed in the Microsoft article as an example of social, I think a better example of social is user-generated content, including wikis. Tech comm has gone through the wiki phase, certainly. And I think the verdict is that wikis aren't really that great for external tech docs. Even so, Confluence is incredibly popular in IT shops as an internal collaboration platform.
As far as social networks, though, most tech docs don't leverage user input this way. Rating systems and comments on pages can be helpful, but most of this input is better funneled through support channels.
Some support groups try to respond to user frustrations expressed on Twitter and Facebook, and that's a great strategy for listening to users. But unless tech writers play support roles, or unless tech writers are plugged into these channels as a way to gather user perspectives, the social venue is largely untraveled.
How many tech authoring solutions are cloud-based? There are a number of vendor solutions, I think, that enable teams to collaborate online. For example, easyDITA is a great cloud-based authoring platform.
A few help authoring tools, such as Help IQ, Doczone, and others have cloud solutions as well. And Github's free online repositories enable a lot of teams to interact and share code (which can include text file formats such as DITA).
Still, few tools and teams are entirely cloud based.
I've kind of been drawing a blank with these 5 technological innovations. Part of me feels like help systems should be open source, powered by Google search, responsive, user-input-enabled, and cloud-based. And the Jekyll solution I'm working on fits all of these categories to some degree or another. However, perhaps these categories are too broad to foster more detailed discussion.
What do you think? How does the tech comm industry leverage these 5 major technological innovations? Are they irrelevant? Are we leveraging them as much as we can or should?
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here.