5 ms·

Writing Documentation When You Aren't a Technical Writer – Part Two

125 points by pytlesk4 8y ago

chrisweekly 8y ago
Nice set of guidelines. Mostly "common sense" but given how (un)common that can be, this is likely pretty helpful for its intended audience. :)
kaycebasques 8y ago
I write the docs for Chrome DevTools and Lighthouse. In the discussion for part 1 of this series I mentioned that the #1 most critical skill for creating useful docs is to know your audience. combatentropy expanded on the idea [1] to include purpose: > I have been a tech writer, and I would say something similar, that you need to know two things to write well: audience and purpose. The road becomes a lot clearer after that. Rules on writing fill whole books, but most writing would improve tenfold if writers remembered audience and purpose. These articles are fine, they have good tips. But, after 8 years of professional technical writing, I strongly recommend focusing on knowing your audience and their purpose. This is a superskill that you can apply to improve any communication. [1] https://news.ycombinator.com/item?id=17839052 https://news.ycombinator.com/item?id=17839052
- gradys 8y ago
  Any practical advice for doing this better? Or concrete examples of times you have done this in the past?
  - kaycebasques 8y ago
    By “practical advice on this” do you mean how to learn more about your audience and their purpose?
- pytlesk4 8y ago
  100% agree with knowing your audience and purpose. But you are a technical writer, so these tips might be obvious. Audience and Purpose could be Part 3? But for people that don't do technical writing day to day, it can be a little daunting when you are initially tasked with writing some docs. This is usually the case at smaller companies where people have to wear multiple hats.
  - kaycebasques 8y ago
    > But for people that don't do technical writing day to day, it can be a little daunting when you are initially tasked with writing some docs. This is what I'm trying to help with. If you keep the framework of "know your audience" and "know their purpose" in mind, docs will be much less daunting. Who am I writing this for? What do they know beforehand? What is their purpose of reading this doc? Answer those questions, and you won't need to memorize long lists of specific tips. Trying to memorize tips and grammar rules without having an overarching framework of why they improve your communication is what makes writing daunting, IMO.
  - pfranz 8y ago
    I always start with the audience in any writing. I'm often asked, "write documentation for your tool" by technical peers and managers and I always have to push back trying to get more specifics. Am I writing for a non-technical end-user? Am I writing for a technical person troubleshooting the tool (can I assume they know yaml or how to use a Terminal)? Am I writing for someone who may reimplement or heavily modify this tool. Is this intended for reference or to walk someone through the process for the first time? All of those are documentation and technical writing, but vary greatly in what details you include and how you approach it. In my experience, as a tool writer/maintainer I tend to want to document the implementation, but nobody cares about that until you leave your job (by then the documentation may be out of date if you don't maintain it). Most people's highest priority is a troubleshooting guide (which is difficult with a new tool) and a very explicit walkthrough for non-technical people (which is difficult to maintain because dialogs get tweaked and supporting tools can change).
type0 8y ago
> Protip: Avoid accidental racism by using “denylist” and “allowlist,” instead of “blacklist” and “whitelist.” I actually misread it as denyalist, who knows denialism maybe is the right word after-all. Not being from US, I had no idea that these were racist terms: https://en.wikipedia.org/wiki/Blacklisting https://en.wikipedia.org/wiki/Blacklisting https://en.wikipedia.org/wiki/Whitelisting https://en.wikipedia.org/wiki/Whitelisting Maybe we should also stop using: https://en.wikipedia.org/wiki/Red_List_Index https://en.wikipedia.org/wiki/Red_List_Index because the population of native North American ethnicities is on decline and biologists are all racist misogynists claiming that there is such an absurd thing as biological sex //sarcasm is not even enough to describe this lunacy that's eating the world//
- theothermkn 8y ago
  > //sarcasm is not even enough to describe this lunacy that's eating the world// The author’s “accidental racism” phrasing is a little awkward, but the idea is there. The point isn’t that “whitelist” and “blacklist” are “racist terms.” Clearly, they are not. The point is that members of the audience for your documentation, paying members and influencing members, could be harmed by them in certain contexts. We don’t always have control over the context or situation in which the user encounters the documentation. For example, I could say that your response is "hysterical," indicating that I find the notion that this is "eating the world" to be overly emotional and alarmist. If you, or another reader, were female, you might then object that "hysterical" shares its root word with "uterus," and its etymology and current shading indicates "characteristic emotional and mental weakness that stems from having a uterus, i.e., from being or being like a woman." Writing is an exercise of power. It is even more so than verbal speech, in the context of documentation especially, because it provides no forum for the user, your paying user, to clarify and to point out offenses. And take a deep breath, because even if this lunacy eats the entirety of software documentation, the world will be nowhere near consumed. You might even be richer for it, in both senses of the word.
  - type0 8y ago
    Yeah, I agree. I should also add that in order to avoid "accidental communism" we should stop using phrases like "shared resources", after all if you at the first linked wikipedia article you will find why it's relevant. It true that writing is a tricky thing since we can't convey intonation and the use of emojis in docs usually is not somethings that's helping the cause. I don't know how it can be solved but if we'll take the way of the word policing you should be inclusive and surely ban: "shared resources", "killing processes" etc etc - there should be no end to this until we reach Farrenheit 451, how "hystorical" (intenstionally misspelled) this might might seem to you. Cheers
