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

List:       kde-bugs-dist
Subject:    [Bug 109581] [USABILITY] Control center module is unintuitative
From:       Stefan Winter <swinter () kde ! org>
Date:       2005-08-03 19:34:16
Message-ID: 20050803193416.13837.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=109581         




------- Additional Comments From swinter kde org  2005-08-03 21:34 -------
[dynamic number of configs]
> I haven't checked this out, but if it's just a spinbox with 'number of
> configs,' that's not sufficient or intuitative. 

Well, it's exactly that. I am aware that you want to have this solved by using the \
XP-style clickable list of networks.

[Global vs per-config UI]
> Right - but that's not enough. Generally, when you select a tab, the entire
> visible area changes, and borders are often used to group related elements in
> a single pane. Even as an experienced user, I had to fill in some values and
> switch tabs to see what changed. The average user will be hopelessly confused
> by this interface. 

I wasn't aware of that. I will at least group the global settings into a box or \
something so that you can see they belong together and are a completely different \
part of the UI. I am aware that you want to have this solved by using the XP-style \
clickable list of networks.

["Config n" is confusing when selecting config]
> Read my suggestions below - I provided suggested solutions for every problem
> I identified. 
> In this case, it was a list of network configs with icons for speed/crypto,
> which should be enough to identify which config is what.

As I said, there may be cases that show you identical tuples of (network \
name,speed,crypto,pm) and are thus undistinguishable. And _that_ is confusing. \
Consider a network that has four different WEP keys per Access Point. Both have the \
same SSID, both have WEP enabled. Which one is which in that iconized list? Same goes \
for situations where PM is enabled but _differently_ configured for two configs with \
the same SSID. This is one reason why I wouldn't like that XP-style clickable list.

[many tabs are tough]
> Dump tabs in favor of showing configs in a listbox, like I suggested. 
I am aware that you want to have this solved by using the XP-style clickable list of \
networks.

[importance of scripts vs. PM settings]
> Right - but think of the Average User. They are much more likely to want to
> set up PM (with a nice GUI) than trigger scripts. 
> I'm not saying that scripts on connect isn't handy, just that Average User
> won't know what to do with it, and they will be more likely to understand and
> want power management. 

As I said before, I generally don't like qualitative statements without backing up. \
Who are you again that you know what John Doe thinks and finds important? I will \
happily believe you after conducting some poll a la "what is more important/do you \
use more for your wireless network configuration: Network initialisation scripts or \
power management options?". Since I don't know it either, I will but the two on equal \
ground, behind that configure button I spoke about.

[WEP hey vs. string and input]
> I don't think a GUI for network configuration is the place to mitigate the
> risks of WEP. 
> You shouldn't need documentation to learn the format - the whole point of a
> GUI is that stuff like that should be obvious. 

Right, that's why the format is auto-detected in KDE 3.5 (I mentioned that earlier, \
didn't I?).

[PM]
> That's fine. This is clearly a wishlist item, but there are definite
> scenarios where I want PM or no PM on a per-network basis. E.g. home, no PM,
> coffee shop network, I want PM. 

I don't really understand your comment. I was going to leave it exactly the way it is \
now. And that _gives_ you the possibility to configure PM per network (i.e. for the \
at-home setup and the coffee shop).

[Crypto icon]
> No - this is for the list of configured networks, not detected networks. If
> you select crypto for a specific config, it appears in the list with a locked
> lock icon, otherwise you get an unlocked lock. 
 
Well, this is perfectly feasible, but would be of relevance when used in combination \
with that XP-style network list. Which I don't like.

[your description of the XP-style grouping]
> This is just common-sense stuff, and things I've gleaned from designing UIs
> myself. 

Obviously my sense isn't common.

As a general comment about the whole of your report:
You have raised many little points, of which I try to incorporate those that seem to \
make sense for me. But it seems that there is one big picture in your mind: that \
XP-style network selection box. I don't have the time nor the nerve to do this, as it \
would require a rewrite of some really big parts of the module (in fact, a complete \
rewrite would probably come cheaper). However, it may make sense the way you describe \
it. I am not a UI guru. Actually, my old layout in stand-alone KWiFiManager times was \
once cited as a "UI nightmare" by several people (Actually, with only one exception: \
one person on earth found the design "cute". And it wasn't me.). For these cases, KDE \
development people often have a very sensible saying at hand - "Show me the code." If \
you write a different module and users like it more than mine, fine. I will happily \
let you maintain the stuff and I have a beer instead.


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