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

List:       kde-usability
Subject:    Re: Kcontrol proposal - screenshot
From:       daniel nagore <daniel_nagore () eresmas ! com>
Date:       2002-09-13 17:48:39
[Download RAW message or body]

El Vie 13 Sep 2002 05:30, Michael E. Peligro escribió:
> On Monday 09 September 2002 06:58 am, Waldo Bastian wrote:
> > > > > What do you mean with "nested groups"? A 3 level hierarchy? Why is
> > > > > that so bad?
> > > >
> > > > because users grapple with trees as it is, making them deep trees
> > > > makes the problem quite a bit worse. at least according to the stuff
> > > > i've been reading about trees.
> > >
> > > http://www.sapdesignguild.org/community/design/hierarchies.asp
> > >
> > > Go down to "People and Hierarchies" for more info on this topic.
> > > Replacing depth with breadth is a recommended strategy for making trees
> > > easier for people. If depth is becoming a problem we might have to
> > > consider adding more items on the top level.
> >
> > I think the biggest problem in the control center is:
> >
> > "The Underestimated Importance of Category Names
> >
> > Category names are more important than many developers believe. From a
> > user's point of view, however, well-chosen category names are essential
> > for them when searching items in a data set. Names or labels may be
> > responsible for a user's success or failure at finding an item. Much time
> > can be wasted if users randomly browse data sets without any sense of
> > orientation. Even more time is wasted if they fail altogether to find
> > what they are looking for."
> >
> > But that is what we are currently working on.
> >
> > One of the complaints against hierarchies that gets mentioned is: "Deeply
> > nested hierarchies cause even more problems because people get
> > disorientated." But I don't think that applies very much to a 3-level
> > hierarchy, that's hardly "deeply nested". Also the risk of getting
> > "disoriented" is greatly reduced IMO with the treeview because it shows
> > the user where (s)he is at all times.
> >
> > The other complaint against hierarchies is that dymanic hierarchies are
> > disorienting. But the control center isn't dynamic it is very static.
> > (And after 3.1 it will hopefully not change in any major way for several
> > releases)
>
> Here are my thoughts on tree views.
>
> Most developers think along the lines of modularity, instantiating and
> keeping track of child-parent objects. Sometimes this bias spills over to
> user-interface design. And to think along those lines is logical for them.
>
> Most developers often think of "abstract", "container" categories and
> sub-categories, so to speak, because if one programs in C++, one needs to
> understand the hierarchy of objects.
>
> The hierarchy of objects is logical, yes. But to implement the logic of
> hierarchies in the form of tree views and categories in the KControl is not
> always a good usability practice.
>
> Developers logical grasp of things .
> Categories, sub-categories
>         Application - main window - child objects
>         Kspread - spreadsheet area - rows & colums - cells - cell format
>
> Users on the other hand, are task-oriented people and want fast access
> "shortcuts" to commonly used tasks first.  
>         Edit, Delete, Insert
>         Edit cell, delete rows & columns, insert graphic, print a file,
> etc... Adjust Printing (Cups), Adjust Fonts, Adjust Mouse Settings
>
> This is the reason why the Windows Control Panel is more logical and
> user-friendly than KDE's Control Center. Frequent configuration tasks
> involve configuring printers, fonts, hardware, so the Windows Control Panel
> is task-based (Add/Edit/Remove -- Printers, Users, Hardware,
> Multimedia..etc). Using a flat, view all icons for immediate access also
> makes this easier. Want to change the mouse settings? They see the mouse
> icon, click, instant access. No time wasted thinking about what category
> the mouse settings belong (Peripherals). Users don't need to think about
> this category in the first place.
>
> Contrast this now with KDE's Control Center, where the first thing you see
> is a tree-view at the left with no initial icons in the center pane.
> Presenting a tree-navigational view is typical of the way developers think,
> categories and subcategories. Users when presented with this panel find it
> hard to navigate since they have to think what major category their
> intended task belongs to, and this is where confusion sets in (like,
> where's the mouse settings? Does mouse settings belongs to Personalization
> category? System category?). So a user is delayed because he is
> unecessarily forced to think of the category that his task belongs
> (tree-view effect), instead of giving him immediate visual information
> (displaying the icon) and access to it. The user is not very concerned with
> categories (only developers). The user also does the extra work of wading
> through every branch in the tree to find where the controls are.
>
> It is also far easier to recognize than to recall. Plus, it's more easier
> to remember visual cues instead of words. Putting these two together is
> even better. (Icons over text).
>
> So the Windows Control Panel uses our greater ability of recognition
> (seeing the icons and text immediately) and provides immediate access to it
> (no wading through the tree structure).
>
> KDE Control Center tree view has icons and text, yes, but it forces you to
> unecessarily think of categories (tree-vew display) before you get to your
> desired task. And that is bad for usability.
>
> I suggest that we reorganized the KControl. Instead of the unhelpful
> startup page of KControl ("Welcome to the KDE Control Center, a central
> place to configure...). The startup page should contain icons of "commonly
> and frequently" used controls, like mouse settings, font settings, network
> settings, sound settings, background settings, desktop settings,
> etc...(much like in Windows Control Panel). However, we retain the tree
> list view in the left for flexibility.
>
> Lycoris has an excellent and very user-friendly tree-view categories in
> their version of KControl. These are neatly arranged with the commonly-used
> settings at the top down to the least commonly-used.
>
> Tree views on the left PLUS a startup page of icons  for "commonly-used"
> settings in the center will be better. The icons in the center will provide
> immediate access without forcing the user to think of categories. The tree
> view at the left, if done like Lycoris' hierarchy, will likewise provide
> another way to access these controls. In that manner, power-users and
> newbies will feel comfortable with both approaches.
>
> Regards,
> Michael

Amen :)

Good way of think. I hope all the kcontrol developers will think about your 
post.





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

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]