For Programmers: Free Programming Magazines  


Home > Archive > PERL Miscellaneous > June 2007 > Re: The Modernization of Emacs: terminology buffer and keybinding









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: The Modernization of Emacs: terminology buffer and keybinding
Twisted

2007-06-24, 4:10 am

On Jun 23, 10:36 am, Martin Gregorie <mar...@see.sig.for.address>
wrote:
> However, there's a case he missed, probably through never using a CAD
> system. All the good ones can be driven either by mouse, or by
> non-chorded key sequences or any combo the user likes. The essence of
> CAD is very accurate pointing but all too many mice move slightly when
> clicked. Fortunately a decent CAD system offers the possibility of
> purely pointing with the mouse and doing everything else with the other
> hand on the keyboard. The result is both fast and extremely accurate.


Actually, what I prefer in (2D and 3D) visual design apps is the
ability to snap to some kind of grid/existing vertices, and to zoom in
close. Then small imprecisions in mouse movement can be rendered
unimportant.

> An interface design point that nobody has yet mentioned here is that
> there are four different types of user that map onto a grid:
>
> casual dedicated
> untrained 1 2
> expert 3 4
>
> I first ran across grid this in "Design of Man-Computer Dialogs" by
> James Martin and its been very useful in systems interface design.
>
> The problem with almost all current GUIs is that they are aimed at types
> 1 and 3 users - this certainly applies to Windows, OS X and Gnome
> desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed
> at type 3 and 4 users.


The problem of course being the complete exclusion of type 1 users.
Everyone starts out as type 1, and I don't think type 2 occurs in
practise. You'd have to be some kind of religious nut to be
"dedicated" while still "untrained", rather than only as a result of
experience. Apps that provide no traction for a type 1 user will not
see much adoption except in an environment of immersion, mentoring, or
desperation. I wonder which of the three explains the majority of
emacs users, and of vi users, and whether those prove to be the same
one. :) (Actually, there'll be a single or a small number of class-2
users: the original developers, who presumably became dedicated before
having much experience *using* the tool. Their experiences are
atypical however, and their knowledge of the internals probably means
they're type 4 by the time they actually use it to do more than debug
it. Unsurprisingly, never experiencing it as a type 1 themselves they
tend to be inconsiderate of future type 1 users...this is normal, and
requires effort to avoid, in much the way blinkered views of stuff and
seeing what you want to see can be normal, and efforts like using
double-blind studies may be needed to avoid bias in evaluating, say, a
new drug. That such efforts are needed should not be seen as
disparaging the programmer or the drug-studier, but as merely
reflecting human nature, and as a simple pragmatic requirement if one
is to maximize utility.)

> Its very difficult indeed to design an interface that suits both
> untrained and expert users.


One with a bog-standard UI but also a "console" or command prompt,
scripting language, and customizable bindings?

Funnily enough I can count the software I've seen with that range of
capabilities (so able to satisfy type 1, 3, AND 4 users) on one hand.
Here's the list, in fact:

