From db6f638547947f73f0671259c1bb25cc1f9c20f2 Mon Sep 17 00:00:00 2001 From: km0 Date: Thu, 13 Apr 2023 15:30:42 +0200 Subject: [PATCH] entry points --- chapters/01_entry_points.md | 8 +++----- notes.md | 1 + 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/chapters/01_entry_points.md b/chapters/01_entry_points.md index 4faf223..a5baad7 100644 --- a/chapters/01_entry_points.md +++ b/chapters/01_entry_points.md @@ -121,8 +121,6 @@ Documentation is a surface where all the sociality, relations, and context aroun A surface that in turn can be activated and used as a platform to reach all the different actors surrounding it. - - ### Getting startled Reading undocumented code feels like being an ant walking on a big painting. You can see the strokes of a brush and have an intuition of their direction, but what's missing is an overall idea of how the composition flows. Documentation provides guidance through the bunch of functions and statements that makes software, a bird's eye perspective. It is often the first thing one gets across when approaching a new library or programming language, and it shapes the way a developer thinks about particular piece of code. @@ -149,10 +147,10 @@ The devil is in the details, and software as well: the translation between human Documentation is not just for beginners: it's a code companion. One never stops reading. Even experienced programmers must refer to docs when first encountering a software, and return to the references when they need a refresher on the syntax of a particular command. They continuously look at code from multiple distances: close to the source code through lines of comment—ignored by the machine, but much appreciated by fellows developers—or from printed books, along with pages of explanations and use cases. -This tentacular surface can reach a programmer in different moment of their life: from the _hello world_ to the _how to uninstall_. This is possible thanks to the multitude of shapes documentation can take: video tutorials and commands cheatsheets, _README_ files and complete guides featuring colored images. Daniele Procida proposes a systematic approach to organize this wealth of formats (Procida, 2017). His framework focuses on the needs of different kinds of readers: by leveraging between practical steps and theoretical knowledge, it charts four main modes of technical writing. Each format comes with its own approach and intentions, and in response to different questions. - ![Diagram with four quadrants: the horizontal axys is from study to work, the vertical from theorical to practical. In the four quadrants tutorials, how to guides, reference, explanation. Bonus: two kokaburras](../img/diataxis.jpg "Diagram with the Diataxis framework") +This tentacular surface can reach a programmer in different moment of their life: from the _hello world_ to the _how to uninstall_. This is possible thanks to the multitude of shapes documentation can take: video tutorials and commands cheatsheets, _README_ files and complete guides featuring colored images. Daniele Procida proposes a systematic approach to organize this wealth of formats (Procida, 2017). His framework focuses on the needs of different kinds of readers: by leveraging between practical steps and theoretical knowledge, it charts four main modes of technical writing. Each format comes with its own approach and intentions, and in response to different questions. + A text that fails to address who's reading can result inaccessible and frustrating. Although the Diataxis framework doesn't encompass every particular situation, its structure offers good aid to situate documentation within different perspectives. This turns out to be really helpful in the process of writing, as a way to fine tune tones, and modulate the nature of shared info. _Tutorials_ offer entry points for the newcomers, while _explanations_ unveal core mechanisms for more navigated readers. _How-to guides_ teach how to get the work done, while _references_ report lists of information ready to be consulted. Different documentations for different readers for the same code. -!!! note "to backdoors!" +Or rather, the same documentation, for the same reader, for the same code, just at different moments in their life. Programmers' needs gradually change, as well as the answers they are looking for, but still, they keep returning to read the docs. diff --git a/notes.md b/notes.md index 55504b6..063e00f 100644 --- a/notes.md +++ b/notes.md @@ -7,6 +7,7 @@ [x] and maybe connect it to aesthetic programming [ ] outro code companion wrap up [ ] context soupboat [could be in the appendix?] +[ ] outro