documentation.rst 2.9 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192
  1. Writing Documentation
  2. ---------------------
  3. This section provide information about writing documentation for
  4. JupyterLab.
  5. Writing Style
  6. ~~~~~~~~~~~~~
  7. - The documentation should be written in the second person, referring
  8. to the reader as "you" and not using the first person plural "we."
  9. The author of the documentation is not sitting next to the user, so
  10. using "we" can lead to frustration when things don't work as
  11. expected.
  12. - Avoid words that trivialize using JupyterLab such as "simply" or
  13. "just." Tasks that developers find simple or easy may not be for
  14. users.
  15. - Write in the active tense, so "drag the notebook cells..." rather
  16. than "notebook cells can be dragged..."
  17. - The beginning of each section should begin with a short (1-2
  18. sentence) high-level description of the topic, feature or component.
  19. Proper Nouns
  20. ~~~~~~~~~~~~
  21. The main parts of JupyterLab should be treated as proper nouns and
  22. capitalized:
  23. - Main Menu
  24. - Left Panel
  25. - Dock Panel
  26. - File Browser
  27. - Command Palette
  28. - Running List
  29. - Tabs List
  30. - Notebook
  31. - Code Console
  32. - Terminal
  33. Keyboard Shortcuts
  34. ~~~~~~~~~~~~~~~~~~
  35. Typeset keyboard shortcuts as follows:
  36. - Monospace typeface, with no spaces between individual keys:
  37. ``Shift Enter``.
  38. - For modifiers, use the platform independent word describing key:
  39. ``Shift``.
  40. - For the ``Accel`` key use the phrase: ``Command/Ctrl``.
  41. - Don’t use platform specific icons for modifier keys, as they are
  42. difficult to display in a platform specific way on Sphinx/RTD.
  43. Screenshots and Animations
  44. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  45. Our documentation should contain screenshots and animations that
  46. illustrate and demonstrate the software. Here are some guidelines for
  47. preparing them:
  48. - Take screenshots and animations at the standard browser font sizes,
  49. 100% browser zoom.
  50. - It is often helpful to have a colored background to highlight the
  51. content of an animation or screenshot. If a colored background is
  52. needed, use Material Design Grey 500 (``#9e9e9e``).
  53. - Screenshots and animations should be styled in the documentation with
  54. a ``max-width: 100%`` property. Never stretch them wider than the
  55. original.
  56. - Screenshots and animations taken on high resolution screens (retina)
  57. may need to be saved at half resolution to be consistent.
  58. - Screenshots or animations should be proceeded by a sentence
  59. describing the content, such as "To open a file, double-click on its
  60. name in the File Browser:".
  61. - Ideally each screenshot or animation should have a drop shadow, but
  62. it is unclear if we should do that beforehand or in CSS (the xkcd
  63. extension tutorial has images with shadowns already - let's think
  64. through this.)
  65. To help us organize them, let's name the files like this:
  66. ::
  67. sourcefile.md
  68. sourcefile_filebrowser.png
  69. sourcefile_editmenu.png
  70. This will help us track the images next to the content they are used
  71. in.