Content guidelines¶

While we encourage you to adopt your own writing style, some rules still apply to maintain clarity and ensure readers can easily understand the content.

Documentation organization¶

When writing documentation about a given topic, keep pages within the same folder organized.

For most topics, a single page should do the job. Place it in the appropriate section of the documentation (e.g., content related to the CRM app goes under User Docs ‣ Sales ‣ CRM) and follow the document structure guidelines.

For more complex topics, several pages may be needed to cover all their aspects. Usually, you will find yourself adding documentation to a topic that is already partially covered. In that case, either create a new page and place it at the same level as other related pages or add new sections to an existing page. When documenting a complex topic from scratch, organize the content across several child pages that are referenced on that directory’s parent page (the TOC page); whenever possible, write content on the parent page and not only on the child pages. Make the parent page accessible from the navigation menu by using the show-content metadata directive.

applications/websites/website/configuration/unsplash.rst applications/general/integrations/unsplash.rst

Document structure¶

Use different heading levels to organize text by sections and sub-sections. Headings are not only displayed in the document but also on the navigation menu (only the H1) and on the “On this page” sidebar (all H2 to H6).

To write good titles and headings:

• Be concise: avoid sentences, questions, and titles starting with “how to”.

• Do not use pronouns in your titles, especially 2nd person (you/your).

• Use sentence case. This means you capitalize only:

  • the first word of the title or heading;

  • the first word after a colon;

  • proper nouns (brands, product and service names, etc.).

Writing style¶

Writing for documentation is not the same as writing for a blog or another medium. Readers are more likely to skim through content to find the information they need. Keep in mind that the documentation is a place to inform and describe, not to convince and promote.

Spelling¶

Use American English spelling and grammar throughout the documentation.

Consistency¶

Consistency is key to everything.

Make sure that the writing style remains consistent. When modifying existing content, try to match the existing tone and presentation or rewrite it to match your own style.

Capitalization¶

• Use sentence case in titles.

• Capitalize app names, e.g., Odoo Sales, the Sales app, etc.

• Capitalize labels (such as fields and buttons) as they appear in Odoo. If a label is in all caps, convert it to sentence case.

• Capitalize the first letter after a colon if it is a complete sentence.

• Avoid capitalizing common nouns, such as “sales order” and “bill of materials”, unless you reference a label or a model.

Grammatical tenses¶

In English, descriptions and instructions usually require the use of the present tense, while the future tense is appropriate only when a specific event is to happen ulteriorly.

Lists¶

Lists help organize information in a clear and concise manner and improve readability. They are used to highlight important details, guide the reader through steps in a systematic way, etc.

Use numbered lists when the sequence matters, e.g., instructions, procedures, or steps that must be performed in a particular order.

Use bulleted lists when the sequence of items does not matter, e.g., lists of features, fields, options, etc.

Icons¶

Use icons in instructions to help readers identify user interface elements and reduce the need for lengthy explanations. Accompany every icon with a descriptor in brackets.

Images¶

Adding a few images to illustrate text helps the readers understand and memorize the content. However, images should never replace text: written instructions should be complete and clear on their own, without relying on visual aids. Use images sparingly, for example, to highlight a particular point or clarify an example.

Screenshots¶

Screenshots are automatically resized to fit the content block’s width. This implies that if they are too wide, they are not readable on lower-resolution screens. We recommend avoiding full-screen screenshots of the app unless absolutely necessary and making sure images are no wider than a range of 768-933 pixels.

Here are a few tips to improve your screenshots:

1. Resize your browser’s width, either by resizing the window itself or by opening the browser’s developer tools and resizing the width.

2. Select the relevant area rather than keeping the entire window.

3. Remove unnecessary information and resize columns when applicable.

Example

Good example (resized browser, no unnecessary columns, adjusted columns’ width, cropped):

Bad example (full-width screenshot):

Media files¶

A media filename:

• is written in lower-case letters;

• is relevant to the media’s content. (e.g., screenshot-tips.gif);

• separates its words with a hyphen - (e.g., awesome-filename.png).

Each RST file has its own folder for storing media files. The folder’s name must be the same as the RST file’s name.

For example, the document doc_filename.rst refers to two images that are placed in the folder doc_filename.

├── section
│   └── doc_filename
│   │   └── screenshot-tips.gif
│   │   └── awesome-filename.png
│   └── doc_filename.rst

ALT tags¶

An ALT tag is a text alternative to an image. This text is displayed if the browser fails to render the image. It is also helpful for users who are visually impaired. Finally, it helps search engines, such as Google, to understand what the image is about and index it correctly, which improves SEO.

Good ALT tags are:

• Short (one line maximum);

• Not a repetition of a previous sentence or title;

• A good description of the action happening in the image;

• Easily understandable if read aloud.

Example

An appropriate ALT tag for the following screenshot would be Activating the developer mode in the Settings app.