KMail key binding and the User Interface Guidelines

Frans Englich frans.englich at telia.com
Tue Feb 3 00:05:09 GMT 2004


On Monday 02 February 2004 23:03, Ingo Klöcker wrote:
> Robin Rosenberg escreveu:
> > Not sure if I should report this as a bug or not.
>
> Don't. We'd close it immediately. We had this discussion already several
> times.
>
> > For some time KMail has not obeyed the "standards" with regard to
> > the common keys like arrow-up, down, Ctrl-A etc. In most
> > applications arrow up mens "focus on next item", in KMail it is
> > "scroll down in mail". Ctrl-A means select all item, i KMail it
> > means select all messages,
>
> In Konqueror Ctrl-A means select all files. In KMail files correspond to
> messages. I don't see any inconsistency here. In KDE 3.1 Ctrl-A
> selected the whole message. But that's a pretty useless action because
> I see no single use case for this. Why would anyone want to select the
> whole message including the header?
>
> > typing a letter focuses on the list item
> > starting with that letter (in kmail its a combination oa actions
> > and selecting items).
> >
> > Of course these are useful to some and people coming from
> > inconsistent mail clients may not notice the inconsistency. I do
> > notice. The consistency in KDE's user interface is a big reason for
> > me preferring KDE over Gnome (and GTK applications in general) I'm
> > used to being able to navigate just about everything from the
> > keyboard using  the "standard" conventions common in Windows and
> > KDE and some other environments. Kmail breaks a lot.
> >
> > I could subscribe to the idea that without a predefined focus some
> > non-standard bindings could be used, but when I explicitly select a
> > pane, by clicking in it or using tab to shift focus to the next
> > pane, things should work the same in all applications.
> >
> > The "focus" is very unclear in KMail. If I use the arrow keys it
> > appears that the messge has focus, but if I press Ctrl-A it appears
> > that the message list has focus pressing J (or something not
> > prebound in Kmail) shifts focus on the first message box starting
> > with the letter 'J'.  Pressing 'K' does not focus one the KDE-list
> > folder
>
> The latter is a bug.
>
> > If I click on a message and press Ctrl-A, the whole message would be
> > selected in any KDE application I can think of. Except KMail.
> >
> > Another thing is the +/- keys which is most apps mean open/close
> > trees in lists. Again Kmail has it's own idea.
>
> [snip]
>
> > Ofcourse, considering the alternatives, KMail is still my choice,
> > but these are things that annoy me and are possibly very annoying
> > to peoply who cannot choise their method of interaction as easily.
>
> 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.
>
> Now, let me explain KMail's philosophy with respect to keyboard
> navigation:
> KMail is designed as focus-less application. That means that all keys
> should always work the same regardless of which pane currently has the
> focus. What's the advantage of this? The advantage which KMail has over
> many other applications which have several panes is the efficiency of
> KMail's keyboard support. Since email management is a task many people
> spend a lot of time with it's important to make it as efficient as
> possible.
>
> 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).
> 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. 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).
>
> 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.
>
> 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).

We could say like this; as Ingo has outlined there is many good arguments(my 
opinion) to why KMail has its keyboard shortcuts as it has. I conclude that 
it should stay this way.
In other words, KMail's shortcuts are inconsistent with the rest of KDE, does 
not follow the Interface Guidelines - and the behavior is kept because the 
functional gain is so high it is considered more important. It is more 
important than consistency with other KDE apps, and more important than 
following the guidelines. That is the reasoning in the big picture AFAICT.

Sounds right?

(I'm not being sarcastic, I'm just trying to clear out how all the different 
aspects hang together)

Cheers,

		Frans

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.




More information about the kde mailing list