KDE Control Center

[Aaron J. Seigo]

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

On Sunday 04 August 2002 01:17, Gerold J. Wucherpfennig wrote:

first, the "reply to proposals" bit:

> 1. The "Panel" - settings
>
> This tree is already accessible with "K->Settings->Configure Panel", so
> it can be removed from the Control Center (hidden).

and then explain to users why they can't configure the panel from the control 
center? one of the strengths of the kde control center is in inclusivity; if 
they want to configure something they go the control center. 
K->Settings->Configure Panel is pretty hidden compared to the control center.

no, this would simply relocate the problem by spreading things out into 
different places along seemingly arbitrary rules ... the goal shouldn't be to 
make kcontrol sparse in a bid to make it "easy", but to make kcontrol 
accessable so that configuration needs are met.

> 2. "Configure Konqueror"
>
> "Configure Konqueror" should include the "File Manager", "Web Browser"
> and (partly the) "Network" tree.

we would then require users to figure out that konqueror is the file manager 
and the web browser (believe me, many people don't get that) ... 

also, some of these settings apply to more than just konqueror. the network 
tree is quite general to the desktop, in fact...

> 3. Create a "System Center"
>
> Non-KDE Items should be put into an independent "Control Center"
> named "System Center". This already happend to the "Information" tree
> which has been put into the "Information Center".

this assumes users can figure the difference between "system" items and 
"desktop" items. i do agree that this approach can work along certain lines, 
e.g. information, desktop and applications (konsole, krfb, knewsticker, etc)  

- --------

now, the "observations and discussion" bit:

> Some suggestions about restructuring the KDE Control Center.
>
> <intro>
>
> Imagine to be a computer newby who's looking at the KDE Control Center
> for the first time.
>
> You look at the 15 top level items on the left:

> And you see that most of these items have even subitems!
>
> </intro>

yes, the current reorganization has merely replaced one type of complexity 
with another. it hasn't ended up with the removal of the look 'n feel 
category (though i remember that being one of the goals) and has given us 
categories such as "advanced" (what belongs in advanced? more importantly: 
how can a user guess what will be in advanced so they can find it? what do 
the advanced items have in common besides an arbitrary judgement of 
difficulty?)

worse yet are the fact that many of the subitems you mention are now rather 
incoherent as they were simply plucked from their original context without 
making changes to compensate for that change in context. example: open the 
appearance and behaviour pages for the desktop and please explain to a user 
why the icon preferences button is in appearance (and takes you somewhere 
that appears rather unrelated at first glance to the desktop!) while turning 
icons on or off in general is in behaviour! at least before they were on 
seperate tabs of the same page, now they are in completely different panels!

even more absurd is the the system / power control / show power control path 
now in the control center

these changes attacked the right problem from the wrong angle. i've been 
trying to think of easy ways to fix it (so that it would fit within my 
personal KDE coding time/energy constraints), but i can't. every time i 
examine it i can't help but feel that there are a couple hundred hours of 
solid hacking required to get it from where it is now to where it should be 
(e.g. better than the way it was).

> The amount of items should be reduced IMO

i don't believe that this is not the real problem, rather  it is merely a 
symptom. the true problem includes: poor naming of the panels (what is 
behaviour?), poor distribution of the options, poor hierarchy design, lack of 
integration testing (e.g. simply splitting up the kicker panels created 
several bugs as the original design of the panel was not taken into 
consideration before hacking it into seperate panels as if with a meat 
cleaver).

previous to this round of changes i had gone through and counted duplicate or 
redundant panels and figured we could eliminate probably a quarter of the 
panels through combination and reorganization while reducing the complexity 
and increasing the clarity of each! the problem is only more poignant now.

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

iD8DBQE9TZNe1rcusafx20MRAi12AJwKGaTRdtcd/JTRDUxzBCTokF/0sgCeNZst
Wg3Ovooe7iBOWmCOWHLCibA=
=YqR7
-----END PGP SIGNATURE-----