[Gllug] is KMAIL a good enough client for gllug?

[Nix]

On Fri, 9 Sep 2005, Steve Nelson stated:
> On 9/8/05, paul <paul at thinksolution.net> wrote:
>> On Thursday 08 September 2005 16:31, Nix wrote:
>> >. I went through my graphics-freak
>> > ooh-look-it's-GUI-it-must-be-cool phase when I was about fifteen
>> 
>> you continually misinterpret everything I've been saying
> 
> Not really - lots of people really did go through a 'wow its GUI'
> phase, especially if we'd spent a lot of time in a purely textual
> environment before.

Indeed. I overdid it, as usual, spending nearly an entire week
just rearranging windows in joy.

These days, of course, I'll do virtually anything to avoid that
sort of waste-of-time excise. :)

  And many of us have moved through that phase,
> because often a purely textual environment is more suitable, less
> inhibiting, faster, less resource intensive etc etc etc than a
> graphical equivalent.
> 
>> I'm just saying - and lets put a cap on it now -

It's just occurred to me: this is another unethical debating tactic, the
`let's stop the debate now because I have no arguments left but I want
it to appear as if I've won' tactic. (I'm not sure if it has a formal
name: anyone here trained in rhetoric?)

Two unethical tactics in *one* paragraph. Impressive.

>> I'm just saying that these days I am more used to working with graphical
>> interfaces - generally they tend to to be self explanatory.
> 
> Actually often they don't.  For very simple tasks 'click on new' yes,
> they are intuitive.  To change a number of detailed settings, point
> and chase, hide and seek mouse effort is very unintuitive, and vi
> /etc/myapp.conf provides a well documented, clear and easy way to make
> changes.

I'll freely admit here that Emacs and Gnus are, er, perhaps not
accessible to the new user. They take the `tutorial, manual, and massive
amounts of instantly-accessible documentation' approach, and sometimes
seem to bind keys almost randomly (`oh, there are only three keys left,
let's pick that one over there').

They're *definitely* an example of `easy to use, hard to learn' software:
but they're so easy to use that once you're hooked, you hardly *ever*
use anything else.

> Let's send an email.
[snip]

Lovely point-by-point analysis. :)

> 4) You're now you're in an editor - well - you want to write an email,
> right?  What is more appropriate?  And if you're a
> programmer/sysadmin/techie/geek (and 99% of us on this list are) the
> ability to write emails in the same tool you use for the rest of your
> job (in my case vi) is a glorious benefit.

This is a very large part of why my news and mail program runs inside
Emacs. (Emacs is weird, of course: things run inside *it* rather than
the other way around.)

> 5) Ok email written - so save & exit the edit - not obvious in vi, I
> grant you, but vi may not be the default editor.

I've always found :ZZ (`I want to go to sleep now') to be one of vi's
few memorable keys. :)

obSilly: <http://www.dina.kvl.dk/~abraham/religion/vi-tutorial.html>,
a tutorial on a complex and difficult task, moving the cursor one
character forwards in vi.

> 6) We now have a summary of the mail, and little instructions at the
> top, which have changed, as the context has changed:
> 
> y:Send  q:Abort  t:To  c:CC  s:Subj  a:Attach file  d:Descrip  ?:Help

One affordance which dialog boxes have which this does not is that
it requires some attention to notice that the instructions have
actually *changed*.

I wonder if what might be good is a hack to (xterm|rxvt|gnome-terminal|
konsole) which arranges for a run of text which is abruptly replaced by
a run of other text to flare brighter for a second.

