@david_chisnall @webbop or in other words: there's a lot to be said for designing for extensibility, but it's an order of magnitude harder design, implementation, and support task, and so outright impossible for someone for whom the base application stretches their skill and experience to the limit

open interchange formats are still very hard in many of the same ways, but not quite as hellishly difficult

@paninid stale documentation is still better than blatantly wrong documentation that looks correct on the outside but teaches concepts wrong.

I tried letting an LLM summarize a programming book I wrote. It looked surprisingly good, until it was just plain wrong.
@MisuseCase @dashdsrdash @tante

@wolf480pl That may be why Stackoverflow worked so well.

Until its community got devastated by AI.

@MisuseCase @dashdsrdash @tante

@wolf480pl @dashdsrdash @ArneBab A few years ago I was responsible for ensuring security compliance for components of a large project. Doing this work required reviewing documentation of the components. I found that while all the documentation followed a common format, parts were often hastily copy-pasted or entered, and sometimes they were out of date.

/1

@wolf480pl @dashdsrdash @ArneBab I would have to chase down someone on the team responsible for the component to get missing/current information. Sometimes the documentation about who was responsible for a component was out of date too, and the person I tried to reach was gone.

When I chased someone down for details about their project they sometimes asked me why Thing A had to be in the documentation anyway, didn’t everyone know Thing A worked like this?

/2

@wolf480pl @dashdsrdash @ArneBab I would remind them that the project was a few years old and very large, different people were coming on board or leaving all the time, requirements had changed, and teams working on different things often didn’t talk directly to each other. So when documenting your feature you cannot assume prior knowledge and you need to be explicit about even the “obvious” stuff.

/3

@wolf480pl @dashdsrdash @ArneBab Good documentation is a skill you can learn but it often involves questioning your assumptions and thinking about people outside of yourself and your immediate team. Many people (not just computer people) have a difficult time with that and even find it emotionally uncomfortable.

/end

@isaackuo

... and as we are in space where language means things, using imprecise language like describing software as intuitive or instinctual is bad; we're not marketers here.

Uses CUA: good.

Obeys Apple Human Interface Guidelines (pick a version that wasn't completely broken: good.

"Extensively tested and revised by actual UX experts with many different users of varying experience": extremely good. And rare.

@MisuseCase @ArneBab @tante

@isaackuo there is software that is easy to understand and efficient to use.

Usually because it uses similar patterns of interaction throughout the software, gives perceptible hints for next actions, and enables combining learnt patterns.

That’s what UX designers do, and it makes a huge difference. For the command line, it’s API design, a part of language design.

Look at game design for possible paths to take.

@dashdsrdash @MisuseCase @tante