Modern businesses love everything seamless. Like, Continuous Integration is a new go-to for software engineers. The underlying principle is sharing code as often as possible, ideally, several times a day.

For technical writers this means that help topics need to be updated constantly. This thing alone is a challenge, but it becomes increasingly alarming when you have more stuff piling up on top of that like... continuous localization.

https://bit.ly/2MmZ2vT

Listening to our clients and fine-tuning our development road map based on the feedback is how we prefer to move forward. Although ClickHelp is a pretty straightforward help authoring tool with an intuitive UI, it can be really hard to cover all its functionality in one go. So, today, we will give you a kind of an impromptu FAQ session that, hopefully, will answer some of the questions you have about our software documentation tool for technical writers ⁉️
https://bit.ly/2pXVCIr

In continuous integration, software developers submit code to a shared repository several times a day. The main idea behind it is catching issues at the earliest stages and fixing them. And, in theory, you can have new releases daily.

This process influences every team in the company, the documentation team included. Working in a CI environment poses new challenges for technical writers and demands for a more careful choice of a help authoring tool as a lot will depend directly on it.
https://bit.ly/2VHOITw

People like to think that they got rid of Waterfall for good, while in reality, many companies are still performing somewhere in between Waterfall and Agile. Nevertheless, even if you feel like you can't call what your company is doing pure Agile, you need to be prepared to face what this new model is going to bring.

https://bit.ly/32wCbF6

While technical documentation is mostly associated with text, it is much more than this. Without visual content technical texts are boring and hard to comprehend. Using diagrams in help topics is a great way to improve your content.

However, you need to remember that with diagrams less is often more; they are extremely helpful, but only when used right. Let's see how you can get the most benefit!

https://bit.ly/33Kin1g

When a customer opens a user manual, the idea that the text is lying or it is trying to manipulate them will hardly ever cross their mind. Who would want to lie in technical documentation and why?

The grim statement proclaiming that everybody lies proves to be true yet again. Here's what technical writers lie about.

https://bit.ly/2Jn8sH2

You will certainly meet people in this world who say things like 'I don't care how this user manual looks as long as it is well-written and contains answers to my questions.' It is great to know that some people are this practical and able to look past the visual side of things. However, people are naturally attracted to things that look if not super-awesome then at least hitting the standard they have in their mind about something.

Let's talk about 'levels of spookiness' of technical documentation and analyze a real user manual example. These levels are nothing serious or scientific; let's have some Halloween fun and hopefully learn something useful! 🎃

https://bit.ly/3224pXq

Does authoring help topics make you an author? We believe it does. And although maybe everything you are creating along the lines of technical documentation becomes the property of the company you are working for, it is more about how you are perceiving yourself.

We are often writing about stuff like whether you need to be an IT specialist in order to create software documentation. But, since it is the Author’s day, we want to talk about something different this time around: why any technical writer has the privilege to be called an author 📝

https://bit.ly/2NIPAnx

Parallel structure in writing means that sentences or elements within sentences have a similar grammar pattern. Such repetition serves several purposes. In literature, it is often a means to draw a reader's attention to a particular situation, certain ideas. That's a pretty common and straightforward literary device.

While it is clear that technical text is not supposed to include most of the literary devices like metaphors, allusions, satire, or symbolism since they bring vagueness and open the text to interpretation which is unacceptable in user manuals, parallel constructions are an exception.

https://bit.ly/2NKQIGT

If you are concerned about your user manuals looking bad, this article will give you certain focus points improving which can turn the situation around.

How far you want to take it depends on your subjective opinion regarding this matter. However, we would still advise you to look at how you can improve certain things. Better looking documentation will definitely make your users happier!

https://bit.ly/2CotvFh

Developing good habits and getting rid of the bad ones is something that applies not only to our personal lives but our careers as well. Today we'd like to talk about good habits that technical writers can work on to improve performance and prevent burnouts.

Behold! These habits will change things for the better.

https://bit.ly/36WuR8n