[Top][All Lists]

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

Re: Emacs completion matches selection UI

From: Stephen J. Turnbull
Subject: Re: Emacs completion matches selection UI
Date: Fri, 20 Dec 2013 10:17:54 +0900

Ted Zlatanov writes:
 > On Wed, 18 Dec 2013 22:40:39 -0500 Stefan Monnier <address@hidden> wrote: 
 > >> If theres another point to this debate, please forgive me, because
 > >> I have missed it.
 > SM> Personally, I'm trying to understand what it is that Ted is suggesting.
 > I've explained it so many times I'm starting to wonder if my English is
 > the problem.

It is.  Or more precisely, your abuse of Emacs technical terms.  Cf
the discussion of "special text buffer".

 > should be going in graphical mode, and if *Completions* stays it should
 > be only in text-mode.

There you go again.  *Completions* is a *buffer*, and does not imply
any particular display.

 > Perhaps you can look at the URL and explore all the options and use
 > cases offered by the jQuery UI autocomplete widget instead of assuming
 > my goal is to traumatize you with shiny things.

There you go again.

 > The jQuery UI library didn't become a de facto standard by
 > accident, it really is a good API.

For many people, especially those for whom a computer needs to be
white goods like a washing machine or toaster with one start button.
We *know* Emacs users are in general not members of that group.

That doesn't mean it's not good for Emacs users too, although I know
one Emacs user very well who ignores it when present because it
doesn't do a damn thing to float his boat in his workflows.  But
"became a standard in that world" is simply not appropriate logic for
bringing it (or similar) into Emacs.  At least, it never was in the
past.  "Try it, you'll like it" is a risky strategy, too.  Some people
won't, and if they're decision-makers you need to appeal to, well,
"sayonara, baby!"

 > Yes.  Most of us are terrible at detecting bad UI in the tools we use
 > every day, and pretending otherwise is disingenuous.

I believe that Emacs users are *much less likely* to be members of the
the "most of us" you describe here, and that they use Emacs as much
for the power implied by the ability to hack your UI as for the power
inherent in the ability to hack apps using powerful APIs.

I've watched Windows power users at work to see *how* they do it, and
I have to admit that their behavior is clearly more efficient than
mine in Mac OS X.  The difference is that they all paid $500 to $1000
for various amounts of training in Windows use, and I'm self-taught.
The point is that the Windows UI is *not* inefficient in itself, but
it's tuned for a certain type of user, it's not actually horrible for
newbies, and it's pretty bad on the discoverability feature.

What you haven't addressed is why the UIs you suggest are appropriate
to Emacs use.  One size does not fit all apps, and one size does not
fit all users.

 > I think you've described (except for the tag cloud, which IMO is a
 > horrible user experience)

I agree, in general.  But here the filters will be the same ones used
already, which all agree are pretty good, whereas I find tag cloud
filters to pretty much suck (I know how to type "US" and "China"
quickly, I don't need those two tags to take up 55% of the display,
thank you very much /Economist of London/).  Perhaps more important to
evaluating my suggestion, the "tag cloud"-style UI is a *proposed*
design targeted at *specific* consoles with *inaccurate* pointing

reply via email to

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