Live data from Hacker News

Diátaxis

diataxis.fr

41–50 of 66 posts

Re: Diátaxis

#41
I've also found these guidelines helpful:

1. In general, do whatever Wikipedia does. e.g., start with a one-sentence definition, then a couple paragraphs of summary, then go into short specified sections, and keep links to the "Citations" at the end. It's been refined for 25 years, it's older than most of your engineers, it's 50+% correct by default.

2. Keep every section to one screenful. If your reader can't see a headline, they get lost.

3. Put a funny picture at the top of the page. Or at least something off Wikimedia Commons.

4. Don't spend a lot of time writing anything. And don't use AI. The AI doesn't know what's inside your head. You yourself have an inkling. The longer you write, the further you'll get. Just write one short thing at a time and refactor aggressively later. Never throw shit over a fence blind. Nobody reads shit that's been flung over a fence.

Steven King said writing is telepathy. All mediated communication sits on a Pareto trade-off with face-to-face communication. Media is always less interactive with slower iterations. You need to figure out exactly what your audience needs, right when they're reading, and write just that, knock 'em dead, and leave. Don't add detail. They'll ask if they need detail.

Re: Diátaxis

#43
I was not familiar with Diataxis, and as I was reading through the webpage, I kept wondering if there were any concrete examples. I love cooking, and it was interesting to see that some of the insights of the whole philosophy used teaching how to cook as an example.

I read a lot of cookbooks, and interestingly enough, I never stopped thinking about what makes a good cookbook (except for its recipes). Diataxis answers that in a way. Indeed, the best cookbooks I have read in some way or another followed Diataxis.

Re: Diátaxis

#44
post #12

We just invested a good amount of time restructuring our docs for Diátaxis. It was helpful, but I wouldn't take it as gospel. The important thing to remember is that each piece of content should be one of the four types. If you're embarking upon a refactoring / rewriting journey for your docs, the only advice I'd share is to actually read the website beginning to end before starting. Especially this page: https://dia…

Ugh, I don't like that page and I have actually deleted it. It'll be gone soon. There is a real problem there, and that page doesn't do a good enough job of dealing with it. I have something cooking that is much, much better.

We're currently in the process of restructuring our documentation and I'd be very interested in an early draft of this, fully understanding that caveat emptor. Is it published anywhere currently?

Re: Diátaxis

#48
post #43

I was not familiar with Diataxis, and as I was reading through the webpage, I kept wondering if there were any concrete examples. I love cooking, and it was interesting to see that some of the insights of the whole philosophy used teaching how to cook as an example. I read a lot of cookbooks, and interestingly enough, I never stopped thinking about what makes a good cookbook (except for its recipes). Diataxis answers…

Much of the Canonical & Ubuntu documentation uses it now. I am not sure which are the best examples though.

https://ubuntu.com/server/docs/

Re: Diátaxis

#49

I love whenever this comes up. It’s a great framework for thinking about and writing docs. It’s hard to keep documentation up to date, however, and I find that items like tutorials and reference materials (unless generated off versioned code) can drift pretty far over time. A feature I like in concept that notion introduced with wikis ages ago was a “verification” timestamp, where you specify a timeframe after which…

I am sure that this exists for other ecosystems as well - rustdoc, Documenter.jl and Sphinx seem to support this - but my experience lies in R: three of the Diátaxis categories map quite nicely onto R package constructs:

- Tutorials are implemented as "vignettes", executed on package validation - How-Tos are attached in roxygen documentation chunks, likewise executable by default - execution disabled when expensive or to avoid side effects. - Reference is implemented in a TeX or Markdown format, commonly parsed by roxygen

The only thing that's missing is a canonical way of documenting implementation rationale. Having the documentation outside the repo worked before LLMs, but there was always that weak point of code drifting away from the documentation...

Re: Diátaxis

#50
I can't help but notice that for a documentation organization framework/method it failed to produce its own good documentation.

There are repetitive bloated texts with unnecessary distractions and unenlightening illustrations. It is maybe well-organized, if one can speak about good organization of poorly expressed knowledge at all.

Post reply on HN