Re: GNU Emacs raison d'etre

[Andreas Röhler]

On 13.05.20 22:05, Karl Fogel wrote:
> On 13 May 2020, Andreas Röhler wrote:
> > Agree with everything beside two last paragraphs. Enjoying the
> > possibilities to extend and assisting new users being productive seems
> > no contradiction. May you give an example where an smooth entrance
> > hinders the power of more complex functionality?
> The newcomer-vs-expert tradeoff is real, and it's pervasive throughout UI and 
> UX design.
>
> One example is button-based functionality.  For both experts and newcomers, 
> those buttons/icons take away screen real estate -- but for newcomers they make 
> features easier to find, so it's worth it.  For experts, they *just* take away 
> screen real estate, while providing little or no benefit.
>
> Use of small symbols to indicate state in the modeline is another area.  Experienced users know 
> what "**" in the mode line means, what "%" means, etc.  Newcomers are 
> frequently confused by the mode line; it is noise to them, until they know how to interpret it -- 
> but that takes a bit of investment.  Now, we could provide bigger, more verbose signs of current 
> state -- but then we'd be taking away screen real estate again.
>
> Another area is the keybinding space and the minibuffer.  Just about every time 
> I have watched a new user use Emacs, I have noticed how frequently they 
> accidentally hit some key combination or sequence and wind up in some weird 
> state that they never meant to be in -- and don't know how to get out of.  
> Often they have minibuffer prompts sitting around all the time, and are unaware 
> that Emacs is asking them for some piece of information (after all, the user 
> didn't mean to put Emacs into that state and has no idea she did so).  But 
> having those keybindings available is *good* for experts, as we know from 
> personal experience.
>
> I could go on.  I've taught many newcomers to Emacs, and often the things that 
> are hardest for them are exactly the things that are *good* for the experienced 
> user.


Okay, thanks for the explanation. So we have two items - the way an 
intro is written and the real-case scenario WRT complexity and action.

For the latter Emacs already provides some caveats - disabling some 
commands at the beginning, which works fine. Your observations WRT 
errors of beginners might be of great value. Is there a way to collect 
these difficulties? Maybe the difference between a beginners state and 
advanced state might be extended?

Having a smooth introduction written by a didactically skilled person is 
another thing. IMHO exists not just a powerful tool but also some 
characteristic difficulties WRT beginners. The reason for the advantage 
as the disadvantage looks as the very same, it's mentioned in the 
founding tale of Emacs: exchanging code between developers.

Thanks all,

Andreas


> These design tradeoffs cannot be avoided.  It would be a fallacy to think that 
> it's always possible to be *both* maximally newcomer-friendly and 
> investor-friendly.
>
> (The term "user-friendly" is itself misleading.  There is no such thing as "a user" in a way that makes the term "user-friendly" 
> meaningful.  Better terms would at least attempt to make important distinctions -- "newcomer-friendly", "expert-friendly", 
> "ADHD-friendly", "limited-movement-friendly", "visually-impaired-friendly", etc -- and would encourage designers to understand 
> that being good in some categories means being bad in others.)
>
> Best regards,
> -Karl