Technical Communicators (aka Instruction Whisperers) are haunted by a great deal of creepy/funny stories. Let us share some ghostly nightmares of our own.
Be our guest and treat yourself to:
By Orysia Gaba
Jeez, what keeps you awake at night?
When writing documentation, target audience is one of the first things on mind of an information developer. Audience determines what deliverable to choose, as well as what style and tone to apply to it. Wrong idea of the target audience’s needs may result in total failure of documentation. Therefore, a good information developer should be aware of every possible target user. Having deep knowledge of the product, understanding the aim of the documentation and the audience – their needs, possibilities, desires, and preferences, results in a masterpiece documentation.
So, how do we know what our target user wants? The answer is research! And I did a little research of my own on one of the most fast-growing generations in history. Millennials. So, let’s have a closer look at them and try to do our best to meet their expectations.
What if a Technical Communicator without localization experience was commissioned a localization task? What if they accepted without being familiar with the localization guidelines? What if they failed? There are no definite answers to these questions, but the one, which is for sure certain, is that certain guidelines are to be followed. So, let’s take a look at what major problems and potential pitfalls may come up on the way of a Technical Communicator challenged to complete a task in which they haven’t gained enough experience yet.
In a modern digitalized world, there is no need to write long messages to express feelings or intentions. With one click, people show emotions and actions – just by using emojis. These cute small symbols make text brighter, and we use them every single day. But do you know what history stands behind these funny pictures and how they can be used even in technical communication?
Today I want to share with you a brilliant post covering all the basics that an Information Developer should know about how colors work, brought to you by Dave Gash, a Technical Writer at Google.
In a nutshell, it’s a great read—both fun and educational—that explains how colors work. It’s all there – physics, optics, additive and subtractive color systems, hexadecimal arithmetic (!) and, most importantly, demonstration of how it all works together in real life (I mean, in a real-life CSS).
Believe it or not, CSS color codes really are intuitive. You’ll be surprised to see how obvious it is that “#000000 can’t be anything but black“, and “#ff0000 cannot possibly be anything but bright red“. On top of that, there’s a quiz, real-life CSS examples, and links to useful resources and tools, which all adds immensely to the post’s educational value.
Thanks to the author for gathering all this information and presenting it in such a fun and easy way! That’s rock’n’roll, folks.
Most technical communicators I know can be divided into 2 types.
There are the ones who love creating general About/Welcome sections in their docs and get off on illustrating workflows, business value, etc.
And then, the ones who need a whole cake and then some to coax themselves into writing overviews and designing diagrams. It’s much easier for this type to write instructions about tangible, down-to-earth, even techy stuff.
My friend Viktoria Bezsmolna is the definitive type 1. Still, this free-spirited girl landed in our InfoDev department. But soon enough, she eloped to marketing. And then to PR. Now, she is a freelance writer and has her own blog – yay!
I finally decided to get to the bottom of how this journey worked out for her.
Our 1,5-hour interview was very thought-provoking, and here’s how it all summed up in my head.
Look at the following broken-line graph (Figure #1). How much time do you need to create one? 5 – 10 minutes? How about two days?
Figure #1 (Click to enlarge)
Now, if I provide an estimate of two days for creating a graph, my Customer will expect to receive a 3D visualization, in color. Then, where is the problem? Why creating a graph with a few broken lines might take that much time?