[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:       Till Adam <adam () kde ! org>
Date:       2005-03-09 22:19:32
Message-ID: 200503092319.40817.adam () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 09 March 2005 20:39, Malte S. Stretz wrote:
> 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.

Where it is less visible, yes. Exactly the point.

> | 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.

Any and all functionality should be availabe via menus, if for no other reason 
than accessibility. (We have not achieved that yet, but we're trying.) It's 
arguable that the mailing list management belongs as a tab in the properties 
dialog, but there is a tradeoff between meeting that expectation and avoiding 
confusion for the majority of users for whom that functionality is esoteric 
and confusing. 

> > 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,

Because we didn't get around to fixing it yet. Fixing it got lower priority as 
it was more important to us to get the properties themselves cleaned up on 
time for 3.4 

> the properties dialog still has a single "General" tab

Unless you have imap or dimap account folders in which case there is also 
"Access Control". The idea is to have that tab for local folders as well, 
eventually, with permission information, similar to what Konqueror shows for 
folders.

> instead "New Message to Mailinglist" is below the same separator where the
> configuration stuff is.

That's a bug.

> 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).

Expiry is a background action. It is usually not triggered explicitely and the 
dialog only applies it on close as a matter of convenience. The entry in the 
Folder menu should also open the dialog, like the one in the RMB menu, I 
guess.

> 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.

What handler? New Message to Mailinglist?

Till

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]