[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [kde] KMail key binding and the User Interface Guidelines
From:       Magnus Holmgren <holmgren () lysator ! liu ! se>
Date:       2006-03-30 8:19:29
Message-ID: 200603301019.32819.holmgren () lysator ! liu ! se
[Download RAW message or body]

Hello, honourable developers!

Please have a look at this and don't just say "we've been through this 
already, it's never gonna change".

Ingo Klöcker wrote this over two years ago:

> We receive almost no complaints (I'd say less than 5 per year) about
> KMail's keybinding. Occasionally (i.e. about every six months or so)
> one person complains about Up/Down scrolling the message instead of
> selecting another message. After those people learn about Left/Right
> they are satisfied.

I'm not satisfied with this and I believe that you could actually get the best 
of both worlds, so why not do so instead of binding some keys so hard?

The main reason that I'm not satisfied is that while some basic navigation is 
made more efficient, bulk message handling (selecting several messages for 
deletion, for example) using the keyboard is seriously hindered, even though 
Shift+Left/Right can be used to extend the selection. I can't move 
around the message list using the arrow keys in the usual way, with 
left/right moving up and down the threads, collapsing and expanding them in 
the process. I more definitely can't use Ctrl+Arrow keys to move the focus 
rectangle and Ctrl+Space and Ctrl+Shift+Arrow keys to select and unselect 
messages. A good application should be usable without a mouse and I don't 
feel that Kmail is, at the moment.

Now, how bad would it be, really, if Kmail weren't focusless?

> Now, let me explain KMail's philosophy with respect to keyboard
> navigation:
> KMail is designed as focus-less application. (...)
>
> So, why is KMail's keyboard support highly efficient? Because the focus
> doesn't get in the way. Okay, let me explain. Let's imagine you want to
> read two consecutive messages with a "KDE compliant" KMail:
> First you have to select the first message you want to read. But wait.
> Before this you have to make sure that the message list has the focus
> (with Tab). So now you have selected the first message (with Up/Down).

Not so. Nothing prevents having arbitrary keys or key combinations change the 
current message regardless of which pane has the focus.

> You start reading. Hmm, the message doesn't fit completely into the
> preview pane. You have to scroll (with Down). To do this you have to
> focus the preview pane and scroll down. 

Untrue. The quickest way is to use Space, which scrolls the current message 
down one screenful, regardless of focus. And assuming that focus never left 
the preview pane Up/Down are still available.

> Now you want to read the next 
> message, so you hit Tab until the message list has focus, you press
> Down to select the next message, you start reading, you hit Tab until
> the preview pane has focus, you press Down to scroll the message down.
> Do you get it? Isn't the fact that you'd constantly have to switch the
> focus between the panes highly annoying? And it's even more annoying to
> find out which pane currently has the focus (unless there was a fat
> ugly frame that indicated the focus).

I agree that the focus rectangle is too difficult to spot. However, that a 
"fat ugly frame" is needed is an exaggeration.

> As comparison let's now see what you would do to read two consecutive
> messages with the "standard breaking" KMail:
> You select the the first message with Left/Right, you start reading, you
> scroll down with Down, you select the next message with Right, you read
> and, as necessary, scroll down with Down.
>
> Now that's what I call efficient. You don't have to care for which pane
> has the focus when you press Up/Down. You don't have to switch the
> focus constantly. Instead KMail just does what you tell it to do.

I don't have to care about which pane has the focus when I use Thunderbird 
either. Usually I just space through my unread messages, or use N to skip to 
the next one before reaching the end of the current message. If I 
accidentally skip away too early, neither program will help me much unless 
the next unread message was directly below, because both currently lack a 
navigation history. Right/Left in Kmail are too slow because each message is 
opened as the selection changes (a delay would help). Of course there are 
other key combos that just move the focus rectangle and that's good, but not 
good enough.

> You want to select another folder: Use Ctrl-Left/Right to select and
> Ctrl-Space to open.
> You want to select another message: Use Left/Right
> You want to scroll: Use Up/Down
>
> You don't have to agree with this philosophy, but I hope that you now at
> least understand why KMail's works as it works, and I'm sure that
> you'll agree that the way it works is very efficient. There's always a
> trade-off between efficiency and "strict standard compliance". And in
> my opinion in the case of KMail the efficient handling outweighs any
> arguments for strict standard compliance (especially with respect to
> the focus paradigm).

I understand the philosophy, and I agree with the idea that focus shouldn't 
get in the way. The problem is that if you don't care at all about which pane 
has focus, you need a truckload of key combinations to be able to do 
everything you could do if you did let focus determine how to act.

But some people like it and they don't need all the Ctrl+Shift+Arrow keys and 
so on. The thing I'm against is the non-configurability. You see, I prefer 
letting standard keys have standard behaviour while adding additional 
shortcuts to speed up work, instead of giving the standard navigational keys 
nonstandard behaviour and adding the standard behaviour to completely 
different keys.

By the way, there are many things remaining to be done to make Kmail truly 
focusless, as reported in some bug reports, like making sure that typing 
unbound letters won't move the selection. Or pressing other key combinations 
that are unaccounted for and therefore get acted upon by the control that in 
fact does have the focus.

I suggested a compromise in https://bugs.kde.org/show_bug.cgi?id=96301. I'd be 
happy to get at least some feedback since my suggestion is perfectly 
compatible with your philosophy. In short:

* Allow reconfiguration of all Kmail-specific and special key bindings. I 
think the only ones remaining are Up, Down, PageUp, PageDown, Shift+Left and 
Shift+Right.

* Add shortcuts to jump between panes, preferably (Shift+)F6 and 
(Shift+)Ctrl+Tab. Tab by itself focuses hypertext links and the Quick search 
field. That makes it way too slow. Possibly add a shortcut to return focus to 
the preview pane.

Thank you for listening!
-- 
Magnus Holmgren
holmgren@lysator.liu.se
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel

[prev in list] [next in list] [prev in thread] [next in thread]