Contribute H2 · Styleguide: Rewrite of Content guidelines

This commit is contained in:
Fede.- 2022-02-11 16:49:36 -03:00
parent 7643bee675
commit f7cc4e928c
7 changed files with 318 additions and 273 deletions

View File

@ -29,7 +29,7 @@ The only directory we are interested in for creating, editing and translating ho
As we can see in the image above, the **pages** directory contains several other directories and subdirectories.
- **01.home**: here is the **Howto** landing page.
- **02.tutorials**: this is the directory where all the howtos are located and organized by categories (eight so far).
- **02.tutorials**: this is the directory where all the howtos are located and organized by categories.
- **03.Glossary**: here is the page where we intend to gather most of the important terms we use through the howtos and guides.
- **04.Contribute**: in this directory we will find guides on how to create, edit and translate the pages of the site.
- **05.Licensing**: the license under which the site content is released.
@ -66,44 +66,27 @@ Below there is a list of the most common variables that can be specified in each
- **page-toc**: set by a boolean value, *true* or *false*. Determines if a *Table of Content* is visible on page or not. Usually it is set to false for index pages (docsparent.md).
For example, if we take a look at the **Cloud** index page header (02.Cloud/docsparent.en.md)
To better understand how these variables affect the pages, we can take a look at, for example, the **Cloud** index page header (02.Cloud/docsparent.en.md):
_docsparent.md_
- _docsparent.md_ at the index/home page
![](en/docsparent_view.png)
_docs.md_
```
---
title: 'Cloud: Nextcloud Introduction'
published: true
visible: true
indexed: true
updated:
________last_modified: "April 2019"
________app: Nextcloud
________app_version: 15
taxonomy:
____category:
________- docs
____tags:
_______- cloud
page-toc:
____active: true
---
```
- _docs.md_ header and view at the Cloud howto index (02.Cloud/docsparent.en.md)
![](en/docs_view.png)
## Meta information
Meta information is set automatically when specified in the page header under 'updated:' section
The meta information is set automatically when specified in the page header under the `updated:` variable. It is necessary to let readers know if the howto is up to date. The fields to complete are:
```
updated:
________last_modified: "April 2019"
________app: Nextcloud
________app_version: 15
```
`last_modified:` "Month and Year" wrapped between `" "` _(i.e: "June 2020")_<br>
`app:` Software name _(i.e: Nextcloud)_<br>
`app_version:` Number version of the software _(i.e: 18)_<br>
### Where to place the Meta information?
This information is not necessary in the indexes, but in those pages where there is data that may vary with updates.
![](en/meta.png)

Binary file not shown.

After

Width:  |  Height:  |  Size: 361 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 186 KiB

After

Width:  |  Height:  |  Size: 189 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 285 KiB

View File

@ -0,0 +1,44 @@
---
title: 'Information guidelines'
published: true
visible: true
updated:
taxonomy:
category:
- docs
tags:
- contribute
- style
page-toc:
active: true
---
# Building the information guidelines
## First question: What can we write about?
This question is already partially answered in the main page of this site:
> *"We aim to cover all the services, with all its **Disroot**'s provided features, for all platforms and/or Operating Systems as well as the largest possible number of clients for the most widely used devices"*
So we can write about the software provided by **Disroot**, how they work and what can we do with them. That seems quite evident until we ask ourselves if we all use the same operating system in our computers or mobile devices.
The fact that our focus is exclusively on the use, promotion and spreading of **free and open source software** (and therefore our howtos are written mainly for GNU/Linux) should not make us forget that there are many people who choose to use proprietary software and their approach to our services is not related to ethical or political reasons but pragmatic.
That is why we explicitly say:
> *"for all platforms and/or Operating Systems as well as the largest possible number of clients for the most widely used devices"*
A basic list of the main operating systems we try to cover would be the following:
- **GNU/Linux**, **Microsoft Windows** and **Apple macOS** on desktop and laptop computers and
- **Google Android**, **Apple iOS**, **Jolla Sailfish OS** and **Microsoft Windows Mobile** on mobile devices.
!! **Everyone, no matter the operating system they use, can collaborate by writing how to use a service. Remember that the most important thing is to make the information available to anyone.**
## Second question: Who are the howtos aimed at?
In principle, any person over 16 years of age can use the **Disroot** services. But we can also think about the fact we all have, for example, relatives and acquaintances older that us who we would like to introduce to the use of socially ethical and technically useful tools or maybe they just want to do it by themselves.
So when writing a howto we must think that the information must be understandable to anyone, regardless of age or technical knowledge. Of course, there are always software that are more complex than others, but that should not mean that we do not make the effort to try to make it possible for anyone to learn them.
This leads to the following question.
## Third question: What type of language should we use?

