From: "Robert J. Chassell" <bob@rattlesnake.com>
Subject: Re: [usability] mouse-1 for performing actions?
Date: Fri, 24 May 2002 20:16:12 +0000 (UTC) [thread overview]
Message-ID: <m17BLTw-000If6C@localhost> (raw)
In-Reply-To: <ilur8k1l8g1.fsf@latte.josefsson.org> (message from Simon Josefsson on Fri, 24 May 2002 20:14:22 +0200)
> ... a slow connection (perhaps 1200 baud; traceroute
> indicated some sort of trouble in Newark, NJ) to a third machine,
> using Emacs without a mouse.)
Congratulations. :-) I would call such an environment unusable from a
usability point of view.
Many programs are no good at all for remote operations on a slow
connection.
QWEST had some sort of trouble in New Jersey and does not properly
re-route packets the way the Internet was originally designed. I had
to create a different route in order to get hold of my email. I
agree, a slow connection makes for a poor interface, but fortunately,
with Emacs, it is basically the same interface I always use, only
slower.
The point of this is that a good user interface takes into account not
only good circumstances, such as I am enjoying as I type these words,
but other circumstances as well, such as remote connections over poor
lines, or being without a mouse on a laptop, or being situationally
blind, as in a car, listening to email.
In many ways, designing for varied conditions is the same as designing
for varied users: on the one hand, the goal is to design an interface
that works when you lose speed, a mouse, and a meta key. On the other
hand, the goal is to design an interface that novices can not only use
readily (for which I think menus and arrow keys are fine) but, at the
same time, that novices can learn to work more efficiently than is
possible with menus and arrow keys.
(Your descriptions of GNOME and KDE suggests to me that their
interfaces are designed for people who are novices and who are not
expected to learn to become more efficient; I don't whether this is
true.)
Moreover, designing for varied users includes designing an interface
that can be modified for people who type whole sentences or paragraphs
before editing them (Viper mode) as well as being designed for people
who edit each word or clause (Emacs in general).
The question is what defaults are suitable?
As a rule of thumb, for example, Emacs is oriented towards people who
edit as they go along, rather than write for a while and then edit, as
vi users do. (For someone who edits as they go along, the shift in vi
from insert mode to edit mode and back requires too many keystrokes;
for someone who goes into edit mode once a paragraph, the shift is
hardly noticeable.)
Similarly, Emacs is oriented towards people who prefer to cut, copy,
and paste rather than type, and who operate on 50 or more different
buffers at one time. Emacs is oriented towards people who navigate by
doing incremental searches, since that is easy, quick, and intuitive.
It is less intuitive and efficent to make nonincremental searches, so
the default Emacs keybinding has an extra character in it.
(The Edit menu provides a string search that is easy for novices and,
being in a menu, is intrinsically slow. The menu also provides
incremental search, but it goes without saying that no one in their
right minds will use incremental search off a menu more than the once
or twice it takes to learn, since that interface is so slow and
inefficent.)
Ok, I'm probably not a typical Emacs user, since I use Gnus more than
the regular Emacs user. And Gnus, like most interactive Emacs modes,
makes heavy use of buttons and hyperlinks where mouse-2 is quite
tricky to use.
That is weird: I have used Gnus without the mouse. And I am using
mail mode now. Often, I use text, Texinfo, and Emacs Lisp mode
frequently. All of these are interactive. None of these make much
use of buttons or hyperlinks. I use the mouse to move point to a
non-near random location and to mark regions that commands like `M-h'
don't handle.
Only in read-only buffers do I use the mouse much for clicking on
buttons, and that only when that is efficient. (In the RMAIL-summary
buffer, for example, I tend to use the `d' and `n' keys alot. I know
I can mouse click on a line and do sometimes, but that is infrequent
compared to the number of times I press the `d' and `n' keys.)
Obviously, a mouse is useful in some circumstances. I am not saying
that one should not use a mouse; I use one when able. I am being
puzzled at the degree you use the mouse for things other than marking
and copying regions text or for changing the location of point.
... heavy use of buttons and hyperlinks where mouse-2 is quite
tricky to use.
How is the use of mouse-2 trickier than the use of mouse-1 or mouse-3?
--
Robert J. Chassell bob@rattlesnake.com
Rattlesnake Enterprises http://www.rattlesnake.com
next prev parent reply other threads:[~2002-05-24 20:16 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-20 19:36 [usability] mouse-1 for performing actions? Simon Josefsson
2002-05-21 15:57 ` Richard Stallman
2002-05-21 20:05 ` Stefan Monnier
2002-05-21 15:58 ` Robert J. Chassell
2002-05-21 17:43 ` Simon Josefsson
2002-05-21 19:48 ` Robert J. Chassell
2002-05-21 21:07 ` Simon Josefsson
2002-05-22 1:09 ` Karl Eichwalder
2002-05-22 3:10 ` Miles Bader
2002-05-22 5:09 ` Karl Eichwalder
2002-05-22 15:19 ` Kai Großjohann
2002-05-22 9:10 ` Kai Großjohann
2002-05-22 9:15 ` Miles Bader
2002-05-22 9:53 ` Kai Großjohann
2002-05-24 0:43 ` Richard Stallman
2002-05-24 16:02 ` Karl Eichwalder
2002-05-24 16:23 ` Kai Großjohann
2002-05-24 16:34 ` Simon Josefsson
2002-05-24 17:49 ` Robert J. Chassell
2002-05-24 18:14 ` Simon Josefsson
2002-05-24 20:16 ` Robert J. Chassell [this message]
2002-05-25 17:19 ` Kai Großjohann
2002-05-25 8:19 ` Eli Zaretskii
2002-05-24 18:58 ` Miles Bader
2002-05-24 19:33 ` Karl Eichwalder
2002-05-24 21:49 ` Robert J. Chassell
2002-05-25 21:20 ` Richard Stallman
2002-05-25 23:05 ` Simon Josefsson
2002-05-26 0:08 ` Miles Bader
2002-05-26 22:25 ` Richard Stallman
2002-05-24 17:33 ` Robert J. Chassell
2002-05-22 15:14 ` Karl Eichwalder
2002-05-21 21:24 ` Francesco Potorti`
2002-05-21 21:35 ` Alan Shutko
2002-05-22 8:46 ` Andreas Schwab
2002-05-22 10:33 ` Francesco Potorti`
2002-05-22 20:58 ` Andreas Schwab
2002-05-22 21:07 ` Francesco Potorti`
2002-05-22 21:21 ` Andreas Schwab
2002-05-24 0:42 ` Richard Stallman
2002-05-24 8:09 ` Francesco Potorti`
2002-05-24 9:59 ` Simon Josefsson
2002-05-22 8:44 ` Kai Großjohann
2002-06-05 15:50 ` Stephen Berman
2002-05-22 22:28 ` Richard Stallman
2002-05-22 1:29 ` Miles Bader
2002-05-24 0:42 ` Richard Stallman
2002-05-22 22:28 ` Richard Stallman
2002-05-23 1:14 ` Miles Bader
2002-05-24 21:12 ` Richard Stallman
2002-05-25 1:27 ` Miles Bader
2002-05-25 8:32 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m17BLTw-000If6C@localhost \
--to=bob@rattlesnake.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).