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

List:       kde-usability
Subject:    Re: The art of not offering customization
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-05-29 17:49:06
[Download RAW message or body]

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

On May 29, 2002 10:56 am, Poletti, Don wrote:
> One issue that this brings up, and has been mentioned by others. We
> can adjust the individual dialogs till the cows come home but the
> overall division needs to be fixed.
>
> I think they're are 2 approaches.
>
> 1) Go as we are. Fix each dialog to simplify matters. then attack
> the larger issue of what goes where. This has the advantage of
> quicker results.
>
> 2) Start from "scratch" and layout the dialogs according to user
> needs rather than from programming.
>
> ok well maybe a third approach would work too. When redesigning
> dialog we should be afraid to combine or re-order dialogs. I suggested
> moving the background dialog into the desktop but didn't hear any feedback.

i suppose you meant "we should *not* be afraid to combine.." and i'd suggest 
that would be the best approach. it gives us some of the benefits of both of 
your first two suggestions...

for instace the taskbar kcm: someone was talking about adding it as a tab to 
the kicker kcm ... there was general agreement that this should indeed occur. 
the reason i haven't simply slapped it in there is that there are one or two 
technical issues to deal with, primarily the fact that selecting "configure 
taskbar" from the taskbar's menu opens up that dialog. it would be nice to 
refrain from duplicating code, so some way of sharing at least the source if 
not the binaries needs to be arrived at.

this isn't a big deal, it just needs to get done.


> I think the whole look-n-feel subdivision may be wrong. Everything about
> a gui is look-n-feel. I'm sure what should be the major divisions or even
> if we should have them but I think this list should start discussing the
> big picture. There are a lot of repeat arguments because there is no
> big pictures nor guidelines for getting us there.

a good project for an ambitious non-coder (or three =) might be to go through 
each and every kcm and make a listing of all the features, what they do, and 
where they currently are. from there, map out what the conceptual 
relationships really are between the options. then, based on that mapping, 
come up with a suggested organization of the features and provide a 
comparison to what currently is there.

thoughts?

- -- 
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)

iD8DBQE89RSS1rcusafx20MRArxuAKCS2wQ1e+vs7FqlN+FQRqIMi/bc0wCfYfD7
1r38qhDyaYRAhxetTzkA2JM=
=yqFz
-----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]