I’ve just published a blog post on the Google Geo Developers Blog, about a new design for the Google Maps API tutorials. I’d love some feedback from technical writers. If you have a few minutes, would you head on over there and let us know what you think?
Today I attended the first ever Write the Docs meetup in Brisbane. It’s the third in the super-popular Write the Docs Australia series.
We started by going round the room introducing ourselves and describing the document we’re most proud of. Stories ranged from blogs, books, and job ads, to documents that actually contained the word “blah blah blah” before given tech writer luv.
There were 3 presentations at this bumper session:
- From Hackathon to Help System, by Jared Morgan
- No-contact Customers: Customer proxies and how to use them, by Laura Bailey
- Writing clearly: a super-power for software developers, by Josh Wulf
From Hackathon to Help System
Jared Morgan gave an amusing and information-packed account of how he implemented an open-source help solution for a product that wasn’t originally designed to support embedded help. He talked us through the original idea for an open-source help product, which he worked on with a partner. The system was to be written in AsciiDoc. The plan was to render the help on hover, using asciidoctor.js.
Jared and his partner didn’t get around to implementing that solution, but an opportunity came up to use the idea at Ladbrokes, where Jared currently works. He initiated the project during a hackathon: putting embedded help into an existing system. There were a number of challenges, because the system wasn’t designed with user assistance in mind. For example, there was no easy way to uniquely identify the fields.
Jared introduced us to a new term: DragonForce a solution. The term comes from a heavy metal band that’s enthusiastic but not particularly methodical in approach. The basic idea was to render the help content when the user clicked a help button. They also wanted to use open source technology, and to use single sourcing of the content.
- Asciidoctor for source content
- Middleman as static site builder
- Franklin as static site framework
- GitLab for on premises hosting
Then came the serious task of releasing the product to real customers. Jared told us how the system needed to be refined and go through QA to prepare it for release. And he gave some pointers into things he’d do otherwise on hindsight.
Jared’s take-aways from the project.
- Developers do care about docs.
- DevOps teams to get things done, and are worth getting to know.
- It’s good to get outside your comfort zone, and learn the challenges the developers have.
- You can think outside the box, and not let your department define the scope of your role as tech writer.
No-contact Customers: Customer proxies and how to use them
Laura Bailey talked about no-contact customers – that is, people you can’t get in touch with. Technical writers need to know their audience. But as businesses grow, customers tend to get further away. So what can you do when you have a no- or low-contact audience? Laura talked about how to be your own data scientist.
Examples of people who may be customer proxies are sales staff, consultants, developers, data scientists. On the systems side, there are support requests, comments, forums, site metrics, surveys, and so on. You need to analyse your own organisation to find out which apply. Laura mentioned that you can even search the Internet for complaints and reviews of your product from customers.
Once you have the data, you need to process it to make it useful. Scrub it and structure it. You may need to do this manually, if you’re listening to phone call recordings, for example. Or automate the scrubbing if you can work with log output, for example.
A hint from Laura is to think of the future, when analysing and recording the data. Think about aspects of the data that you may need to use in future, and record the relevant data points now. It’s also worth noting that often you’re working with systems that are designed for teams other than tech writers, such as sales staff. So think carefully about which data points can provide insights into the questions you have.
Scrutinise your data, and bear in mind where it came from. Avoid confirmation bias. Find as many data sources as possible, and try to support your conclusions with data from more than one source.
It’s a lot of work, says Laura. Data and its analysis is one of the biggest problems in the tech industry, and is currently a focus too. So take care to target your workload to the questions you need answered. Use the work to proactively prevent growth of the problems you’ve targeted.
Writing clearly: a super-power for software developers
Josh Wulf gave a rollercoaster talk about his experiences in developing Magikcraft.io, which teaches children to code in Minecraft. My summation: Trillions of GitHub commits, oodles of smart people, crazy love of code.
Josh invited us to observe 10 seconds of silence for all of the unread docs. 🙂 And he played us some Roger Troutman.
Some nuggets from Josh: Sometimes we think that language just describes things, but language actually creates the world. It gives us the ability to observe our own actions. At first you’re unconscious of your actions. But then you write it down, and you can analyse it. Bug reports are a good example. Diagrams do the same thing.
A good way of helping people is to ask them to tell you, and to tell themselves:
- What I did.
- What it did.
That’s often enough to solve the problem.
It’s a wrap
Thanks to Swapnil Ogale and all the Write the Docs attendees for another great meetup!
I’m putting together a presentation about Tech Comm on a Map, the app that shows technical communication events and groups around the world. What would you like to know about the web app and the Android app for Tech Comm on a Map?
It’s a little scary for a tech writer to create and publish an app. Actually, it’s a little scary for anyone. Are you curious about any particular aspects of why I did it, what the results are, or anything else? If I can, I’ll weave the answers into the presentation.
I’ll be speaking about Tech Comm on a Map at STC Summit 2017 in May, and possibly at other events after that. At the moment, I’m writing the presentation based on my early proposal and outline. I’m having fun! But before I get too invested in what I think is fun, I’d love to hear what other people think too.
The theme for STC Summit 2017 is “Gain the Edge to Get Results“.
Here’s the blurb and outline from the proposal I sent to the STC Summit committee.
As an API technical writer, it’s hard to put yourself in the shoes of your readers. They’re application developers. They’d rather read code than prose.
One way of grokking this audience is to develop an app yourself.
This presentation tells the story of a tech writer, a map, and an app. The app is Tech Comm on a Map, an interactive web-based map that shows events of interest to technical communicators. You’ll hear why Sarah decided to create an app and how she went about it. You’ll see some code and understand the nuts and bolts of the app: where the data is stored, how it gets there, how it ends up on a map for everyone to see.
Tech Comm on a Map is an app for technical communicators, and technical communicators contribute to the data. Sarah will describe the process of crowd-sourcing the data and open-sourcing the app: what went well, what went slowly, what’s still going.
Writing an app has helped Sarah understand her audience (software engineers), her subject matter (APIs), and her profession (technical communication). Come and see how.
It’s hard to create an app. It’s even harder to get the app published and make it available to other people. That’s true whether you’re a developer or a technical writer. You need to put yourself on the edge and take the jump. You need courage, strength of conviction, and knowledge. Above all, you need documentation and examples. They give you the edge.
By taking the jump into app development, Sarah has gained first-hand knowledge of what developers go through. She applies this knowledge to the documentation she writes. It’s also a lot of fun!
At this session, you’ll learn the technical details:
- How the app’s data is crowd-sourced.
- What open sourcing your code means, and why you may want to do it.
- The difference between a web-based application and a mobile app, from a developer’s as well as a user’s point of view. Tech Comm on a Map is available as a native Android app as well as a webapp.
- The information sources that Sarah used when developing the app.
You’ll also see how such a project can help develop your soft skills:
- Sarah’s engineering colleagues helped her kick off the development of the app, and made ongoing suggestions for refinement. The resulting interactions increased mutual understanding and respect.
- Fellow technical writers all over the world help compile the data. A project like this is a good way of connecting with your peers.
- Developing an app can help you better understand your subject and your audience of software engineers and other specialists.
- Such a project gives you confidence in your own abilities, even if you’re just skimming the surface of code complexity.
See Tech Comm on a Map in action at https://sarahmaddox.github.io/techcomm-map.
What are you curious about?
Does the above description raise any specific questions in your mind? Is there something you’re very keen to find out? Let me know, and I’ll include it in the presentation if I can.
Yesterday I attended a Write the Docs meetup where Andrew Etter spoke about his recently published book, Modern Technical Writing: An Introduction to Software Documentation.
I haven’t read Andrew’s book yet, so I appreciated this introduction from the author. One thing that strikes me is how interwoven are two aspects of technical writing: firstly, the processes (the way we glean our material and our efficiency and efficacy in writing content); secondly, the tools we use. Every now and then, I’ve heard people say we shouldn’t focus so much on the tools when discussing our profession and how best to perform our role. I’ve thought that too, at times. But it seems to me that these two aspects of our work are becoming more and more interdependent. The tools make a specific way of working possible, and the way we think of our work determines the tools we choose.
From what Andrew said about his book yesterday, the content of the book seems to agree with my above musings. Now, I should go and read that book. 🙂
Modern Technical Writing, the book
Andrew pointed out that you can read his book in about 45 minutes, and that he’s been allotted an hour for this talk! This comment raised a good laugh.
The book is about 11,000 words. Andrew summed it up (with a smile) in about 12 words, which roughly correspond to the highlighted words in the list below:
- Learn – learn your subject matter and get to know your audience.
- Write in lightweight markup – it’s the easiest way to get from a pleasant writing experience to a useful website. Markdown is a good solution, because people want to use it. You’ll therefore have plenty of people willing to contribute to your docs.
- Treat the docs as code – version control and continuous updates. The stability of the docs over time depends on the quality of your updates.
- Create static websites.
The book, Modern Technical Writing, started as a wiki page. Andrew needed information about technical writing to pass on to others. He did a bit of research, to see if anything already existed that he could use. Having found nothing that fit the bill, he decided “I’m the writer”, and wrote it himself.
What makes a book sell?
Andrew spoke amusingly about an FAQ on the Kindle Direct Publishing site: “Why am I not selling? I am a good writer.” The fundamental question is, how do you get people to buy something you’re selling? Andrew said with a smile that he has no idea! He doesn’t do much marketing or promotion via social media. Here’s his recommendation:
If you have something you feel strongly about, something you’ve shown to your friends and got good feedback on, something you think adds value to the world, then put it out there.
The publishing process
Andrew chose Kindle Direct Publishing as the mechanism for publishing and earning royalties. The rules around pricing are really complicated. The magic happens when you upload your book to Amazon, and they transform it to a Kindle book. Amazon is the market leader in online publication, and your book benefits from this.
One drawback is that you cannot test your book before publication. You just upload it, view the highly inaccurate preview, and then publish it.
Andrew showed us a screenshot of his book on Amazon right next to Strunk and White’s Elements of Style. To be near Elements of Style is mind-boggling. But it lasted a very short time. He dispelled any myths that self-publishing is lucrative. He has, however, received very nice messages from people all over the world.
Charging a price for the book
If you give something away for free, there’s the perception that it’s not really valuable. If you give it a price, people are more likely to see it as worth something.
For his book, Andrew thinks that the price of around $4 is in the right range.
What technical writers do
What is the “differentiated value add” of a technical writer? That is, what do we do that no-one else does?
- Consistency – specifically, consistency in tooling. Without tech writers, each engineering team would pick their own tools, which would result in chaos.
- Accountability – someone has to be responsible for creating good documentation. Andrew remarked with a smile that you have to be able to fire someone if the documentation is bad.
- Creation and curation – writers review and take care of others’ content as well as writing it.
- Culture – having good writers around makes everyone else aware of what good writing looks like.
- Good documentation leads to efficiency improvements in many ways. It helps the organisation and customers save time, and time is a precious resource.
Andrew talked a bit about the writing process, project prioritisation, and the team. He joked at the beginning of the presentation that these topics may form part of the second edition of the book, if he ever considers writing one.
The old way versus the new way of producing documentation
Andrew talked about old methodologies and tools versus the new ones, and walked through some code samples. I didn’t make notes of this part of the talk. The details are in Andrew’s book.
Thanks to Andrew Etter for an engaging presentation and congrats on your successful book!
Where do technical writers belong in an organisation? Which team should we be part of? This is an interesting question that many of us are asking. I don’t have an answer. In fact, there are probably as many answers as there are possibilities, because each organisation is different, and so is each technical writing role. But I do have some musings and two presentations to introduce.
Where we end up in the organisation can affect the way other people see us and our contribution to the company. It can affect our own perception of our purpose and goals. It may even affect our ability to do our job, if our position in the company determines the access we have to information, technology, and other resources.
Sometimes, we’re lucky enough to have a say in where we end up. That’s when it becomes really interesting, because the choice may not be easy.
Where do we belong?
Here are some of the possibilities:
- Engineering and product management: Technical writers work closely with the software developers to understand the ins and outs of the product. It’s also very useful if technical writers can give early input into the design of a product, taking advantage of the user-focused nature of a technical writer’s role.
- User experience: Technical writers, UX designers and UX researchers are focused on the needs of the customer. They often work closely together in producing the documentation and other user aids, even if they’re not part of the same team.
- Support: The documentation is an essential resource for the support team. Working as part of support can give technical writers direct access to the requests and problems reported by customers.
- Marketing: The documentation is an important marketing asset, and the level of technical detail in the documentation tends to yield excellent SEO (search engine optimisation). Technical writers and marketers often find themselves writing about the same products and topics, especially at the launch of a new product or feature. Marketing teams have great resources for customer analysis, and a flair for words.
- Developer relations: This is a team of people with various roles, including technical writers, software engineers, developer advocates, marketing leads, and others. The team acts as an interface between the internal teams who’re developing the products, and external developers/customers who’re using the products. The products are developer-focused, including APIs, SDKs, libraries, and so on.
- Change management: See the comments on this post for discussion.
- Any more?
Two takes on working with product teams
Recently I presented a webinar on working with an engineering team, and I attended a talk by Craig Simms on integrating more closely with a product team. It’s interesting to compare these two takes on the topic.
Webinar: Working with an Engineering Team
The ASTC (Australian Society for Technical Communication) and I recently collaborated to host a webinar on working with an engineering team. You can watch the recording below, and on Vimeo. The slides are available on SlideShare.
Click the play button to view the video above.
Talk: Integrating with Software Product Teams
At a recent Write the Docs meeting, Craig Simms presented a talk on how technical writers can integrate more closely with software teams. It’s a zestful account of the journey he and his colleague have taken towards becoming integrated with a product team, and the lessons learned during that journey. The recording is on YouTube, and embedded below.
What do you think?
Where do technical writers fit in, and do you know of any other presentations that talk about integrating with various teams?