Tamiya model building manuals are the gold standard of accessibility and have been so for 30+ years. They don't even require spoken or written language to understand.

Examples:

- https://www.rcscrapyard.net/manuals/tamiya/ta01/ta01-08.jpg

- https://randrhotels.com/images/198187.jpg

Few instruction manuals are as effectively designed as the Tigerfibel, designed for the crew of the Tiger tank.

https://en.m.wikipedia.org/wiki/Tigerfibel

From the Wiki..

Like other manuals designated as Fibel (basic primer), they summarised what the crew needed to know for day-to-day use of the tank, but unlike the typical tedious style of a German tank manual of that period, it is well illustrated in a comic style and much of the text is written as humorous poetry.

The author's knew their audience, with plentiful use of scantily clad ladies.

Will Eisner and his studio made some US equivalents, which were similarly easy on the eyes.

Motto: If you'd like that Joe remembers, draw a damsel's unclothed members

  Bei der Kaserne
  Vor dem grossen Tor
  Steht ′ne Laterne
  Und steht sie noch davor

p 50 of the Tiger-Fibel shows how "swiping right" worked in the 1930s, with an upper right corner drawing of the table telephones from the "Femina Palast" Berlin nightclub.

https://archive.org/details/Der-Generalinspekteur-der-Panzer...

(it's in the radio/intercomm section, so it looks like tech manuals going ahead and duzing the reader are nothing new?)

I love User Guides/Reference Manuals (perhaps i am showing my age here). They are a must with every product however "user friendly" its designers may think it is.

Anybody who has dealt with teaching "How to use a Smartphone/Tablet" to the elderly understands the frustration of not having a proper guide to give them to read slowly and absorb. The so-called "obvious user-friendly UI" is anything but. There are so many random gestures dependent on context that even i (a tech-knowledgeable person) find them hard to remember and use correctly as needed. Given that a smartphone is now indispensable for everyday work, it is almost criminal to not provide a user guide to the elderly who most need it.

I wonder if someone could nake an LLM that takes Chinese manuals, YouTube how-tos, and instructibles web pages, then outputs fun to read manuals in English?

They could charge by the manual to create manuals for resellers.

Someone in IT should do the same but specifically for printers.

You might want to bookmark this: https://www.badcaps.net/ Functional & Free.

Checking it out...thank you so much

Ah, I miss the Haynes books so damn much. Disclaimer: maintenance documentation is more or less what pays (most of) my checks.

You got a few different things here that interact in weird ways when you're making books about taking things apart and putting them back together:

1) Different configurations of the thing you're taking apart - when does a "configuration" become a wholly different thing? This is something that's still not been quantitatively handled, crazy as it sounds. We have the tech, but no one thinks it's worth buying into, because there's so much money riding on the customer thinking that the product variants are more similar than they actually are.

2) What's the logical disassembly? Does the air cleaner come off before the brake fluid reservoir? Wait, the variant with the fuel injector doesn't have the air cleaner . . so maybe don't combine the airbox and brake reservoir into a single assembly for this. ETC ETC.

3) Functional systems like wiring, hydraulics - where do those go? Do you group procedures by functional system, or by disassembly order? Also: who determines what a "function" is?

And of course on top of this you have integrations - do you want the handbook to "talk" to the CAD/CAM system? Wait, do you want the parts lists to come from somewhere else? Who's checking to make sure the CAD matches the PDM? And on and on and on and on. It's all good fun.

Also, speaking to the original article: XML-based publishing systems are not the be-all-end-all of pubs solutions; by and large, they're a gigantic tar baby for a publications department. Now, I'm not saying that systems using XML can't be pretty neat, by integrating with CAD/PDM/ERP, but that doesn't really have anything to do with XML. In fact, intensively granular XML formats - S1000D, iSpec2XXX and MIL-STD-40051 come to mind at once - don't do a whole lot more other than lock down content to a single software vendor in a single manufacturer for just the staff of the publications department. All of the good stuff from those specs are things that shouldn't live in a document format - they should be integrated from CM, ILS/IPS, SE, ERP, and PDM. The XML itself is entirely irrelevant, and by overspecializing the schema it guarantees that each instance is going to be bespoke to every single vendor/customer/program/project. Nothing XML does can't be done in Asciidoc, for much less money, with much less work, on a generic compute platform, and using a format that can be reviewed by any jerk with a good modern text editor.