ROM BASICs and QBasic (on any really ancient microcomputer, and old
pre-Windows PCs, respectively; the former came with printed manuals
and you could just run prepackaged software from disks very easily;
QBasic had mouse and menu support, but an immediate mode command line.
You might not count ROM BASICS as as friendly, due to the lack of
menus and such, but then at that time in history NOTHING had menus and
such! And comprehensive introductory use manuals came with those, and
with pre-Windows PCs (DOS also had a decent and easy to navigate help
system). Most other BASICs and programming environments more generally
lack an integrated environment with an immediate mode prompt. Eclipse
actually sort of does, but the evaluate line can't be used really
arbitrarily and I've found it touchy, and rarely use it.

Hypercard (found commonly on old Macs; had a command prompt you could
access to directly communicate to an interpreter).

Fractint (fractal graphics making software for old pre-Windows PCs;
had a similar prompt, accessed by typing 'g', but also had extensive
help and menus readily controlled by stock keyboard commands such as
the arrow keys, and later a Windows port with menus and mouse
support).

Quake and descendants (yes, the games. Easy to just use the menus and
play the game. Advanced users could hit ~ to drop down a console and
do a few things. Really advanced ones made config files to rebind
weapons and make chat macros to fire off a taunting sentence with a
single keystroke -- no more embarrassment getting fragged while typing
it in longhand in mid-game. Super-advanced ones got at the QuakeC and
made bots, flag-capture mode mods, and other enhancements and
utilities. And sometimes cheats.)

There's probably some more out there, but I've yet to see such
desirable things as:

* The paint program with the usual interface, except you can also do
stuff like hit ~ and type "resample files:c:\foo\*.jpg width:640
height:480 preserveAspectRatio:true doNotEnlarge:false"
* The word processor with the usual interface, except you can also do
stuff like hit ~ and type "format leftIndent 2 where paragraph begins
'Quotation: '"
* The word processor with the usual interface where I can define
logical styles, then change them in only one place and affect every
pre-existing occurrence retroactively.
* The word processor with the usual interface where I can also view an
underlying markup representation and hand-hack that, and which likely
has the capabilities of the first two as a direct consequence of the
implied architecture. Only please, proper functional markup, not
macros like LaTeX or (shudder) winword. I don't want it to be possible
for documents of dubious origin to make it start sneezing, or any of
the general ugliness that follows TeX around like its shadow.
Documents that look as nice when displayed and printed, sure, but just
as nice under the hood if you please.
* Something as powerful as Mathematica, but with a more
straightforward basic-use interface as well as access to a fancy
interpreter.
* The operating system where you can do powerful stuff with a command
line and a script or two, but can also get by without either. (Windows
fails the former. Linux fails the latter.)
* For that matter, the operating system whose GUI takes the concept
behind OLE to its logical conclusion, and lets the user separately
choose and configure their text editing, this-editing, that-editing,
whosit-viewing, and the like components, and those components are used
in building more complex applications. All the alternatives would of
course adhere to a common interface for a particular sort of
component, of course. (An OO language like Java lends itself to this,
what with interfaces and inheritance and dynamic class loading!)
When I run my browser and go to GG to make a post I'd get a text entry
field that was actually my choice in a box, with the usual
capabilities such as spellchecking available, and its own little menu
bar at the top and suchlike. I'd be able to save the contents to disk
without futzing around with the clipboard and launching Notepad, and
later reload, in case the web site was prone to eating the odd
submission. My Jave IDE would display code in the same editor (the
interface should therefore support the using application externally
driving coloring/highlighting, as well as jump-to-line and similar
capabilities). Of course the editor wouldn't itself be Java-aware,
which might not be useful, for example composing a usenet post.
Instead it would provide a variety of abilities to the embedding
application, which may or may not use them. What it would provide
being its particular internal search, spell check, key bindings, etc.

> About the closest I've seen have been
> keyboard driven menu structures which have been designed so the user can
> build their own "command sequences" that traverse menu levels without
> showing the menus, as long as items are selected correctly from each
> level. Many CAD systems approximate to this but I've yet to see a
> graphical desktop, IDE, or editor menu structure that came close.


The bog-standard alt, this, that sequences on Windows "come close";
they do make the menus display, but otherwise they do exactly what you
want, and you can ignore the menus blinking around in your peripheral
vision. When I go to save a file with unsaved changes my first
inclination is ctrl+S; if the app doesn't support that the very next
thing I try is alt, f, s, before resorting to the mouse.

blmblm@myrealbox.com

2007-06-25, 7:10 pm

In article <1182657564.912472.55570@g4g2000hsf.googlegroups.com>,
Twisted <twisted0n3@gmail.com> wrote:
> On Jun 23, 10:36 am, Martin Gregorie <mar...@see.sig.for.address>
> wrote:


[ snip ]

> * The operating system where you can do powerful stuff with a command
> line and a script or two, but can also get by without either. (Windows
> fails the former. Linux fails the latter.)


About the latter -- it's hard for me to be sure, since for many
things something with a GUI is not my first choice of tool, but
my impression is that on "user-friendly" Linux distributions,
pretty much everything, including symin stuff, can be done by
pointing and clicking, starting with the menus displayed on the
default desktop. Perhaps someone with more/different experience
can comment on how many things still require scripting or a
command line.

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
Matthias Buelow

2007-06-26, 10:03 pm

Twisted wrote:

[...]

Hey dude,

get back to selling used cars and leave us computer gs alone, will ya?

Thanks.
David Kastrup

2007-06-26, 10:03 pm

Matthias Buelow <mkb@incubus.de> writes:

> Twisted wrote:
>
> [...]
>
> Hey dude,
>
> get back to selling used cars and leave us computer gs alone,
> will ya?


Well, how will his customers react to the stories about avoiding
Mercedes cars because of people getting hit in the face by the crank
start?

--
David Kastrup
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com