KDE Control Center
Aaron J. Seigo
aseigo at olympusproject.org
Sun Aug 4 21:49:33 BST 2002
-----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-----
More information about the kde-core-devel
mailing list