[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-05-22 21:10:07
[Download RAW message or body]

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

On May 22, 2002 01:25 pm, Thomas Zander wrote:
> >  o there is both a listing of desktops to select from AND a set of tab
> > widgets. this means the user must track two sets of mode changing
> > widgets. this is far too complex.
>
> Hmm? That is used in many places in KDE, I have only heard very good things
> everytime I introduced a schema like this.

you're obviously talking to the wrong people then. or confusing requirements. 
where else is this layout style seen?

allowing control of the current context to be controlled simultaneously by two 
otherwise seperate widgets is very difficult to understand.

> In fact this is something you can not get around unless you provide all the
> widgets now in tabs on one screen.
> And please don't tell me that makes it more usable, a screen full of
> widgets never is more usable then well grouped tabs.

yes, they can be. you are correct that a random arrangement of widgets filling 
up the entire screen can be butt ugly, but tabs are not a magic wand. in 
fact, a single page of well laid out and well chosen widgets is better than 
tabs, while tabs are better than chaos.

btw, tabs that are subcomponents of a page, as they are in the background kcm, 
border on chaos.

> > the Setup... button even
> > changes meaning if you choose "pattern" vs "background pattern". hardly
> > usable in that state. the user should be able to look at the options and
> > see corelations between the different options and their sub-widgets.
>
> I agree the 'background program' and the 'patterns' don't belong in this
> section.  That puts the setup button also 'out of place'
> This indeed needs fixing; what about 3 radio buttons, a rename of
> 'Mode' to 'Gradient mode' and using 2 setup buttons for the 'program' and
> 'patterns' would be more suitable.

which is exactly what i did in the draft layout i had posted ... which, btw, 
can be seen now at:

   http://urbanlizard.com/~aseigo/background.html

> Right; good points.
> Adding a list on the same dialog is not an option IMO, it takes too much
> space. So a seperate dialog is still needed for your list. (that dialog
> needs work as well, but thats a different issue)

really? take a look at the draft i threw together... it doesn't seem to take 
too much space ..

> This then means it still is usefull to provide the single background image
> in a combobox for 2 reasons; 1)If you only have one, you dont want to open
> the dialog to see the name.

having two widgets that control the same thing is not good.

> 2)selecting an image is done really nice since
> the preview is updated immidiately as you walk through the combobox.

which is also really slow, btw... at least on my system.

> I would suggest to make a checkbox to select wallpapers being on, and
> placing the single/multiple radiobuttons in front of the respective
> options. This is seen best in the proxy kcm.

which is also broken design IMO. why isn't there simply a "No proxy" option in 
the Configuration box?

> >  o advanced tab: blending refers to wallpapers as can be seen by it
> > greying out when you select no wallpaper. what is it doing on the
> > advanced tab?
>
> This is not true; it blends between the background-color and the wallpaper.
> If you choose no wallpaper the current implementation does not even allow
> you to change your blending.

exactly. so if it is controlled by the wallpaper setting it should be with the 
wallpaper settings.

> The limit pixmap size is needed for people with a limited amount of mem.
> And yes; it belongs on the Advanced tab :)

hrm.. ok.. 

> The slider can be below the 3 radiobuttons with its label at the same
> horizontal position as the radiobuttons.

again with all the radio buttons! this can all be put in a single combo box. 
please repeat to yourself: "more widgets == bad things"

> Agreed; and I probably was a bit too quick to tell you guys you were wrong.
> I do think that the intentions of the application were not converted into
> the GUI properly with the previous designs; please take a moment to see
> what the application programmer wants to offer feature wise.

right now there are only two things not in the current draft:

 o patterns
 o pixmap cache settings

pixmap cache settings should be put in an advanced dialog (to avoid tabs), as 
you said. 

as for application programmers wanting to offer features, sometimes they 
should be a good enough programmer to know when to say "no." patterns may 
well be one of those types of options.

> I hope that you are willing to try another design using some of the points
> I think are wrong in your design proposal. I also believe all problems will
> be solved (tm) if you follow the above suggestions.

i respectfully disagree with many of your suggestions, but am working those 
which i do believe are valid into my working draft ... 

thank you for your input as it is very useful and important to have.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE87Akw1rcusafx20MRAou8AJ9L09cLNVu4elHypqHgXV7tMuEKlQCfbX7F
A3SvUBjqtX0aNVEKYfcvuNc=
=FWVW
-----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]