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

List:       kde-usability
Subject:    Re: KMail/Kontact keyboard navigation
From:       Diego Moya <turingt () gmail ! com>
Date:       2005-03-28 14:59:03
Message-ID: 11ee0494050328065948f237e () mail ! gmail ! com
[Download RAW message or body]

(Sorry if this message gets posted twice - I sent it last Wednesday
and was automatically filtered because of the attached image).


Here's my take on this subject:

- Unless you can provide a new interface as efficient as the current
one, the old behaviour must still work in the new design (at least the
basics: up/down scrolls through text of current message, left/right
moves to previous/next message). Secondary details might change,
though.

- The interface shouldn't be changed unless the new design is an
improvement (or at least not worse) for everybody.

- KMail developers should agree that the current interface *has* a
severe problem for newcomers, and it's just not an educational one but
also a consistency one. If we analyze it with the Knowledge Gap model,
we find the error is that the new user already *has* knowledge about
how a list should behave (there is no gap), but this knowledge
conflicts with the provided interface. Having a list (the messages
panel) that doesn't behave like a list is inconsistent with the rest
of KDE and with user expectations.
(P.S. This is partly alleviated by the "Keyboard navigation bar"
suggested by Sébastien. At least it enhances the discoverability and
remembrance of the left/right keys)

- Adding a preference to select among two broken modes will *not* fix
the problem. (BTW, that's one of the reasons why I always have ditched
KDE for my personal use - this too often is the preferred "solution"
for usability problems in KDE apps, but it rarely is the best one. I
see KDE as a "make your own GUI", but not everybody is a good
Interaction Architect. Ok, now I've finished my rant and go back to
the problem).


Sébastien is right in that every listbox should allow to be navigated
with up/down keys. Sven is right in that, as long as there are two
vertical scrollable panels, one of them will be awkward to use.

The logic consequence is that there MUST NOT be two up/down panels. In
order to achieve the right solution one of the two must be changed
into something else, a custom widget that doesn't raise those strong
expectations of up/down navigation.


A possible solution is the "thread arcs" widget found in Gnumail. This
widget shows all messages in a thread ordered by date from left to
right. An arc means that the second message was a reply to the first
one.

This interface was developed by IBM for the ReMail prototype (see
links below). It has good research support performed on real users,
and better yet, it presents a *horizontal* axis for previous/next
messages, so it's best suited for Kmail's left/right keys.

GnuMail:
http://www.roard.com/screenshots/gnumail-threadarcs.png

Remail Thread Arcs:
http://www.research.ibm.com/remail/threadarcs.html
(includes link to IBM research report on thread arcs).


I've done a mockup of a possible solution on how Kmail could use Thread Arcs: 

http://www.ii.uam.es/~dmoya/imagenes/kmail-mockup.png

The messages panel is changed into a dropdown selection box
so you still have access to the history list if needed, but the main
navigation is now done reading the "<- Previous" and "-> Next" rows
and using left/right keys.

Under the selection box I have are placed the thread arcs widget and
aggregated information of the whole thread (see description in the IBM
research paper).

I've also added columns to order "by thread" and "by read/unread". The
default message ordering should be "by thread" so that left and right
keys move through the current thread as seen in the Thread Arcs
widget. You can easily change that by selecting a different ordering
column (by date, all the unread messages, by sender...). (I find that
selecting the "thread mode" is too difficult in the current mail
clients interfaces - it is usually buried as a second-level option
under the View menu. Turning it into a ordering column makes it faster
to select).


Using the Thread Arc widget would be an important bonus for KMail - it
adds to the interface a lot of information related to frequent user
tasks. As you see, creating an interface that does the "Right Thing"
and solves all problems is usually a lot of work!
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

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