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

List:       kde-usability
Subject:    Re: Panel Arrangement KCM
From:       Benoit Walter <b.walter () free ! fr>
Date:       2004-02-11 20:05:53
Message-ID: 200402112105.53929.b.walter () free ! fr
[Download RAW message or body]

On Wednesday 11 February 2004 20:28, Aaron Seigo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On February 11, 2004 12:12, Benoit Walter wrote:
> > On my system, the window size is 625x574, but we usually use this panel
> > from kcontrol, which makes it unusable on a 640x480. So yes it is too
> > large and too wide.
>
> btw, which version of KDE are you using?

CVS.

> > Having too many columns is also a problem, we have 3 ones, plus the list
> > view of kcontrol.
>
> hrm... viewed within kcontrol this is a problem =/
>
> > > this was tried. it didn't work. in fact, it was like this in the very
> > > first revision of the UI... testing it showed how much that idea sucked
> > > =)
> >
> > Can you explain how?
>
> people did not see the buttons (fixated on the display) and were not sure
> how it worked, especially in combination with the other controls which
> weren't associated with the monitor in any way. i expected it to work out
> fine, testing proved otherwise =/

Well, I personnally did not test it, but I am glad you did it :-) So I agree.

> > > > There are quite a lot of things that could be improved in this panel,
> > > > such as:
> > > > - using a combobox instead of a listview for the list of panels
> > >
> > > a combobox is slower to access.
> >
> > As it would be in any place where we use a combobox. If you take for
> > example the background dialog, you use a combobox, too, although it would
> > have been in these case useful to quickly change the backgrounds...
> > But in the case of panels, I don't think you need to access very quickly
> > to this action. You just choose the panel you wish to configure and
> > change the settings.
>
> hrm... the convincing argument for me here is the fact that in kcontrol it
> results in 4 columns ... sure... can do.

That's enough, but I tried to give other reasons why we should try to save 
some screen space...

> > > > - moving settings between appearance and hide when appropriate
> > >
> > > which ones?
> >
> > Appearance->Advanced:
> > - Hide button size (should be close to show/hide hide button)
>
> no. this is a rarely accessed setting and should have sane defaults.

I don't think we should change the defaults :-) But leaving some options in an 
advanced dialog should be avoided, if possible.

> > - Allow drag'n drop resizing of panels (should be close to panel size)
>
> ditto.
>
> again, these things were moved to the Advanced dialog from being on the
> main interface some time ago. there were GOOD reasons for that.

The GOOD reasons where mostly to save place, that's why less frequently used 
options (and also the last ones to be implemented) were moved to an advanced 
dialog.
I am not totally against the use of an advanced dialog. But when possible, 
settings should be grouped logically. Having 1 advanced dialog for several 
categories is not good.

> > > > - the menu section should have its own module as the KMenu is not
> > > > only related to kicker but can be shown when clicking on desktop or
> > > > pressing alt+F1, too.
> > >
> > > this is a technicality. people tend to perceive the menu as part of the
> > > panel.
> >
> > That's not that obvious. That's the case from a developper point of view
> > as the code for kmenu is located in kicker. But users who click on the
> > desktop to display the menu will never find it in the 3rd tab of the
> > panel kcm...
>
> no, this is based on talking with users and silently watching them try to
> manipulate these things... they usually first try to right click on the
> menu if they are an experienced windows user =)

Yes, sure. Most users (especially when coming from windows) click on the menu. 
But it does not mean that they will easily find it somewhere in the panel 
configuration.

> > It could be found anyway when right clicking on the panel ("Configure
> > Panel..."). For the moment, we have 2 sections:
> > - Layout (with 4 tabs: Arrangement, Hiding, Menu and Appearance)
> > - Taskbar
> >
> > The layout section is not really ideal for the configuration of the
> > kmenu. OTOH, it would be much easier and more logical to find it in its
> > own section as it is the case for the taskbar.
>
> yes, for 3.3 when you launch it from the panel there won't be any tabs.
> each tab will be it's own icon down the side.

Then it will be inconsistent with the control center... Not good.

> > In the control center, it is even more difficult to find it in the panel
> > section. I usually think it is good to reduce the number of modules, but
> > the "Desktop" has only 5 modules and Multiple Desktops is likely to be
> > moved to another place.
>
> "only 5" is plenty. =)

Not that much, if there are good and logical reaons for it. Especially if it 
can help tidying a bloated dialog.

> we used to have monolithic panels. then we broke them into itty bitty
> pieces. then we put some of them back together. now we want to break them
> into itty bitty pieces again? sounds like useless meandering that is
> resulting in the repetition of history ... having a billion panels is not
> the way to go. tabwidgets aren't _that_ evil.

Each case is different. Of course generally I am against having too many 
modules, and we should reduce that number. But that is not a law we should 
respect at all cost and for each case. Closing your eyes and automagically 
transform panels into tabs is not a solution. There are always exceptions, 
and if the most logical solution is to add a new panel, the general trend 
should not prevent from doing it.
Let's say removing 10 panels and adding 2 ones is something possible in a 
multi-dimensional world :-)
 
_______________________________________________
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]