'Re: Why was the folder Properties dialog split up in 1.8?'

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

List:       kmail-devel
Subject:    Re: Why was the folder Properties dialog split up in 1.8?
From:       "Malte S. Stretz" <msquadrat.nospamplease () gmx ! net>
Date:       2005-03-09 19:39:08
Message-ID: 200503092039.11955 () malte ! stretz ! eu ! org
[Download RAW message or body]

On Wednesday 09 March 2005 16:09 CET Carsten Burghardt wrote:
> Malte S. Stretz sagte:
> >[...]
> > Was there some good reason to split this dialog up that I miss?  To
> > summarize, I think all folder "settings" and handler belong to the
> > Properties dialog, that would not only give the user one place to look
> > for settings but also shrink the menus, especially the context menu.
>
> The reason for the changes to the properties dialog is an usability
> study: http://www.openusability.org/reports/view.php?group_id=55&repid=43

While I agree on many parts of that "study" (were any of those changes 
tested by actual users or is it just what the three authors thought was 
better?), the split of the properties dialog is IMO nonsense and even 
contradicts what the authors wanted to achieve.

That's of course only my opinion but I now (try to) work with that new 
dialogs for about a week and still I try to find stuff in the properties 
dialog which aren't there anymore.

If I may comment on some parts of the study:

| 1. Current State
| The folder properties dialog of Kmail is rather confusing and suffering
| from a load of settings. For most users and for most cases, only essential
| functions are relevant. The other functions distract from the essential
| ones, which leads to a visual clutter and confusion. 

That's right.  But by moving the options around, you won't have less 
options, just move the clutter somewhere else.

| 2.1 Amount of settings
| The first step is to reduce the amount of settings that a "normal" user is
| confronted with in the properties dialog. Issues that either require deep
| technical insight or that is relevant only in 1% of cases should be kept
| "out of sight", but still accessible, or put to another place. Reducing 

How often do you change the settings of your folders?  (I used the dialogs 
pretty much the last days because I used the KDE update as a chance to also 
clean up my folder structure and unsubscribe from some mailinglists I don't 
read anymore.)  Normally you change neither the mailinglist settings nor 
the expiry settings very often.

So instead of "hiding" (in the meaning of removing it from the daily used 
interface, see below) those rarely used options, you instead move them into 
the menus, adding to their complexity.

And if you really need to change some of those options, where do you look 
first?  Maybe it's just me, but if I look for some kind of settings, I open 
up a configure dialog.  And for the folders, the Properties dialog is more 
or less the configure dialog.

So instead of moving stuff "out of sight" of the "normal" user (maybe I'm no 
"normal" user, but on "normal" days I don't look at the Properties dialog 
very often), you move the stuff *into* sight by cluttering the menus.

> We agreed that the new layout is much better and thus changed it.

Unfortuanetely did you only apply the bad suggestions and left out the good 
ones :)  The "Mailing List Management" dialog still has the old confusing 
interface, the properties dialog still has a single "General" tab, the 
context menu still contains "Compact Folder", even an "Assign Shortcut" was 
added there.  "Compact Folder" and "Expire" are not grouped together, 
instead "New Message to Mailinglist" is below the same separator where the 
configuration stuff is.

If I should write a "study" about this, I'd actually go exactly the other 
way this one went with the Expire dialog:  Split the "configure" part and 
the "action" part.  Like the old expiry settings were:  Settings in the 
Properties dialog, the action directly via the menu (or some separate 
"folder maintenance" dialog where also the Compact action and possibly a 
backup action could be added).

The latter should be applied to the mailinglist management, too:  Settings 
in the Properties dialog but calling the handler from somewhere else, maybe 
that maintenance dialog I suggested above.

The idea behind that suggestion is:  Configure once (and in one place), use 
often.  But I'm no usability expert, just a user, so I'm probably 
completely wrong.

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>
_______________________________________________
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] 