I don't care if x11/xorg is too much hassle for your liking. You're entitled to your opinion. But I do take offense to the example you used:

"It took my mother years to understand *email*."



That's because she was instructed merely in use of the interface, not the underlying concepts. If an "email consortium" existed like IEEE or IANA for their respective subjects, they wouldn't explain email to my mother the way I did, with a tour of a particular email client app or webmail app. But, she and I both wanted to just get her message sent, to accomplish the immediate goal and get on with life, simply and easily. Sound familiar?

Quality instruction would have required that I told her about the protocols, headers, and addressing rules before mentioning the existence of email clients. Then, she could have sat down in front of emacs or Outlook and, with equal ease, quickly figured out for herself how either platform performs the functions universal to "email", because she understands the essentials of how the programs work -- or, if you prefer, what they really do. It's a bit of both.

Instead, we "teach" non-programmers (especially personal acquaintances who are not enrolled in a formal, costly class) by taking them on a tour of the menus of whatever program has been bestowed upon them by circumstance, then leave them alone. This is what my friends and family want, generally, but it isn't what's best for them. More important, it isn't what's best for me. They just make more trouble to call me about later that way.

Is it the same with you? Did your mother take "years to understand *email," beginning with a tutorial in the use of whatever client was provided by her ISP? Then, she changed ISP, or for whatever reason switched to a new email client, and had to "learn all over". After 3 or 4 of these changes, she noticed that elements like send/reply all/forward/reply, To:/From:/Cc:/Bcc: are fairly ubiquitous, as are username & password, and she hypothesizes as to which consistencies are neither coincidence nor shared artistic vision of the app/page designers, and deduced that the remainder of those commonalities are necessitated by what email "really is", and thus, after *years*, understands email.

It's actually a testament to human intelligence that anybody instructed as an "end user" of software ever learns any of it, as they all have to put together all the underlying theory we could have explained to them in the first place, saving all parties several tutorials on use of specific apps, none of which added anything to the user experience, nor, I'll warrant, to familial bonds.

I think the programming paradigm needs an overhaul, starting with the assumption that average users can't understand it.

Drawing conclusions on end-users' ability to learn from Linux documentation leads to spurious deductions, because their intended audience already knows the background information, or is strongly motivated to learn it. If you're not willing to learn xorg/x11, maybe Linux is not for you, or if it is you just need to check the compatibility of the hardware you intend to use, a little more carefully than under your current enabler. Anyway, nobody said that would be easy.

Good documentation, an example of which might be an email client at my college back when email was not a common household appliance, would explain more than just what happens on the screen with various menu selections. It would describe what's happening to the data, and give the user an appreciation of why the program design is good -- or why it isn't! That may be part of why good software documentation can't be bought. Some is available for free though. Squid, for example, is a breeze to setup using only its .conf file, which is well commented. I'd wager even your mother could understand it.

# for now