[Arcana] More Emacs love.

Karl Fogel kfogel at red-bean.com
Sat Jul 28 15:32:35 CDT 2012

Jim Blandy <jimb at red-bean.com> writes:
>You're not straw-manning here? Fine, so imagine we're talking to a
>great UI designer, who gets Emacs.
>We have experience *using* interfaces, but much less experience
>*designing* them. Users always feel boxed in where good designers see

<Warning: some serious ranting below>

That would be part of the definition of a good designer, sure.  But
frequently, I'm watching someone use a program and I see options where
the designer of that program either did not, or did not bother to
implement them.

Doesn't that happen to you too?  On your Android devices?

Like, *all the time*? :-)

Here's one: if you type "i" in a default Android text entry keyboard for
text messages, it'll offer you "I" as an option up in that top row of
quick selections.  But it doesn't offer "I'd", "I'll", "I'm", etc.  In
fact, it has just empty space where it could put those options.  Now,
it'll show those options once I hit apostrophe myself, but by then it's
too late -- it's the process of getting to apostrophe that's expensive
in the first place, because that character is on one of the alternate
keyboards you have to flip to first!

I, the allegedly inexperienced UI designer :-), see the principle here,
which is that (in lieu of a blank completion row!) you should offer
users quick routes to options that would otherwise be expensive to get
to, and that that expense calculation should be factored in along with
the likelihood of the option.  Perhaps "is" is somewhat more common than
"I'm", but it's also a lot easier to enter anyway, so if you don't have
room for both options, it might actually make sense to offer "I'm"
instead of "is".  (As it happens, there's room for both and they're just
wasting all that blank space, but you see the principle I'm getting at.)

This has been true through several Android upgrades.

So no, I don't have a lot of faith in someone just because they call
themselves a "UI designer".  When they show me they're really thinking
about the problem, I'll listen, but my faith in the label itself has
been pretty thoroughly eroded.

By the way, I design lots of UI -- for myself and users like me -- and I
think you do too.  My UIs are pretty good for that small set of users;
the ones of yours that I've used, I've liked.  Are sure you're not
selling yourself short?

>Why the emphasis on discoverability? I wanted your smart-transpose
>feature in my own Emacs, built-in, but I know Emacs has so much
>wonderful stuff already that I don't know about that I knew that if
>your stuff had gone in upstream, I still wouldn't have known about it.

(Yeah, I'm pretty sure I'm not straw-manning.  Many -- though certainly
not all -- UI designers I talk to make me think of the practice of
medicine in the sixteenth century.  Thanks to those UI designers, the
rest of the world didn't have completion and incremental search until
years after we had it.)

So, this was sort of what happened to me in the case of my custom code.
Had I known about flyspell -- which wasn't "discoverable" to me mainly
because I had an idiolectic understanding of the word "spell" -- I
probably would never have written the custom code.  Having written it,
however, I found it better tuned to my use case than flyspell is, which
isn't so surprising I guess.

I agree discoverability is a problem in Emacs.  I don't know of any
program that has solved that problem.  It may be that it's possible to
solve, but I admit I'm skeptical.  Basically, you have a ton of features
that are reachable via a keyboard interface.  So they're not visually
apparent.  If they *were* visually apparent, they'd either crowd the
screen (bad for obvious reasons), or be nested way way down in levels of
menu (where, in fact, they are right now, if you have menus turned on in
Emacs, which I don't).  Or... or what?  Suggest themselves every so
often, via a talking paper clip?  There are only a few sensory avenues
available here, and the brain can only tolerate a certain level of
information density per square inch (hence I'm skeptical about
translucent help floating behind my text).

Emacs and similar programs have gone full tilt in taking advantage of
human kinesthetic memory.  It works great for users who practice and
make the investment; for those who don't, it's awful.

Users who learn the documentation system -- M-x apropos, Info, etc --
and do deliberate searches for what they need are usually rewarded.  In
the case of flyspell, IMHO the documentation is very badly organized
[1], which is just a bug, but that doesn't in itself invalidate the UI
principle that users who are willing to make high investments do better
with a different kind of interface than ones who aren't.

If that sounds like some kind of claim of superiority, it's certainly
not.  In most systems I use, I'm a newbie, and I'm grateful that the
system is oriented toward newbies.  As I become expert in some of them,
I grow to resent the newbie orientation, because it makes it harder to
use the program as an expert (see: CiviCRM).


[1] See "16 Commands for Fixing Typos", which separates transposition-
    fixing commands from spelling-fixing commands, even though much of
    what the latter does is really the former, since the user didn't
    make a spelling error per se.  The word "typo" does not appear in
    the flyspell section of the docs at all.

More information about the Arcana mailing list