I've been thinking about some of the stuff that Frans English has brought up about KDE Control Centre. While I don't agree with some of the things he's written, there is certainly a case for cleanup in some of the hardware settings.
Some of the cleanup is going to mean breaking up some of the existing kcm's. The real culprits are some of the KMilo plugins. Make no mistake - I love the support for special Vaio features - Windows reconfigures the screen brightness on my laptop depending on power profile, and it stays stuck at that brightness level through a full reboot. Without Vaio support, I can't see what is on the screen if the last time I used Windows it was on battery (say I pulled the power supply connector just before shutdown).
But finding the module in the Control Centre still confuses me sometimes. Changing the screen brightness, or checking battery power isn't a System Administration function. Bits of it need to go into the Power Control->Laptop Battery module, and into the Peripherals->Display module. For things like the battery status, it needs proper integration (eg so it only polls APM for battery level if there isn't a smarter notification element). Similarly, some of it might need to go into Peripherals->Mouse.
I guess that there are likely some similar issues for other similar things (eg the IBM thinkpad). Certainly I expected to find keyboard shortcuts (and KHotKeys, and keyboard layout) within Peripherals, not within Regional and Accessibility.
A first step would be to make a clear definition of what belongs in what top level division within the KDE Control Centre. Re-aligning the functionality to match that division can then follow on.
Syndicate Blogs
Nice text Brad, the issues yo
Nice text Brad, the issues you mentions about the laptop KCM's is very relevant. As you say, there's two of them while they're very similar as well as they are in the wrong category - "System Administration" when they could be in "Hardware"(called Peripherals currently).
Moving those two KCMs to "Peripherals" and renaming "Peripherals" to "Hardware" is in fact already done, I committed it a couple of weeks(?) ago. Allthough, people said this kind of reorganization was too big for 3.3 so eventually it will be reverted(it's small changes anyway). We'll see how that turns out.
Further, as Brad points out, it feels like they duplicate functionality as well as their content is better situated in other KCMs. I think this is hard to code in a clean way. Until we come up with a clean solutions(and someone implements it) I have a quite satisfactory solution, if you ask me
, but it depends on my new class for kdelibs/kutils... More on that later on.
Regarding the search functionality; The fact we at all have it is an alarm bell telling our navigation is more or less screwed. When the search functionality feels redundant navigation has become acceptable. But one should also keep in mind the search functionality also provides an /alternative/ method for navigating(which is good).
I've pondered about what arendjr and cmiramon mentions - KControl have functionality which is /totally/ irrelevant for some setups. For example, multi head, laptop battery or the laptop KCMs.
One solution is adding a plugin system to KPersonalizer which probes(only prompts the user if necessary, of course) the installation for hardware/software and then disables the KCMs but that doesn't work because the settings can be session specific(centralized settings, roaming clients). Another solution is to add a directive to the KCM's desktop containing a command line which lets the the exit code decide whether the kcm should be shown or not(run on kcontrol startup) but that's too simple - the probing KCMs needs to do are too advanced for fitting in a little shell script.
The solution I (atleast so far) think holds is to add an boolean directive to the desktop file which says "I need to probe" and a static function to KCModule. When KControl starts it puts KCMs which needs to probe in a separate list and loads the GUI with the "normal" KCMs, and then after the gui is up iterates through the probing routines and adds "afterwards" those KCMs which also needed to show up(anything else would kill KControl startup performance, I think).
Datschge mentions KControl is huge, no doubt. But, it is not necessarily the cause to its usability problems - the problem is rather that this "hugeness" is exposed to /all/ users, regardless of how relevant it is. So, a lot of improvement can be done by reducing the amount of KCMs and toplevel categories(which everyone is exposed to) and push settings back to the KCMs(make them bigger) and as a natural follow up, widen the meaning of the categories and KCMs. That's why, among other reasons, Peripherals is called Hardware(so it also can contain Laptop and other hardware and don't need their own categories). For example, it would be better if there were one KCM called "Laptop" which contained the IBM/Vaio Laptop KCMs as well as the Laptop battery one tabs - the laptop stuff would only be exposed to laptop people, while they still find it perfectly fine, meanwhile all other just have one Laptop KCM. Of course, the best would be if this stuff was autodetected.
A new version of the guidelines is up, it have changed quite a lot since the initial version:
http://developer.kde.org/documentation/standards/kde/kcontrol_style/index.html
Feedback is of course very much appreciated - drop a line on kde-usability, to me(frans.englich@telia.com) or as Brad did - write a blog entry
BTW, some KConfigXT solution for KCMs, similar to KConfigDialog is badly needed...
Cheers,
Frans
search functionality
i completely disagree with you regarding search functionality. no mater how cleverly we organize kcontrol, the only way to make it completely obvious is to rip out most of the options. thinking that we can simply stir up the options in a different structure and magically have most users be able to immediately find one out of 100s of options is delusional.
we can either rip out most of kcontrol or we can rethink our concepts of what "navigation" means completely. i'm not in favour of ripping kcontrol to shreds as that will leave us with something that covers a small percentage of the users' needs. we can't allow ourselves to shortchange the user to achieve a level of usability, IMHO.
so... we need to rethink navigation. a keyword search-driven system is probably the best way to achieve quick and accurate access. when the users says, "i want to change my mouse icons" they should be able to type "mouse icons" or "cursor icons" or even just "icons" or "cursor" or ..... and have the mouse panel listed (along with any other relevant panels).
the remainder of the navigational interface should provide a paired-down icon view of the panels, broken out into the major groups with the most common panels shown. there should be panels available that are never shown at this level; for instance, the widget style panel should not be shown at the top level, but the metatheme panel should. via the metatheme panel the user can drill down to the widget style panel via an entry in the "Related Panels" link. the panels that a user uses most often should also float "up" in prominence. this interface can afford to be somewhat lossy in presentation when paired with search and "related panels" functionality as primary navigation tools.
so… we need to rethink na
so… we need to rethink navigation. a keyword search-driven system is probably the best way to achieve quick and accurate access. when the users says, "i want to change my mouse icons" they should be able to type "mouse icons" or "cursor icons" or even just "icons" or "cursor" or ….. and have the mouse panel listed (along with any other relevant panels).
What about clicking on a picture of the mouse?
A clickable image map is one way to rethink the navigation, at least for the first click. (Obviously, for blind people, there would have to some alternate representation.)
A lot of what is in the 3.1 control center could be fit into a picture of a computer and it's pieces: Appearance and Themes, Desktop, Peripherals, Power Control, Sound & Multimedia, and parts of the System Admin (Fonts, and Date & Time). You could probably stick Regional & Accessibility in there too (when the user clicks on the monitor part of the picture).
Another area which needs quit
Another area which needs quite some focus is the keyboard stuff as Brad discusses. At a first glance it appears hilariously funny - 11 tabs spread over 4 KCMs, all for configuring keyboard and shortcuts. But after a second thought, someone is getting really excited by it..
Anyway, if we had two KCMs with two tabs each it would usability wise be acceptable. I have an old patch which basically removes one tab(yay..). I would gladly give it away..
The solution to the keyboard mess is as always - man power
Cheers,
Frans
One big problem I see with your approach...
You correctly name relevance of parts of the control centre on the respective setup as problem, but suggesting that KDE should be probing for which hardware exists and react according to this is imo beyond the scope of KDE. It's highly dependent on the system KDE is installed on, and the hardware probing part is usually job of those offering KDE as part of their system they put together, not a job of KDE itself. And as you surely know it's very easy to customize the control centre's structure accordingly.
Sure it could.. I think it is
Sure it could.. I think it is reasonable if the presence of a KCM depends on whether the hardware is there or not. It makes perfect sense. The Display KCM does it partly already.
Also, this do belong in KDE because this is all just GUI stuff - it's not about interacting with the hardware or is engineering wise a Bad solution.
Cheers,
Frans
Improving & promoting KControl's search capability
First of all KControl is only intended to be a one stop place for all kind of settings, all existing context dependent settings you get in apps' settings menus and in mouse right click menus should be generally suggested and preferred wherever possible.
With this in mind I think we should stop "cleaning up" by "rearranging" the stuff in Control Centre for the hundredth time but instead using a different approach more capable of handling a large amount of options: Make the search tab in KControl the by default activated tab. If you think it's insufficient in the current state it should be improved. But please no more rearranging efforts trying to make a complete library looking less huge than it really is, for a purpose the Control Centre actually never was intended for.
KControl for non-apps
As I see it, application configuration is one thing, but there are a number of features in the KDE Control Centre where they are the only UI available - there is no right mouse click or menu bar to hold a Settings item for the mouse control, or for display settings.
If you don't want to put that configuration into KDE Control Centre that is OK, but we then need to refactor the design so that we can have a sensible and intuitive way of getting at the required information.
Further, for things like laptop control, it doesn't really matter exactly how we access it, but it is important that there aren't two applications/applets both trying to do part of the problem. That is surely the path to user confusion.
Sorry, I definitely think it has to be changed.
The question is...
...what needs to be changed. Rearrangements had been done plenty of times already and they didn't improve much except making those familiar with the old structure having to learn a new one again.
What we need it alternate approaches which are better at handling the big amount of controls (since they are more likely to become even more in the future, not less than now). One I mentioned is making the search tab default so when someone wants to search something he actually does a search instead going through all settings manually like it seems to be popular atm. Another approach could be giving KControl a default interface similar to what Apple did with its control center, ie. show all icons grouped by category in the content area and using the side pane for one icon turning back to that main view followed by the most used subviews.
Optional modules?
Personally, I'm not really bothered by the fact the Vaio settings are a seperate module. What does confuse though is why I have a module for Vaio settings while my machine is far from a Vaio
--
Arend van Beelen jr.
http://www.liacs.nl/~dvbeelen