docs/documentation_best_practices.md

   1 # Documentation Best Practices
   2
   3 This page exists to document best practices when writing documentation for QMK. Following these guidelines will help to keep a consistent tone and style, which will in turn help other people more easily understand QMK.
   4
   5 # Page Opening
   6
   7 Your documentation page should generally start with an H1 heading, followed by a 1 paragrah description of what the user will find on this page. Keep in mind that this heading and paragraph will sit next to the Table of Contents, so keep the heading short and avoid long strings with no whitespace.
   8
   9 Example:
  10
  11 ```
  12 # My Page Title
  13
  14 This page covers my super cool feature. You can use this feature to make coffee, squeeze fresh oj, and have an egg mcmuffin and hashbrowns delivered from your local macca's by drone.
  15 ```
  16
  17 # Headings
  18
  19 Your page should generally have multiple "H1" headings. Only H1 and H2 headings will included in the Table of Contents, so plan them out appropriately. Excess width should be avoided in H1 and H2 headings to prevent the Table of Contents from getting too wide.
  20
  21 # Styled Hint Blocks
  22
  23 You can have styled hint blocks drawn around text to draw attention to it.
  24
  25 ```
  26 {% hint style='info' %}
  27 This uses `hint style='info'`
  28 {% endhint %}
  29 ```
  30
  31 ### Examples:
  32
  33 {% hint style='info' %}
  34 This uses `hint style='info'`
  35 {% endhint %}
  36
  37 {% hint style='tip' %}
  38 This uses `hint style='tip'`
  39 {% endhint %}
  40
  41 {% hint style='danger' %}
  42 This uses `hint style='danger'`
  43 {% endhint %}
  44
  45 {% hint style='working' %}
  46 This uses `hint style='working'`
  47 {% endhint %}
  48
  49 # Styled Terminal Blocks
  50
  51 You can present styled terminal blocks by including special tokens inside your text block.
  52
  53 ```
  54 \`\`\`
  55 **[terminal]
  56 **[prompt foo@joe]**[path ~]**[delimiter  $ ]**[command ./myscript]
  57 Normal output line. Nothing special here...
  58 But...
  59 You can add some colors. What about a warning message?
  60 **[warning [WARNING] The color depends on the theme. Could look normal too]
  61 What about an error message?
  62 **[error [ERROR] This is not the error you are looking for]
  63 \`\`\`
  64 ```
  65
  66 ### Example
  67
  68 ```
  69 **[terminal]
  70 **[prompt foo@joe]**[path ~]**[delimiter  $ ]**[command ./myscript]
  71 Normal output line. Nothing special here...
  72 But...
  73 You can add some colors. What about a warning message?
  74 **[warning [WARNING] The color depends on the theme. Could look normal too]
  75 What about an error message?
  76 **[error [ERROR] This is not the error you are looking for]
  77 ```
  78
  79 # Documenting Features
  80
  81 If you create a new feature for QMK, create a documentation page for it. It doesn't have to be very long, a few sentances describing your feature and a table listing any relevant keycodes is enough. Here is a basic template:
  82
  83 ```markdown
  84 # My Cool Feature
  85
  86 This page describes my cool feature. You can use my cool feature to make coffee and order cream and sugar to be delivered via drone.
  87
  88 ## My Cool Feature Keycodes
  89
  90 |Long Name|Short Name|Description|
  91 |---------|----------|-----------|
  92 |KC_COFFEE||Make Coffee|
  93 |KC_CREAM||Order Cream|
  94 |KC_SUGAR||Order Sugar|
  95 ```
  96
  97 Place your documentation into `docs/feature_<my_cool_feature>.md`, and add that file to the appropriate place in `docs/_summary.md`. If you have added any keycodes be sure to add them to `docs/keycodes.md` with a link back to your feature page.