# Tips For Writing Documentation¶

Being busy now for more than month improving the documentation for the Plone trainings with lots of interesting and eye opening moments it is time for some words of wisdom :)

First, I would like to say thank you for all people who took time to contribute you are awesome !

As I said already before, writing documentation is not uncomplicated. Besides the knowledge about the topic you write about, you need to know how to reach your audience (tone of voice), how to structure and how to write your docs in a appealing way (more on that later).

## Think First - Write Later¶

What ? Write later ? Crazy ?

Nope, I am not (I mean show me one person who is not).

This is IMHO (In My Humble (Honest) Opinion) one of the most important points.

People tent to forget that and have the habit of start writing without a clear plan and structure in mind, which often results in chaotic and unstructured documentation which is hard to read and follow.

Plan and structure your docs carefully:

• Which topics to cover
• Order of the topics
• Background knowledge and information
• Extended information
• Exercises
• Requirements
• Sexy factor (I will cover that later)

## Be Clear From The Beginning¶

Mention explicit in the beginning the audience and level you want to address, is the training for all levels or is it for experienced Plone developer ?

Give a short introduction about the training, let the people know what the training will cover

## Do Not Expect Your Level Of Knowledge¶

What would be the point of giving trainings, right ? :)

Do not expect that the audience have the same wisdom you have, do not expect that someone who is following the training about Plone deployments with Ansible knows what ZMI stands for.

Provide these information in the docs (by using a glossary) and during the presentation !

Try to think as an attendee ! Hah ! That is different, isn’t it ? :)

## Bonus Tip¶

Ask someone else who is not involved to understand your writings !

## The Language Thing¶

Keep in mind that the majority of us is not native speaking English.

We learn/learned English as second, third, fourth, language.

Keep that in mind during writing, use common words and also try to avoid stuff like we’re, using we are is better to understand.

## Lets Write¶

In the following some tips for the time we you actually write.

Sorry we are not there yet, but almost !

It is stunning how many people do not configure their editors for writing. Why ? What is wrong with you ? (No offense).

No one is perfect, everyone makes typos or syntax errors in reST (reStructuredText).

I mean you use pep or flake8 or both with python, right ? Why not use a spell-checker and a reST linter on your writings ?

### Bonus Tip¶

If you want examples for setting up Vim, Sublime, Atom or Visual Studio get in contact !

### Do Not Trust All Linter¶

Ahe ? You said use linter, now you are saying do not trust them ?

Some linter are somewhat strict, which is OK for writing prose, but hard to follow writing documentation.

Take the results with a grain of salt. :)

## Writing¶

Yes, lets talk about writing !

• The content of the headers

This brings us pretty much back to the beginning of this post, structure.

Also, decide for one structure and use this one through the whole documentation. Please do not change your header structure with every document.

==========
==========

==========

------------

I will publish more on that in the upcoming style-guide for writing training documentation, soon !

Keep is short and two the point !

Examples:

Great:

Solr Query Syntax
=================

Not that great:

site_actions
++++++++++++++++

The fist one clearly describes something, the second one is less clear.

Which brings us to the next point.

### Code Blocks¶

Code blocks, if right used are awesome, because by using the you improve the readability of your docs a lot.

Let me show you two pictures of the same training documentation one without and one with code blocks:

#### Use Valid Code Examples¶

If you use code blocks, make sure that your examples are actually valid code ! Cutting off brackets or maybe parts will lead to not working code examples, which will look bad to the user and also will produce warnings or even build errors of the docs.

##### Examples¶

Not that great:

.. code-block:: json

"ebs_snapshots" : {
"aws_key" : "***** AWS KEY FOR SNAPSHOTTING (IAM USER) *****",
"aws_secret" : "***** AWS SECRET FOR SNAPSHOTTING (IAM USER) *****"}

Will result in no code highlighting and build warnings !

Great:

.. code-block:: json

{
"ebs_snapshots" : {
"aws_key" : "***** AWS KEY FOR SNAPSHOTTING (IAM USER) *****",
"aws_secret" : "***** AWS SECRET FOR SNAPSHOTTING (IAM USER) *****"}
}

Is excellent !!

### Pep8 And Friends¶

Pep8 and friends are super cool and helpful for writing Python, for reST not so much !!

Even worst using “pep8 style” line length will result in bad documentation.

Why ?

First, like I said by using “pep8 style” and cutting your written words by 79 characters it gets hard to read (review) the docs.

This is not a problem for the created HTML, but it is a huge annoyance for reviewing and improving.

Reading the whole sentence gets really hard !

It is really bad for the sexy factor, yes now we are talking about it !

By polluting your docs with unnecessary lines, because of pep8, you make it harder for your self to create user appealing documentation.

Using pep8 makes it harder to translate, since your sentence is cut in a weird way.

Remember, we like one sentence per line, if possible !

#### Solution¶

• Aim for docs for around 120 - 130 characters per line.
• One sentence per line, if possible, if not split meaningful

## The Sexy Factor¶

People still underestimate this !

If you one of these, let me tell you, no offense, but you are wrong !

If you want that people follow your docs and stay motivated you have to make sure that your docs are not ‘only’ well written and structured but also that they look somehow appealing !