That list involves such constraints on programs as to dramatically reduce their utility and generality.
The emphasis on visual input also runs into a very early problem: What about the blind? What about the deaf (audio UI no longer an option)?
Communicating visual analogies with either of those senses is pretty crapshoot. With neither it's worse.
So constraining program function to the capabilities naturally expressible in sight alone doesn't work.
Logical hierarchies (and graphs, or interconnected paths if one prefers) are fine though. [transient.el](https://github.com/magit/transient) is popular for a reason and actively considers accessibility. (Hydra to an extent could do similar but wasn't quite as good.)
Those run into a contradiction between "no modals" and "communicate state", incidentally. Menus and decision trees are stateful and arguably modal in presentation.
[Hierarchy](https://github.com/DamienCassou/hierarchy) is apparently a built-in now, too.
Deep hierarchies & menu-hell is user-alienating though. Doesn't matter how good you make the menu experience, at some point it ends up a problem.
Undoable state changes is an interesting one. It also runs into an interesting problem with most modern filesystems: They are no longer versioned or explicitly transactional, nor do they keep a transaction log. There *have* been filesystems with some or all of these features before. This should be fixed.
Word order shenanigans don't work across languages, some allow arbitrary reordering based on things like prioritization.
Dynamic rediscoverability is a good workaround for memorization.
> it’s very appropriate, since the command as a concept is built around the technological limits of floppy disks, limits that are comically irrelevant in the 21st century.drag your app out of the 1980s and implement autosave and version control already.
Funny thing about that, we do not have some of the system persistence & durability features some (expensive) systems had back then (or which were otherwise known in research but not implemented). Perhaps we should catch up to what was actually possible in the 80s first? Because we're largely stuck in 60~70s cheapest design and it shows.
#26 fails with even just pen & paper. A sufficiently malicious user will find a way. You can refuse to proactively assist in malicious uses, you can hinder them, but you simply cannot prevent them from a sufficiently motivated user.
---
Okay, there are *way* too many appends that have not involved redaction of prior points to account for them, which results in annoying inconsistencies and contradictions.
I will not account for those as a general rule. Perhaps I sometimes will though.
My attention is flagging as well.
---
> A user with a wrong mental model making an inaccurate prediction leads to user frustration.
Wireguard is pretty annoying about this and what it chooses to expose or not. The workarounds I have to do are very silly and wouldn't needed if it exposed internal state.
Color and other texture differences can affect readability positively or negative as well.
Literally just permit user customization & reprogramming.
Yes, filenames are a problem. Filesystems in general suck. This is a structured input/output, UI and communication problem as well as a more [general design problem](https://hidamari.apartments/objects/7b242044-3cc4-4447-991b-58accb1fb61e) with implications.
An object graph with discoverability, capabilities & garbage collection would solve a lot of the issues files have.
Unpredictable moving elements that are interactive are awful, yes.
Forcing users in recipes/cookbooks is not okay either. Suggestions are fine.
Yes, plan for failure. Especially failure beyond the user's control. Assumptions of infrastructural privilege have no place in a reliable program.
You don't have to just hear text. [Auditory icons & fonts](https://www.w3.org/press-releases/1998/css2/) are a [thing](https://www.w3.org/TR/CSS-access/). Thanks [Emacspeak](https://emacspeak.sourceforge.net/) for the info. Semantic & logical content does *not* have to map one-to-one with presentation. This is another reason hypertext is superior to "plain" text.
Yeah, low odds != impossibility. This comes back to prior mention of planning for failure. Unfortunately it can't always be addressed. A program can't do all that much about the system's lack of ECC memory. The kernel/VM can do some, but ultimately if [the system is physical broken/faulty](https://www.realworldtech.com/forum/?threadid=198497&curpostid=198647), it is what it is.
App nagging is (proprietary) malware-pusher behavior and [rests on malicious laws](https://www.eff.org/deeplinks/2019/06/felony-contempt-business-model-lexmarks-anti-competitive-legacy).
[SaaSS](https://www.gnu.org/philosophy/who-does-that-server-really-serve.html.en) is also typically (proprietary) malware.
Yes, hardware privilege is an assumption to remove too. Assume the worst.
SMS is not adequate secure for one-time codes anyway. For all their [(deservedly) abysmal reputation](https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology#Controversy_regarding_NIST_standard_SP_800-90), NIST are [right about that](https://pages.nist.gov/800-63-3/sp800-63b.html#5132-out-of-band-verifiers).
Relying on it is not resilient to failure and is engineering further failure.
