[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
- RE: (emacs) Intro [was: Making Emacs popular again with a video], (continued)
- Re: (emacs) Intro [was: Making Emacs popular again with a video], Karl Fogel, 2020/05/14
- Re: (emacs) Intro [was: Making Emacs popular again with a video], Richard Stallman, 2020/05/14
- Re: (emacs) Intro [was: Making Emacs popular again with a video], Andreas Röhler, 2020/05/15
- GNU Emacs raison d'etre, excalamus, 2020/05/12
- Re: GNU Emacs raison d'etre, Karl Fogel, 2020/05/13
- RE: GNU Emacs raison d'etre, Drew Adams, 2020/05/13
- Re: GNU Emacs raison d'etre, Andreas Röhler, 2020/05/13
- Re: GNU Emacs raison d'etre,
Karl Fogel <=
- Re: GNU Emacs raison d'etre, Dmitry Gutov, 2020/05/13
- Re: GNU Emacs raison d'etre, Karl Fogel, 2020/05/13
- Re: GNU Emacs raison d'etre, Dmitry Gutov, 2020/05/13
- Re: GNU Emacs raison d'etre, Karl Fogel, 2020/05/14
- RE: GNU Emacs raison d'etre, Drew Adams, 2020/05/14
- Re: GNU Emacs raison d'etre, excalamus, 2020/05/14
- Re: GNU Emacs raison d'etre, Richard Stallman, 2020/05/14
- Re: GNU Emacs raison d'etre, Karl Fogel, 2020/05/15
- Re: GNU Emacs raison d'etre, Arthur Miller, 2020/05/15
- Re: GNU Emacs raison d'etre, Dmitry Gutov, 2020/05/15