From kde-pim Mon Sep 30 23:28:16 2002 From: Cornelius Schumacher Date: Mon, 30 Sep 2002 23:28:16 +0000 To: kde-pim Subject: Re: [Kde-pim] KAddressBook GUI design issues X-MARC-Message: https://marc.info/?l=kde-pim&m=103342830524288 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 _______________________________________________ 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/