(The definition of `a run of text' requires careful thought. You still
want new text atop blankness to appear instantly without flaring, or
typing text in would look... odd; yet you don't want the characters in
a changed menu line to flare intermittently depending on whether there
was a space in each cell previously or not. We probably also don't
want a complete screen blank-and-repaint to flare.)

> Now to make an (admittedly straw-man) comparison, let's do the same in Outlook.

Yes, this is very straw-man: using Outlook as an avatar of good
graphical mail client functionality is like using Stalin as proof that
speaking Russian damages one's morality. :)

> 1) Your hands are on the keyboard.
> 2) Move mouse (oh - my hands were on the keyboard) to the picture of
> an email, and click on it.  Yes I know I could type c-n but why have a
> mouse if we're not going to use it?

Also, the affordance for hotkeys in Outlook is very bad. The menus only
list what hotkeys are bound to menu items if you fiddle an item on
in an obscure customization item, and as the menus aren't visible
when you're typing, you have to remember them anyway.

(This is a general fault of GUIs, again. Tellico had it until I moaned,
and now it allocates hotkeys for fields automatically and does the
underline-to-show-hotkey thing.

Perhaps a GUI with a pine-like hit-this-key box instead of a menu?  I
hate pine, but this seems to be one thing it's done right. There was a
tcsh-derived shell once whose name I've quite forgotten which did a
similar thing.)

> 3) New window pops up (ewww - more mess and loss of screen
> real-estate)

It takes multiple saccades for the eyes to locate the new window,
too. This is true the first few times something happens in a textual
app, too, but if you run your textual app maximized, the same thing will
generally always appear on the same place on screen, reducing eye
movements. GUIs have a habit of whamming up new windows in a different
place every time, so the multiple saccades never go away.

(Real user-interface analysis people really do go to this level of
detail as a matter of course. I've seen them, and it's awe-inspiring to
watch; I do what I can to emulate them, but I'm not fit to carry their
boots. Alas, there are very, very few such people, and most of them
don't seem to have had much to do with designing GUIs for normal
mortals.)

> 5) Type in the intended recipient and press enter.

It has a pull-down list here of similar names you've used before, and a
hotkey to autocomplete them. Alas, the hotkey and pull-down list work
from *different data sources* so you can easily get only one thing in
the list, say, `complete', and it blats up a huge modal dialog telling
you that there are none.

That's another big no-no from a UI point of view: a hotkey that Does
Something Fast, like completing a name, should *never* wham up a modal
dialog if it fails, because anyone who's used the feature more than once
or twice is going to be typing in another name, and now all that typing
vanishes in a storm of beeping.

> 7) Ok, so I'll have to move the cursor.  I could use tab, but a) we
> have a mouse b) I might not know that tab will move to a new field c)
> I don't necessarily want to tab to the rest of the fields - who said I
> want ccs, bccs etc.  So I ....

d) it doesn't even work consistently, because in the main editing pane
tab enters a tab. (I can see the logic here, such as it is, but, um, why
am I not able to enter a tab in the subject field, for instance?)

> 8) Move hands to the mouse.

You meant `hand'. I've never seen a user manoevre a mouse with both
hands.

This btw is where laptop users and specialized keyboard users have
it good: because the mouse is *in the keyboard*, moving to it is
very much faster than with a separate device. (It's still a lot
slower than hitting a key, though, assuming touch-typing.)

> 11) This is a nasty horrid experience having to type and move the
> cursor around in this edity thing.  For a start when I do the sort of
> natural things I do in an editor, it spews random letters and
> punctuation at me, or worse still asks me if I want to keep my
> message, and pops up a window in front of what I was doing!

More significant is the way it's almost impossible to control your
indentation. You have to dive around menus to de-indent, often it
does nothing when you do so, and often it decides to de-indent half
the document. I still don't see any logic or coherency in this:
I suspect it uses a random number generator to pick a behaviour.

Hell, no, this is MS. That's nowhere near lunatic enough. I bet it uses
a secret human-behaviour-modelling system from MS Research (that was
intended to model user respones so as to customize UIs to work as well
as possible) in order to find the most annoying thing to do, and then
does it. That would explain Outlook's huge memory hit too.

(MS: advanced research, arrogance, and incompetence combined!)

(Sorry, do I sound bitter? Overexposure to Outlook at fault, sorry.
Gods I hate that program. It does *everything* wrong.)

> 13) Ok - lets send the email.  How do I do that? Ah - there's a
> picture of an envelope and the word send up there.

For that at least Ctrl-Enter works and is reasonably easy to remember.

>> you seem to take it personally that I have a preference or
>> need that is different to yours.
> 
> No - we're generally analytical people who try to get points across,
> and who will analyse point by point what you say, raising a
> counter-point.

It's called debating; it's a national sport in many countries. (Hands up
all those here who were *not* on their school debating team.)

-- 
`... published last year in a limited edition... In one of the
 great tragedies of publishing, it was not a limited enough edition
 and so I have read it.' --- James Nicoll
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug