emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Emacs raison d'etre


From: Karl Fogel
Subject: Re: GNU Emacs raison d'etre
Date: Wed, 13 May 2020 15:05:29 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]