If you’re that keen on business books, I have one that you might enjoy: https://www.sallery.co.uk/lessons. I’ve tried to avoid some of the pitfalls listed in the article, but feedback from someone with broad knowledge of the genre would be most welcome!
I’m somewhat surprised that the article doesn’t mention Robert Winter’s “The Interactive Beethoven”. I kept an old ThinkPad running for a long time after it should have been obsoleted, just so that I could spin up that disc. Amazing sound quality, great use of hypermedia… a real CD-ROM showpiece.
I went on an architectural tour of the Barbican Centre a few years ago - it was great, highly recommended (particularly if you're a fan of Brutalism, an under-appreciated style). Anyway, the (excellent) tour guide explained the reason that the development has the 3-4k population mentioned above. Apparently the destruction of housing stock caused by WWII bombing of the City was such that the population no longer justified the appointment of an MP. The Corporation of London weren't willing to lose their representation, and so immediately decided to rebuild precisely enough accommodation to be entitled to an MP - hence the entire Barbican development.
I've no idea whether that's true, but it fits in with the general opaque feudality that is the City.
Also: if faced with a zombie apocalypse, the Barbican would be a very good place to hold out. Good sight lines, few street-level entrances, a surprisingly large network of tunnels and the largest greenhouse outside of Kew... perfect!
Diagrams are good for representing structure, and inherently less good at representing behaviour (as mentioned in the article). I recall that in the early 2000s some UML tool venders were pushing "round-trip automation" as a way of tackling this problem; basically you'd model your business domain with some class diagrams, generate some boilerplate code, write code for the actual behaviour and then the tool would magically suck all the behaviour logic back into the diagram. It sort of worked, for a couple of passes, until the tool failed to capture the precise semantics of some perfectly valid code (which was probably inevitable).
I'm hoping that the (somewhat-fine) distinction between no-code and low-code is made with the same problems in mind, that is, an acknowledgement that code is quite often the best way of expressing the behaviour of a system.
There's a place for UML in the README.md; as some other commenters have pointed out, UML works much better as a sketching tool than as a total definition of a software system. A couple of quick class diagrams at the top level (probably generated using something like https://plantuml.com/) might provide a better communication model than text.