icc97 8y ago
I've been reading a stark comparison recently, ReasonML vs MDN. I realise this is unfair as MDN has had much more resources and time and the ReasonML docs are a straight copy of the OCaml docs, but compare the Reason List.map [0] vs MDN Array.map [1]. Given that the Reason docs are taken from OCaml and modified , I was wondering how well it would work to take the MDN docs and modify the relevant subset for Reason. [0]: https://reasonml.github.io/api/List.html#VALmap https://reasonml.github.io/api/List.html#VALmap [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
C7H8N4O2 8y ago
Does any one else find the site design frustrating? Constant top/bottom bars and a full window height of low-quality content before the article begins.
- hybridtupel 8y ago
  There were some discussions about that here before. One of them is this "Make Medium readable again": https://news.ycombinator.com/item?id=16516126 https://news.ycombinator.com/item?id=16516126 edit: Removed Markdown
- Kagerjay 8y ago
  I always wonder what people are talking about, but I've had this extension for so long that I forgot how bad medium is. "Make medium readable again" https://chrome.google.com/webstore/detail/make-medium-readable-agai/kljjfejkagofbgklifblndjelgabcmig?hl=en https://chrome.google.com/webstore/detail/make-medium-readab...

125 points by pytlesk4 8y ago

Nice set of guidelines. Mostly "common sense" but given how (un)common that can be, this is likely pretty helpful for its intended audience. :)

kaycebasques 8y ago

I write the docs for Chrome DevTools and Lighthouse. In the discussion for part 1 of this series I mentioned that the #1 most critical skill for creating useful docs is to know your audience. combatentropy expanded on the idea [1] to include purpose: > I have been a tech writer, and I would say something similar, that you need to know two things to write well: audience and purpose. The road becomes a lot clearer after that. Rules on writing fill whole books, but most writing would improve tenfold if writers remembered audience and purpose. These articles are fine, they have good tips. But, after 8 years of professional technical writing, I strongly recommend focusing on knowing your audience and their purpose. This is a superskill that you can apply to improve any communication. [1] https://news.ycombinator.com/item?id=17839052 https://news.ycombinator.com/item?id=17839052

gradys 8y ago
Any practical advice for doing this better? Or concrete examples of times you have done this in the past?
- kaycebasques 8y ago
  By “practical advice on this” do you mean how to learn more about your audience and their purpose?
pytlesk4 8y ago
100% agree with knowing your audience and purpose. But you are a technical writer, so these tips might be obvious. Audience and Purpose could be Part 3? But for people that don't do technical writing day to day, it can be a little daunting when you are initially tasked with writing some docs. This is usually the case at smaller companies where people have to wear multiple hats.
- kaycebasques 8y ago
  > But for people that don't do technical writing day to day, it can be a little daunting when you are initially tasked with writing some docs. This is what I'm trying to help with. If you keep the framework of "know your audience" and "know their purpose" in mind, docs will be much less daunting. Who am I writing this for? What do they know beforehand? What is their purpose of reading this doc? Answer those questions, and you won't need to memorize long lists of specific tips. Trying to memorize tips and grammar rules without having an overarching framework of why they improve your communication is what makes writing daunting, IMO.
- pfranz 8y ago
  I always start with the audience in any writing. I'm often asked, "write documentation for your tool" by technical peers and managers and I always have to push back trying to get more specifics. Am I writing for a non-technical end-user? Am I writing for a technical person troubleshooting the tool (can I assume they know yaml or how to use a Terminal)? Am I writing for someone who may reimplement or heavily modify this tool. Is this intended for reference or to walk someone through the process for the first time? All of those are documentation and technical writing, but vary greatly in what details you include and how you approach it. In my experience, as a tool writer/maintainer I tend to want to document the implementation, but nobody cares about that until you leave your job (by then the documentation may be out of date if you don't maintain it). Most people's highest priority is a troubleshooting guide (which is difficult with a new tool) and a very explicit walkthrough for non-technical people (which is difficult to maintain because dialogs get tweaked and supporting tools can change).

type0 8y ago

> Protip: Avoid accidental racism by using “denylist” and “allowlist,” instead of “blacklist” and “whitelist.” I actually misread it as denyalist, who knows denialism maybe is the right word after-all. Not being from US, I had no idea that these were racist terms: https://en.wikipedia.org/wiki/Blacklisting https://en.wikipedia.org/wiki/Blacklisting https://en.wikipedia.org/wiki/Whitelisting https://en.wikipedia.org/wiki/Whitelisting Maybe we should also stop using: https://en.wikipedia.org/wiki/Red_List_Index https://en.wikipedia.org/wiki/Red_List_Index because the population of native North American ethnicities is on decline and biologists are all racist misogynists claiming that there is such an absurd thing as biological sex //sarcasm is not even enough to describe this lunacy that's eating the world//

theothermkn 8y ago
> //sarcasm is not even enough to describe this lunacy that's eating the world// The author’s “accidental racism” phrasing is a little awkward, but the idea is there. The point isn’t that “whitelist” and “blacklist” are “racist terms.” Clearly, they are not. The point is that members of the audience for your documentation, paying members and influencing members, could be harmed by them in certain contexts. We don’t always have control over the context or situation in which the user encounters the documentation. For example, I could say that your response is "hysterical," indicating that I find the notion that this is "eating the world" to be overly emotional and alarmist. If you, or another reader, were female, you might then object that "hysterical" shares its root word with "uterus," and its etymology and current shading indicates "characteristic emotional and mental weakness that stems from having a uterus, i.e., from being or being like a woman." Writing is an exercise of power. It is even more so than verbal speech, in the context of documentation especially, because it provides no forum for the user, your paying user, to clarify and to point out offenses. And take a deep breath, because even if this lunacy eats the entirety of software documentation, the world will be nowhere near consumed. You might even be richer for it, in both senses of the word.
- type0 8y ago
  Yeah, I agree. I should also add that in order to avoid "accidental communism" we should stop using phrases like "shared resources", after all if you at the first linked wikipedia article you will find why it's relevant. It true that writing is a tricky thing since we can't convey intonation and the use of emojis in docs usually is not somethings that's helping the cause. I don't know how it can be solved but if we'll take the way of the word policing you should be inclusive and surely ban: "shared resources", "killing processes" etc etc - there should be no end to this until we reach Farrenheit 451, how "hystorical" (intenstionally misspelled) this might might seem to you. Cheers

icc97 8y ago

I've been reading a stark comparison recently, ReasonML vs MDN. I realise this is unfair as MDN has had much more resources and time and the ReasonML docs are a straight copy of the OCaml docs, but compare the Reason List.map [0] vs MDN Array.map [1]. Given that the Reason docs are taken from OCaml and modified , I was wondering how well it would work to take the MDN docs and modify the relevant subset for Reason. [0]: https://reasonml.github.io/api/List.html#VALmap https://reasonml.github.io/api/List.html#VALmap [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

C7H8N4O2 8y ago

Does any one else find the site design frustrating? Constant top/bottom bars and a full window height of low-quality content before the article begins.

hybridtupel 8y ago
There were some discussions about that here before. One of them is this "Make Medium readable again": https://news.ycombinator.com/item?id=16516126 https://news.ycombinator.com/item?id=16516126 edit: Removed Markdown
Kagerjay 8y ago
I always wonder what people are talking about, but I've had this extension for so long that I forgot how bad medium is. "Make medium readable again" https://chrome.google.com/webstore/detail/make-medium-readable-agai/kljjfejkagofbgklifblndjelgabcmig?hl=en https://chrome.google.com/webstore/detail/make-medium-readab...