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

List:       kde-usability
Subject:    Re: [Kde-usability] Some observations & comments on KDE2.x's UI
From:       Jono Bacon <f9808590 () wlv ! ac ! uk>
Date:       2001-03-23 17:29:39
[Download RAW message or body]


On Fri, 23 Mar 2001 10:01:50 -0700 "Majewski, Bruno" 
<Bruno.Majewski@attcanada.com> wrote:

> Note: this is a edited version of a recent posting of mine on KDEdotNews. I
> must point out that these observations are from:
> *	the Debian Potato packages of KDE 2.1, running on my Woody box;
> *	my KDE2.0-equipped Mandrake 7.2 box;
> *	the Sparc-based SuSE 7 running KDE 1.1.2  I have in my cubicle at
> work.
> 

:-)

> While KDE 2.x gives an impression of being more polished/more 
advanced, at
> the same time it has become more complex and less intuitive. KDE 2.1 is
> definitively not one of those old, primitive window managers of old. It is
> far more functional, nice-looking and intuitive than whatever you'll find
> usually with (say) twm or olwm. But there an accumulation of details here
> and there that makes it less intuitive than *cough!* Windows.

I agree. An abundance of features can cause confusion if not 
implemented correctly.

> I don't like to say that a *nix GUI environment is less intuitive than
> anything that comes out of Redmond, but considering the design of all those
> added bells and whistles in KDE and how to access them, it's kind of true.
> One of my biggest beef, for example, has been with the menu that pops up
> when you right-click on the desktop: it has become more complex in
> appearance, intimidating... while losing the "display properties" item found
> in KDE 1.1.x

Windows has many great design features. I think people who penalise 
windows just because it does not fullfill expectations in some areas, 
are silly to lump the whole beast into one catagory. We would'nt want 
to say KDE is bad just because one area needs work.

> Furthermore, the "buttons" (quit, maximize, minimize and...?) in the
> top-right corner of each windows are somewhat inconsistent and not always
> obvious to figure out what they mean. The "X" I can figure out, but
> sometimes, there is one that is a circle which I cannot for the life of me
> figure out what it means. Do we really need it, anyway? And then there is
> that "?" (question mark) button which does not seem to bring anything
> usefull or be really supported by the environment. Well, what I am expecting
> after I click on this button is not happening. Aaannnd of course, if I am to
> rant about these buttons, I should also bitch about the inconsistent/always
> changing "maximize/minimize" ones. While I am of the "more power"/"the more
> is the better" frame of mind, there can be too much of a good thing.

It is these areas that will be picked up in the general KDE study. The 
general KDE study will be a subset of the KDE Usability Study that gets 
data on general KDE use such as kwm, konqi. We will then look at more 
specific data in other studies such as the icon study.

> Note: I think the aforementionned buttons got tidyed up in KDE2.1, 
that the
> disconcerting behaviour was more in KDE2.0 thank KDE2.1 -- but then, I'm
> going from memory, here.  My KDE2 boxen are at home and I am at work.
> 
> Essentially, what I am trying to convey here is that some streamlining is in
> order for KDE, and the sooner the better. We cannot throw all sorts of info
> at the user, show him/her a big extensive set of controls all at the same
> time and hope he/she can figure it out. We have to take the "overload
> factor" in account -- I know the concept of "task loading" doesn't fit quite
> well here, but if you have heard of this concept, it's a similar principle.
> To avoid the user being overloaded , attention must be paid about the order
> of presentation, and of when does it make sense or not to show something or
> make a menu item available to the end-user. For example, the menu brought
> out by a right-click on the desktop could be visually simplified: do we need
> little icons besides the menu items in a pop-up contextal menu?

It is with these intentions that the KDE Usability Study was born. The 
intention is to streamline the usability of KDE and how the user 
interacts with it.

> Besides the desktop contextual-menu, another place where some serious
> thinking needs to happen is with the panel at the bottom of the screen
> (KPanel ? I've just looked at the SuSE 7-loaded Ultra-SPARC I have in my
> cubicle).  All those quick-access buttons (shell, control centre, misc.
> KOffice applications, etc.) did confuse all those not familiar with Linux
> that I tried to introduce to Linux, can be viewed as cluttering the panel to
> the point of making it intimidating and harder to use at any screen
> resolution lesser than 1024x7something.  Why not put these quicklaunch
> buttons into a quick-launch pop-up menu, with a lightning bolt icon?  SuSE
> did this with its v7.0 distro (KDE 1.1.2), I found it to be clearer to
> understand and to make the panel more appealing.
> 
> Going back to the "avoid overloading the user with unessary controls" thing:
> I guess the main culprit here under KDE2.x has been the control centre.
> There are so many control items in the left-most scroll-list of the control
> centre that it makes it hard to zoom in quickly to what you want to change
> and one can say that it is intimidating to people new to KDE.  Since some
> control/configuration items will be used more frequently than others, that
> some controls can be considered more "advanced" than others, it should be
> looked into showing the most-often used controls first, without the more
> advanced controls in the way.  Maybe the use of tabs could do it?

KControl is an area in which maybe more specialised research could be 
done. Whn we do the study we will try to profile users as best we can, 
and it may be an idea to profile KDE use. System configuration could be 
one use.

> What does not help either is the apparent amount of repetition and/or
> misplacement of things I have found in the KDE 2.x UI: on my KDE2.1 Debian
> box, why is there a /K/Preferences and a /K/Control Centre ?  Shouldn't
> /K/Editors be in /K/Applications/Editors? Likewise, the same can be asked
> about /K/Toys, /K/Graphics and all the other similar sub-menus.  I think
> that TPTB should look into the structure of the "K menu" to clean it up --
> or at least that it should be discussed.
> 
> KDE 2.x is quite neat, but I'm sure it could be made even more neat (dare I
> say "really cool"?)  with just a few modifications here and there...

*All* software can be improved. We just need to agree on a decent 
organised system of testing.

Would you be interested to help the study and move towards a better 
KDE? We could use *all* kinds of help, and your assistance would be 
appreiciated. If you can help, are there any particular areas that 
interest you?

	Jono

Jono Bacon - [vmlinuz] -- jono@kde.org
KDE/Qt Developer


_______________________________________________
kde-usability mailing list
kde-usability@master.kde.org
http://master.kde.org/mailman/listinfo/kde-usability

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