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

List:       kde-usability
Subject:    Re: Configure Desktop Background
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-06-07 19:43:58
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On June 7, 2002 12:05 pm, Simon Edwards wrote:
> It looks like two separate things. How do people magically realise that
> it's the same thing? (and feel confident that they have correctly 'deduced'
> what's happening behind the scenes?)

because it uses the exact same wording and is the exact same sort of widget 
(e.g. a checkbox). and when you change it in one, it changes in the other.

it isn't like they'll be looking at both kcms side by side (though they could 
in a contrived situation) and scratching their head over which is which. 

in fact, right now, they go "control hunting", opening countless kcms in 
search of "The right one" ... where "The right one" is wherever the person 
who designed it thought it should go. unfortunately people don't think 
exactly a like and some people might expect it in place A, others in place B 
and neither can be shown to be more wrong or right than the other.

note that this is not for every, or even most, controls. just certain ones 
that stradle grey lines.

> Well, I did try to give some support to my assertion below. The stuff about
> virtual spaces comes directly from HCI research. (And I'll try to find the
> URL where I read about it. It's quite interesting actually). I don't just
> make this stuff up. ;-)

fine, but i think you're using the wrong metaphors. this isn't about objects 
in space, it is about controls.

> > because it belongs in more than one category. similar to how the same
> > page might be indexed under two different headings in a book's index...
>
> yes, but there is still one page, and you still turn to same page which is
> located at one place.

right: there are multiple entries, but they both reference the same thing.
this is exactly what i'm talking about. i'm not saying we need to have two 
pixmap caches, but that we may want two places where the user can modify that 
one pixmap cache from.

> Each control should have one and only one
> position which is 'obvious' to the average user (or at least more obvious
> than any where else).

good luck on finding those magic positions: for some controls they don't exist
people don't think the same way, and sometimes we want to accomplish the same 
thing but with a different "story" in mind..

> Another thing, if a user looks for something and
> doesn't find under one category, then will just look somewhere else. I
> don't think putting things in the tree twice really buys much.

part of the idea is to limit the need to kcm hunting for hard-to-categorize 
settings.

> > don't confuse "control" for "object".
>
> I don't think users abstract a setting from the controls that are used to
> edit it. The control is the object from the users point of view. (Although

are you trying to say that the user sees the setting to widget to turn off 
tooltips as the tooltip themselves? i think everyone figures out that the 
tooltip is that yellow thing that pops up, the checkbox controls it.

control -> object ...

> > light switches for the same light source are found in multiple places in
> > my
>
> This is a good point. But I think that the situation in the Control Center
> is more like have two light switches locate less than one meter from each
> other.

it's like having them at each doorway ... 

> Having two switches located at opposite ends of a room makes sense,
> and it is obvious what's going on. It doesn't make sense to have two
> controls for the same thing positioned so close to each other.

now you're making assumptions about a user's perception of the proximity 
between kcms ... within the kcontrol application, some might. seeing as they 
are launchable seperately and the kcontrol app is so large, i would gander 
that the percieved "distance" is greater than you think.

> Perhaps, but each extra piece of UI is another thing that people have to
> search through and ignore when they are looking for something else.

not if it makes contextual sense. you keep assuming people graze. well, 
grazing only happens when the user can't find what they are looking for (or 
aren't looking for anything at all, e.g. exploring) ... if they can 
immediately find what they are looking for, they won't need to graze

> > > Aaron, can provide a quick list of which settings are duplicated? I
> > > don't actually know, and I thought that I knew the control center quite
> > > well...
> >
> > no, because i honestly have better things to do with my time.
>
> Can you point out just one pair? I'm searching through KDE 3.0.0 and I
> can't find one in the Control Center. :-/ or is this a CVS thing?

Desktop -> Misc Options box -> Enable Desktop Menu
Style -> Misc tab -> Menubar on top of the screen in style of MacOS

you owe me 3 minutes of my life back ;-)

> But what does it do? Where is this cache? Is it in RAM? on disk? Gfx card
> mem? What? and how much mem do I have left over? Is it caching the current
> background or multiple images? I appreciate that it's for power users, but
> god damn, why should I have to read the source to find out what it really
> does? What if I really *do* need to use this setting, but I can't because I
> don't know it is what I need... The GUI could at least make some effort to
> explain what it is talking about here...

you do realize that there is a help button in that kcm, right? it explains 
that the pixmap cache limits the amount of RAM that KDE will use to store 
pixmap info (or cache it).. this is useful on limited memory systems to make 
sure KDE doesn't end up caching 50MB of pixmaps in RAM when you only have 
64MB to work with at the start... limiting it means KDE may need to read the 
graphics files off of disk more often (speed hit to showing backgrounds), but 
everything else should run faster ...

and yes, the GUI could use with some explanatory text.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler" 
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9AQz/1rcusafx20MRAgImAJwJZXKccgYFNAuXXId+A0YxO8Gu7gCgmg+A
dDvH7UdgUfJ0A5HM1GeFN5Q=
=SZmX
-----END PGP SIGNATURE-----

_______________________________________________
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]