View File

@ -0,0 +1,255 @@
---
title: 'Visual guidelines'
published: true
visible: true
updated:
taxonomy:
category:
- docs
tags:
- contribute
- style
page-toc:
active: true
---
# Content visual guidelines
The content of a how-to then should meet the following criteria:
1. **Use of visual aids (if it's possible) like**:
- Screen shots
- Gif / video recording of the desktop or mobile
!!
!! For gif / video recordings of a desktop we usually work with [**Peek**](https://github.com/phw/peek)
!!
!! For mobile devices you can use [**screenrecorder**](https://f-droid.org/en/packages/com.orpheusdroid.screenrecorder/)
2. **Easy to adapt by other projects**: In order to do so, we think that mentions to **Disroot** and other unique identifiers of the **Disroot** project, should be kept at the necessary minimum and the content the more generic and adjectiveless as possible. This way, it's easier for other projects to use, adapt and edit the howtos.
3. **Concise text content**: Write only what is necessary to explain a task or a feature and warn about important things users should know.
4. **Avoid long text paragraphs**
5. **Use bullet points instead of a big paragraphs when describing several steps or features**
6. **Avoid using tables, unless it serves a purpose other then text formating.**
#### Notes:
Start line with !! to format notices. Add exclamation mark image with \!\[]\(/home/icons/note.png)
Example:
!! ![](/home/icons/note.png)
!! **NOTE!** If you lose your password, you won't be able to retrieve your files on the cloud as they're encrypted, so even the server administrators can't see their content.
#### Inline images
Images are centered by default in the next line. To use an image inline, so on the same line of a sentence use {.inline} right after. Like in this example:
```
![](en/07_share_button.png) {.inline}
```
----------------------------------------------------------------------
# Some formating tips
**Disroot**'s [How-to Website](https://howto.disroot.org/) is built with [Grav](https://getgrav.org/), and uses **Markdown** as Markup / Formating text composing language because it's an easy one to do so.
So if you want to write a how-to for **Disroot** and you're not experienced with Markdown, here are some tips and recomandations about the text formating of a tutorial.
## Titles
The how-to title itself goes in the page header, you can edit it if you use git.
As for the different sections titles of a how-to you can compose it in Markdown by using the `#` symbol and a space before the title itself. For example:
Writing this...
```
# Title 1
## Title 2
### Title 3
#### Title 4
##### Title 5
```
...will be displayed as:
# Title 1
## Title 2
### Title 3
#### Title 4
##### Title 5
The more `#` you use the smaller the title will be.
Titles are important for several reasons. One of the main is that Grav uses them to automatically generate the TOC (Table of Content) of the page. So they can be used to show the different chapters / sections of the howto at the top of the page index.
Smaller titles appear as "sub chapters" in the TOC. This could be useful to do something like this:
We recommend the using of one `#` for the main page title and two `##` for sub chapters. You can use `###` titles for minor headers within the text, that you want to be in the TOC and even smaller titles for headers that do not need to be in the TOC.
## Lists
Please, use lists to list steps or features in a howto.
Making bullet points is easy. Writing...
```
My List:
- something 1
1. sub item 1
2. sub item 2
- something 2
```
...will show this:
My List:
- something 1
1. sub item 1
2. sub item 2
- something 2
## Bold
Please, use bold to highlight:<br>
- Important information
- Warnings to the user
- Or a smaller title inside a section that is not necessary to be listed in the TOC.
To highlight a word or a line with bold, use two `*` symbol before and after the part it needed.<br> For example, if you write...
`**Something**`
it will be displayed as:
**Something**
## Italic
Italic works in a similar way as bold. You can use the `_` symbol or one `*` symbol before and after the word or text section you want to apply the format.<br>
Examples:<br>
Writing...<br>
`_example_`<br>
`*example*`
... will show this:
_example_<br>
*example*
## Links
Sometimes we need to insert links to some pages or websites. It can be done this way:
Writing `[link to Disroot website](disroot.org)`
will be displayed as:
[link to Disroot website](disroot.org)
## Embedding videos / gifs / screenshots in the howto
As we've mentioned, we like images / videos in the tutorials. You can embed them by doing the following:
- First: Creating a folder where to put the videos / gifs / images
- Second: Naming the files by the order in which they will appear troughout the how-to
Then create a link with the path to the folder and name of the file in question.<br>
So if you write...
`![](name_of_folder_full_of_media_files/example_1.png)`
... you will see this:
![](en/name_of_folder_full_of_media_files/example_1.png)
And if you do this:
`text before ![](name_of_folder_full_of_media_files/example_1.png) text after`
you'll get this:
text before ![](en/name_of_folder_full_of_media_files/example_1.png) text after
The structure described above also works to embed gifs and .mp4 videos.
## Code
If you need to show some terminal commands, code lines, instructions or examples like the ones we've been doing through this guide, you can use the **`** symbol before and after the text you want to show.<br>
For example:<br>
This is a command line command: `sudo apt update`
# Terminologies
To make the tutorials more coherent and easier to be adapted by other groups, we recommend the use of the following criteria:
- When writing a how-to, **Disroot**'s name should be referred as: **Disroot**, starting with capital letter and bold type.
- And the different services refered as follows:
|Service|Disroot name|
|-:|:-|
|Lufi|**Disroot Upload**|
|Forum/Discourse|**Disroot Forum**|
|Etherpad|**Disroot Pad**|
|EtherCalc|**Disroot Calc**|
|XMPP|**Disroot Chat**|
|Email services in general|**Disroot Email**|
|Rainloop|**Disroot Webmail**|
|Hubzilla Instance|**DisHub**|
|Private Bin|**Disroot Bin**|
|Polls|**Disroot Polls**|
|Nextcloud:|**Disroot Cloud**|
|Nextcloud Calendar App|**Disroot Calendar**|
|Nextcloud Notes App|**Disroot Notes**|
|Nextcloud Contacts App|**Disroot Contacts**|
This way, if the expressions are regular, it's easier to just do a "*Search and replace*" :wink:
# Video how-to's
For video how-tos we also think that the content should be **kept at the minimum** and **short** enough for the user to be able to complete a task and for the clarity sake of it.
Same as the text how-tos, the tutorials should have the following structure:
1. **Meta information**
2. **Content**
3. **Licensing information**
**Meta information** and **licensing information** will be placed by the **Disroot** admins in the video description of the Peertube instance where the videos will be hosted.
## Description of Content
To the extent possible, videos should go with:
- Title of the how-to
- Brief description of what it is about
- Software version it refers to
So that they can be placed by **Disroot** admins on the video description at the Peertube instance.
## Content
## Licensing of video how-to's
As we mentioned before, the licensing information will be placed by **Disroot**'s Admins in the video description.
However we recommend that you place the following image at the end of your video for about 10 seconds fade in and out:
![](en/licensing-pic.png)
In this case if the video is downloaded and reuploaded somewhere else the license information is still there.
---

View File

@ -1,5 +1,5 @@
---
title: 'Style Guide: Content'
title: 'Content guidelines'
published: true
visible: true
updated:
@ -13,246 +13,9 @@ page-toc:
active: true
---
# Content guidelines
There are several ways to write or translate a guide, no doubt. And if we search on the Internet we will find all kind of styles: from very technical to some very funny ones, passing through some quite boring, some visually impressive and others certainly spartan in more than one aspect. But they all have one thing in common: **the information**. That is our raw material.
# Content guide lines
The **Howto Project** is about providing, not just any information, but useful information about the software available on the **Disroot** platform in the clearest and most accessible way we can. But how to achieve this?
We think that how-to's text content should be kept at the minimum for the clarity and portability sake of it. In the ideal case, just the specific context necessary, the essential steps to do a task and, whenever it's possible, supported by visual aids (screenshots, gifs) showing how a task is being done.
The content of a how-to then should meet the following criteria:
1. **Use of visual aids (if it's possible) like**:
- Screen shots
- Gif / video recording of the desktop or mobile
!!
!! For gif / video recordings of a desktop we usually work with [**Peek**](https://github.com/phw/peek)
!!
!! For mobile devices you can use [**screenrecorder**](https://f-droid.org/en/packages/com.orpheusdroid.screenrecorder/)
2. **Easy to adapt by other projects**: In order to do so, we think that mentions to **Disroot** and other unique identifiers of the **Disroot** project, should be kept at the necessary minimum and the content the more generic and adjectiveless as possible. This way, it's easier for other projects to use, adapt and edit the howtos.
3. **Concise text content**: Write only what is necessary to explain a task or a feature and warn about important things users should know.
4. **Avoid long text paragraphs**
5. **Use bullet points instead of a big paragraphs when describing several steps or features**
6. **Avoid using tables, unless it serves a purpose other then text formating.**
#### Notes:
Start line with !! to format notices. Add exclamation mark image with \!\[]\(/home/icons/note.png)
Example:
!! ![](/home/icons/note.png)
!! **NOTE!** If you lose your password, you won't be able to retrieve your files on the cloud as they're encrypted, so even the server administrators can't see their content.
#### Inline images
Images are centered by default in the next line. To use an image inline, so on the same line of a sentence use {.inline} right after. Like in this example:
```
![](en/07_share_button.png) {.inline}
```
----------------------------------------------------------------------
# Some formating tips
**Disroot**'s [How-to Website](https://howto.disroot.org/) is built with [Grav](https://getgrav.org/), and uses **Markdown** as Markup / Formating text composing language because it's an easy one to do so.
So if you want to write a how-to for **Disroot** and you're not experienced with Markdown, here are some tips and recomandations about the text formating of a tutorial.
## Titles
The how-to title itself goes in the page header, you can edit it if you use git.
As for the different sections titles of a how-to you can compose it in Markdown by using the `#` symbol and a space before the title itself. For example:
Writing this...
```
# Title 1
## Title 2
### Title 3
#### Title 4
##### Title 5
```
...will be displayed as:
# Title 1
## Title 2
### Title 3
#### Title 4
##### Title 5
The more `#` you use the smaller the title will be.
Titles are important for several reasons. One of the main is that Grav uses them to automatically generate the TOC (Table of Content) of the page. So they can be used to show the different chapters / sections of the howto at the top of the page index.
Smaller titles appear as "sub chapters" in the TOC. This could be useful to do something like this:
We recommend the using of one `#` for the main page title and two `##` for sub chapters. You can use `###` titles for minor headers within the text, that you want to be in the TOC and even smaller titles for headers that do not need to be in the TOC.
## Lists
Please, use lists to list steps or features in a howto.
Making bullet points is easy. Writing...
```
My List:
- something 1
1. sub item 1
2. sub item 2
- something 2
```
...will show this:
My List:
- something 1
1. sub item 1
2. sub item 2
- something 2
## Bold
Please, use bold to highlight:<br>
- Important information
- Warnings to the user
- Or a smaller title inside a section that is not necessary to be listed in the TOC.
To highlight a word or a line with bold, use two `*` symbol before and after the part it needed.<br> For example, if you write...
`**Something**`
it will be displayed as:
**Something**
## Italic
Italic works in a similar way as bold. You can use the `_` symbol or one `*` symbol before and after the word or text section you want to apply the format.<br>
Examples:<br>
Writing...<br>
`_example_`<br>
`*example*`
... will show this:
_example_<br>
*example*
## Links
Sometimes we need to insert links to some pages or websites. It can be done this way:
Writing `[link to Disroot website](disroot.org)`
will be displayed as:
[link to Disroot website](disroot.org)
## Embedding videos / gifs / screenshots in the howto
As we've mentioned, we like images / videos in the tutorials. You can embed them by doing the following:
- First: Creating a folder where to put the videos / gifs / images
- Second: Naming the files by the order in which they will appear troughout the how-to
Then create a link with the path to the folder and name of the file in question.<br>
So if you write...
`![](name_of_folder_full_of_media_files/example_1.png)`
... you will see this:
![](en/name_of_folder_full_of_media_files/example_1.png)
And if you do this:
`text before ![](name_of_folder_full_of_media_files/example_1.png) text after`
you'll get this:
text before ![](en/name_of_folder_full_of_media_files/example_1.png) text after
The structure described above also works to embed gifs and .mp4 videos.
## Code
If you need to show some terminal commands, code lines, instructions or examples like the ones we've been doing through this guide, you can use the **`** symbol before and after the text you want to show.<br>
For example:<br>
This is a command line command: `sudo apt update`
# Terminologies
To make the tutorials more coherent and easier to be adapted by other groups, we recommend the use of the following criteria:
- When writing a how-to, **Disroot**'s name should be referred as: **Disroot**, starting with capital letter and bold type.
- And the different services refered as follows:
|Service|Disroot name|
|-:|:-|
|Lufi|**Disroot Upload**|
|Forum/Discourse|**Disroot Forum**|
|Etherpad|**Disroot Pad**|
|EtherCalc|**Disroot Calc**|
|XMPP|**Disroot Chat**|
|Email services in general|**Disroot Email**|
|Rainloop|**Disroot Webmail**|
|Hubzilla Instance|**DisHub**|
|Private Bin|**Disroot Bin**|
|Polls|**Disroot Polls**|
|Nextcloud:|**Disroot Cloud**|
|Nextcloud Calendar App|**Disroot Calendar**|
|Nextcloud Notes App|**Disroot Notes**|
|Nextcloud Contacts App|**Disroot Contacts**|
This way, if the expressions are regular, it's easier to just do a "*Search and replace*" :wink:
# Video how-to's
For video how-tos we also think that the content should be **kept at the minimum** and **short** enough for the user to be able to complete a task and for the clarity sake of it.
Same as the text how-tos, the tutorials should have the following structure:
1. **Meta information**
2. **Content**
3. **Licensing information**
**Meta information** and **licensing information** will be placed by the **Disroot** admins in the video description of the Peertube instance where the videos will be hosted.
## Description of Content
To the extent possible, videos should go with:
- Title of the how-to
- Brief description of what it is about
- Software version it refers to
So that they can be placed by **Disroot** admins on the video description at the Peertube instance.
## Content
## Licensing of video how-to's
As we mentioned before, the licensing information will be placed by **Disroot**'s Admins in the video description.
However we recommend that you place the following image at the end of your video for about 10 seconds fade in and out:
![](en/licensing-pic.png)
In this case if the video is downloaded and reuploaded somewhere else the license information is still there.
---
Well, we can ask ourselves some questions and see if we can build together some definitions to guide us in the task.