I’m coming to the conclusion that there are specific types of content that suit a DITA environment, and that the converse is also true: DITA is not the best solution for every content type. (DITA is the Darwin Information Typing Architecture, an XML architecture for designing, writing, managing, and publishing information.)
“Well, duh,” you may say. :) I’ve never worked in a DITA environment, but I’ve attended two indepth training courses and a number of case studies that walked through successful DITA implementations. The most recent was at the ASTC (NSW) conference last week, where Gareth Oakes presented a case study of an automotive content management system that he designed and implemented in collaboration with Repco. The content is stored and managed in DITA format, and published on a website. (See my report on the session: Repco and DITA.) This was a convincing case study of a situation where DITA has succeeded very well.
In my analysis, the DITA implementations that work well are those where the content consists of a large number of topics, and where those topics have an identical structure. It’s almost as if you’re building a database of content. Good examples are catalogues of automotive spare parts, machine repair instructions, safety procedures, aircraft manufacturing manuals, and so on.
Apart from volume and support for a standard layout, this type of content has other requirements that DITA can satisfy well, including the ability to automatically build a variety of manuals by combining the topics into different configurations (via DITA maps) and multi-channel publishing.
On the other hand, some content doesn’t benefit much from such a highly structured storage format. Potentially, the overhead of a DITA environment is overkill and the costs may outweigh the benefits. If we have contributors to the docs who are not tech writers or developers, asking them to learn DITA or specific source control and editor rules can be a deterrent.
Dare I say it: Much of the documentation we write in the software industry falls into the latter category. Our topics tend to be lengthy, less uniform in structure, and more discursive than, say, an auto parts manual. API reference docs are an exception, but they’re auto-generated from software code anyway. We also don’t usually need to recombine the topics into different output configurations, such as different models of a car.
What do you think? Please contradict me. :) Do you have examples that gainsay or support the above conclusions? I’d love to see some examples of well-structured and well-presented documentation produced from DITA source.
This week an analytics ninja showed me how to use Google Analytics to track the values entered into a text field. It comes down to sending a dummy page name to Google Analytics, containing the value entered into the field. Google Analytics faithfully records a “page view” for that value, which you can then see in the analytics reports in the same way that you can see any other page view. Magic.
For example, let’s say you have a search box on a documentation page, allowing readers to search a subset of the documentation. It would be nice to track the most popular search terms entered into that field, as an indication of what most readers are interested in. If people are searching for something that is already documented, you might consider restructuring the documentation to give more prominence to that topic. And how about the terms that people enter into the search box without finding a match? The unmatched terms might indicate a gap in the documentation, or even give a clue to functionality that would be a popular addition to the product itself.
It turns out that you can track input values via Google Analytics. The trick is to make a special call to Google Analytics, triggered when the input field loses focus (
<input onblur="ga('send', 'pageview', 'my-page-name?myParam=' + this.value);" />
ga call sends a customised page view to Google Analytics, passing a made-up page name that you can track separately from the page on which the input field occurs. The made-up page name is a concatenation of a string (
'my-page-name?myParam=') plus the value typed into the input field (
my-page-name can contain any value you like. It’s handy to use the title of the page on which the input box occurs, because then you can see all the page views in the same area of Google Analytics.
Similarly, the part that contains the input text can have any structure you like. For example, if the page is called “Overview” and the input field is a search box, the Google Analytics call could look like this:
<input onblur="ga('send', 'pageview', 'overview?searchText=' + this.value);" />
This blog post assumes you have already set up Google Analytics for your site. See the Google Analytics setup guide. The Google Analytics documentation on page tracking describes the syntax of the above “ga” call, part of “analytics.js”.
Yesterday I was privileged and delighted to speak at a meeting of the STC Silicon Valley Chapter in Santa Clara. Thanks so much to Tom Johnson and David Hovey for organising the meeting, and thank you too to all the attendees. It was a lovely experience, with a warm, enthusiastic and inspiring audience. This post includes some links for people who’d like to continue playing with the APIs we saw last night and delving deeper into the world of API documentation.
The presentation is on SlideShare: API Technical Writing: What, Why and How. (Note that last night’s presentation didn’t include slide 51.) The slides include a number of links to further information.
The presentation is a technical writer’s introduction to APIs (Application Programming Interfaces) and to the world of API documentation. I hope it’s useful to writers who’ve had very little exposure to APIs, as well as to those who’ve played with APIs a bit and want to learn about the life of an API technical writer.
Here’s a summary of the presentation:
- Introduction to the role of API technical writer.
- Overview of the types of developer products we may be asked to document, including APIs (application programming interfaces), SDKs (software development kits), and other developer frameworks.
- What an API is and who uses them.
- A day in the life of an API technical writer—what we do, in detail.
- Examples of good and popular API documentation.
- The components of API documentation.
- Useful tools.
- How to become an API tech writer—tips on getting started.
Demo of the Flickr API
During the session, I did a live demo of the Flickr API. If you’d like to play with this API yourself, take a look at the Flickr Developer Guide (and later the Flickr API reference documentation). You’ll need a Flickr API key, which is quick and easy to get. Slide 23 in my presentation shows the URL for a simple request to the Flickr API.
There are more links to follow in the presentation itself: API Technical Writing: What, Why and How. I hope you enjoy playing with some APIs and learning about the life of an API technical writer!
Hallo fellow techcomm folks! Do you have a hobby?
Mine is fairly pedestrian. I like to go walking in the bush. It blows away the cobwebs. Well, actually, I often have to blow away the cobwebs myself. They festoon the pathways in the early morning. It’s best to keep your mouth closed when strolling in the Australian bush, or you’ll find yourself spitting spiders.
Sometimes a bird pops out and does something interesting, and I blog about it.
Of a dark winter’s eve I can perchance be found tickling the ivories. Perhaps significantly, other members of the household are usually to be found in the furthest corners of the house.
So fess up
What do you get up to when the pleasures of the pen pall? (Aside from avoiding sentences like that.)
For years I had a Calvin and Hobbes cartoon pasted above my desk. It showed Calvin’s father with a mangled bicycle, obviously the result of a bad stack. The caption read: “The secret to enjoying your job is to have a hobby that’s even worse.”
A fellow technical writer asked me this week about the documentation that developers need to do their jobs. He was thinking not of the guides people need when they want to integrate their systems with another organisation’s systems, but rather the internal guides developers may write for themselves about their projects and tools.
That’s a very good question. I’ve thought about it over the last couple of days, and pulled together a list of the types of developer-focused documentation I’ve come across. If you have any to add, please do!
The list is confined to documents relating to the role of software engineer/developer. It doesn’t include more general information that all employees need, such as human resources and facilities.
Information about the project and system they’re working on
- Who the people are: engineering team members, product managers, technical writers, stakeholders.
- Customers: Who they are and what they do, or would like to do, with the system or application that the team is developing.
- Goals: Mission, vision, goals for the upcoming month/quarter/year.
- Product requirements document for the system, application, or major feature that they’re working on.
- Design documents.
- Architectural overview, preferably in the form of a diagram.
- Comments in the code, written by their fellow developers.
Help with their development environment
- How to set up the development environment for the application/system that the team is developing.
- Guides to specific tools, whether built in-house or third party, including the IDE of choice, build tool, source repository.
- A pointer to the issue tracker used by the team.
- Guide to the team’s code review tool and procedures.
- Best practices for writing automated tests, and information about existing code coverage.
- Links to the team’s online chat room, useful email groups, and other communication tools used by the team.
- Where to go with technical and tooling problems.
- Coding style guides for each programming language in use.
- Guidelines for in-code comments: style; where to put them; how long they should be; the difference between simple comments and those that are intended for automated doc generation such as Javadoc; and encouragement that comments in the code are a Good Thing.
- Best practices for code readability.
Sundry useful guides
- Communication guidelines, if the developer’s role will involve significant liaison with third-party developers, customers, or important stakeholders.
- A map to the nearest coffee machine, preferably reinforced by a path of glowing floor lights.
Too much information can be a bad thing. :) I spotted this sign on a recent trip to Arizona: