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.
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).
> 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.
I added node_modules and OpenCV compiled for Lambda. Should be easy to play around with this code, just download it on Linux. I used Parallels to launch Unbuntu, then I zipped up the source code with apex and uploaded it to AWS Lambda.
Stoplight Scenarios lets you use scenarios to test web APIs, automate processes and tasks, mashup APIs, create demos, trigger lambda functions, and more. If you are familiar with Postman, Paw, Zapier, or IFTTT - Stoplight Scenarios are like a beautiful combination of the best parts of those products. They are free to use, shareable, and flexible enough to cover most use cases.
Check out some pre made examples to learn more about Scenarios and play around with them. If you already have a Stoplight account, you will need to log out.
