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

List:       kde-pim
Subject:    Re: [Kde-pim] KAddressBook GUI design issues
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-09-30 23:28:16
[Download RAW message or body]

On Monday 30 September 2002 21:59, Anders Lund wrote:
>
> First the QuickEdit + distribution list manager:
>
> I can appreciate the idear of the quick edit, but the current design
> of the component has several GUI design flaws.
>
> * It does not display all its controls correctly if the kaddressbook
> window hasn't got quite a size. It should claim the space it requires
> to display correctly, or alternatively provide optional scrollbars
> like kcm modules, though that is not really a good solution.

Hmm, I can't reproduce any problem with misdisplayed controls. The quick 
does claim enough space to display correct.

> * It contains keyboard accellerators for controls, that may conflict
> with those of the kaddressbook window's menus. I think all
> accellerators should be removed to get a clean design, whereas the
> addressee editor dialog is lacking accellerators, preferably every
> single control in a dialog should provide a keyboard accellerator.

All controls in a window should have accelarators. As this is almost 
impossible to achieve manually (especially if you consider 
translations), we should probably try to do this automatcially. There 
is KAcceleratorManager in libkdeui. This might be worth a try.

> * Nested tab widgets is downright bad GUI design. (Go here if you
> forgot why: http://www.iarchitect.com/mshame.htm) If the quickedit
> and the dist list manager should be displayed within the same widget,
> we should come up with an alternative control - possibly the tab bar
> used for Kate tool views could be used, placed in the bottom of the
> window (the same control is used in the konqueror navigation bar - so
> it probably will become familliar to users).

The nested tabs as they are now are horrible. We can't release 
KAddressBook before fixing this problem. Several additional 
alternatives come to my mind:
- Use bottom tabs for the feature bar tab, that gives a slightly better 
impression, but doesn't change very much.
- Provide menu items for enabling the distribution list editor and the 
quick edit independently. This could also mean that we could have both 
at once, but they could also be mutually exclusive. We could also add 
tollbar buttons for the menu action to provide quicker access to these 
options.
- Another alternative could be dock widgets, although I tend to not like 
them, because they have the potential to make a GUI really confusing.

> * I miss the option to display the dist list manager in the form of a
> dialog, as I dislike it embedded in the window in the current form by
> taste. As for the addressee editor, a dialog form should have
> keyboard accellerators while an embedded view none.

We really should provide the distributon list editor also as dialog. The 
embedded version is really cool, because of the drag&drop feature, but 
there is no reason why a dialog based version couldn't do the same and 
the embedded version could also provide the controls for selecting an 
addresse from a list.

Conclusion: the embedded version and the dialog version should be based 
on the same code.

> And some suggestions:
>
> * Since we allready has such tool views, maybe adding a "manage by
> categories" view would be good, pretty much like the dist list
> editor, so that you could create a category and drag contacts to it
> from the main view (Just agree, I'll volunteer to create it in time
> for 3.2 if you do).

Agreed ;-)

> * Btw I often think that categories should be usable as dist lists
> automatically, in which case the distribution list system could even
> be dropped (unless someone cares for the option to select a different
> email address for a specific purpose in a dist list...). Anyway
> beeing able to send email to a category directly from kmail
> forexample would be kinda cool, I do know that that could easily be
> added in the kmail code, but having the adderssbook returning
> categories as dist lists would be cleaner.

Using categories to create some kind of implicit distribution lists 
sounds like a cool idea.

I don't think that we could replace the distributiobn lists by 
categories. They are used in a different way. For categories you have 
the set of all your addressees and try to classify them by different 
categories. For distribution lists you don't have the intention to 
classify your addressees, but you have to select a certain subgroup 
because of a common interest or some very specialized reason. The 
difference is that you come from a very generalzed point of view when 
using categories and come from a very specialized point of view when 
you use distribution lists. Of course ther is some overlap, but it's 
something different.

> * I would like to add the option to decide weather to display the
> quickedit and details panes to the view configuration, with the
> options for each to display, not display or inherit current state.
> That way I could create views handy for editing and views handy for
> viewing. (Again, just agree and I'll go on)

I like that idea.

> I don't know if a generic way of removing all accels inside a widget
> exists, but maybe we should come up with one?

As said above, try to use KAccelaratorManager.

> Some notes about the details pane:
>
> * It is not working well GUI-wise when displayed in a vertical pane,
> because it does not have an understanding of the width it requires.
> It should consider the required width and either provide scrollbars
> or claim the space it needs, preferably the first since the width
> will depend on the amount and length of the data in individual
> contacts.

It doesn't seem to provide a minimum width. That's a bug.

> * Allthough I havent got any options to configure it atm, I do
> remember a serious problem with background tiles, especially
> "bordered" ones.

What do I have to do to make the "Select Background" submenus to be 
enabled?

By the way, the details view comes up with unusable font settings for 
me. They are just too small to be readable. As I couldn't find a way to 
configure the fonts, I wonder how this is supposed to work.

> (I'm not sure if a [k]html view wouldn't do a much better job, using
> a such would also enable really flexible templates for advanced
> users. It has scrollbars/geometry management and supoorts
> selecting/copying)

KHTML might be a bit heavy, but a QTextView could also be very useful to 
provide rich-text formatting.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]