The phases of project initiation and project closure are substantially covered in blog posts, talks, and other resources across the TechComm society. Today, I would like to address a less frequently discussed phase – replacing a technical communicator in a project team.
Have you ever been assigned a task to write API documentation, and then you got lost in tools for creating it?
If yes, I would like to share with you amazing research by Diána Lakatos who analyzed loads of info to provide us with a magnificent overview of open-source tools for documenting APIs.
Is storytelling the same as writing well? How to write a concise yet interesting API guide? Is there a way to keep a help system offhand and casual without using humor? All this and much more in my presentation!
Complex System of Information Security (CSIS) comprises a set of organizational and technical measures aimed to ensure the protection of information circulating in the system from disclosure, leakage, and unauthorized access (c).
If your company is implementing the CSIS, it’s in for reinforced credibility and boosted sales. And you as a Technical Communicator are in for a bumpy ride. 😊
Let’s take a look at a grueling journey of meticulously described processes, roadmaps, and guidelines that need to accompany every stage of the System development.
From a TechComm newbie to a well-experienced pro, we all have hundreds of useful resources saved to our browser bookmarks, read-it-later apps, and bookmark managers. The series of posts TechComm handy resources is a humble try to organize my resources into a single easily accessible depository.
People tend to create stereotypes about things they don’t have much insight into. I broke into information development from a different industry, and I’d like to share my own experience of mythbusting.
Before starting my career as an Information Developer, I was a translator and had little awareness of the role and its responsibilities. As a philosopher once said, “Theory without practice is empty”, and I’m glad I got a chance to fill the void and break my stereotypes during the first month of practical experience. Let me share some of them with you. Continue reading
In 2018, we devoted several posts to the latest writing style guide from Microsoft:
- Microsoft Manual of Style vs. Microsoft Writing Style Guide
- MMoS vs MSG: The old, the new, and the unexpected
Yet, Microsoft guidelines is the topic one can talk about endlesly, isn’t it? 🙂 This time, I decided to focus on a few aspects of procedure writing and formatting that grabbed my attention most.
Grab your favorite drink, turn up the sound, and don’t miss the quiz at the end of the video!
Here’s a sneak peek at the video highlights:
- Use device-neutral verbs.
Users may interact with your product using various devices and input methods.
- Minimize UI terminology (menu, tab, box, and similar.).
Fewer words make actions more clear. Compare these: “From the File menu, select the New option” and “Go to File > New”.
- Mind the look and feel of your text.
Proper combination of font size, line spacing, and capitalization makes your text more scannable and easy to follow. Microsoft provides specific formatting advice to get you started.
Do you use these guidelines in your docs and did they make a difference for you? Let us know in the comments!