GeneXus Community Wiki Style Guide

Official Content

This article is aimed at all those who write in the GeneXus Community Wiki.

It gives you specific guidelines and patterns to write with the same criteria. Therefore, here you will find the decisions taken for the style of writing in the documentation.

Language

Community Wiki documents should be written preferably in English (American English).

Basic styles

The writing style is the same as Google's way of writing and Microsoft's way of writing.

Grammatical person to whom you write

You have to write to the reader in the second person (you). So do Google and Microsoft.

The public of the GeneXus Community Wiki, in general, are developers, so you write "you" to developers readers. If you need to differentiate developer from end-user, you have to take that into account. 

Good examples of second-person writing

yes " When you download the setup, ..."
yes "When pressing the F5 key, ..."  

This link provides more examples and useful alternatives to writing in the second person.

You have to avoid some ways of writing

Avoid writing "let's"

Example #1
no "Let’s suppose that a company sells products and offers services."
yes "Suppose that a company sells products and offers services."

Example #2
no "
Let's see an example."
yes "Look at the following example."


Avoid writing "we... " / "our..."

Example #1
no "As we know, there are many ways to..."
​​​​​​yes "There are many ways to..."

​​​​​​Example #2
no "Our objective is..."
yes"The objective is..."

Example #3
no "We have the Prize Transaction which allows defining rewards to be traded for miles."
yes "The Prize Transaction allows defining rewards to be traded for miles."

Example #4
no "We call users’ views to the descriptions given by the users who need the application, about their reality and requirements."
yes "The concept of users’ views refers to the descriptions given by the users who need the application, about their reality and requirements."


Important considerations when writing documentation

1) In the first sentence, you always have to write the objective or the definition of what you are documenting (what it is for).

2) Put yourself in the reader's place. If you were the reader of what you are writing, what would you need to be told? What is important and what is not? In what order is it friendly to read it?

3) Describe one idea per paragraph. If there’s more than one, split the paragraphs.

4) If your paragraph contains a list of any type, convert it to a bulleted list.

Example:

Quickly read this:

The User Control object offers the following benefits: It provides the possibility to define User Controls in a built-in way into the Knowledge Base. Also, it allows you to base its appearance on a style provided by a designer, CSS Framework, etc. Besides, it generates a server-side HTML code, which means power, since it is easier to scale a server than the clients.

Now quickly read this:

The User Control object offers the following benefits:

  • It provides the possibility to define User Controls in a built-in way into the Knowledge Base.
  • Allows you to base its appearance on a style provided by a designer, CSS Framework, etc.
  • Generates a server-side HTML code, which means power, since it is easier to scale a server than the clients.

Both contain the same content. However, the second form of writing helps you better understand the information and in less time.
 

5) If your paragraph contains steps to follow (i.e., to set something), convert it to a numbered list. It may be clearer describing steps (Step1, Step2, Step3) instead of writing paragraphs that start with the words "First", "Next", "Then".

6) Use headings properly. Structure your writing with headings.

7) It is vital to write always the exact names of the properties, methods, controls, etc.
    Additionally, you should link the property name with the page which defines it.

Examples

no Auto-number property
yes Autonumber property

no Query Viewer control
yes QueryViewer control

Why?

  • To provide precision to the reader.
  • To be coherent and professional.
  • To help the reader to find it inside GeneXus without doubts. 


8) When writing an article about a property, method, event:
            no Do not start like this:
                       - This property allows you to...
                       - This property is used to...


yes Start like this:
            - Determines...
            - Sets...
            - Names...
            - Describes...

Why?

  • To explain what it is for in a direct way.
  • The GeneXus Community Wiki is integrated with the GeneXus IDE. This means that if you are working with the GeneXus IDE, and you right click on the name of a property, and then you select Show Description, you will see the first sentence of the property article:

IDEPropertyShowDescription

 

9) When you need to indicate a sequence of options the reader must select, use the following writing style: 

yes File > New > Object. 

Do not use other writing styles (in order to maintain coherence):

no File / New / Object. 
no File - New - Object. 


10) The examples always help to finish understanding the explanations. So, try to include an example of use.

 

Suggested tools

  • Grammarly is a spellchecker that helps you wherever you write on the web. So, it will help you when you are editing GeneXus Community Wiki pages. 
  • Hemingway is another application that allows you to paste a paragraph and it detects a different kind of errors in your writing. It also suggests you how to improve them.