The followup to Aaron started getting long, so I address some other issues in 
this letter, especially William's and Segedunum's comments. Again, apologies 
for the late followup.

William's comment about the Multiple Window(MW) approach causing a flood of 
entries in the taskbar doesn't apply because QDialog derivatives doesn't have 
taskbar entries. When one window receives focus, all of them pop to the top 
-- they act as one unit. However, if they had a taskbar entries.. Trying the 
actual prototype helps.

William's comment about annoying windows popups is also interesting(it's a 
major problem in KDE, IMO). Windows/popups thrown at the user are annoying 
when it is unexpected and not wanted, e.g. not a user activated event. For 
example, a system modal dialog which shows irrelevant content is truly 
annoying, but the appearance of KMail's main window is not, because it's what 
the user is looking for. Similarly, a configuration dialog in KControl is 
what the user literally asks for.


Regarding navigation, I will elaborate a little.

I think there is a consensus on the icon view as representation of either 
categories, their content, or both, especially because of its Fitts' 
law-properties. 
When a module is viewed with kdelibs running the new_kcm_code branch, which 
means KDialogBase's size is respected, it is clear a module easily covers an 
icon view containing ~13 entries(a minimum of entries AFAICT; the categories 
and the average content of one category) with reasonable icon size. On top of 
that, we should remember the KCMs needs more space than the restrictions of 
new_kcm_code, and it's not that there's a big interest for fixing existing 
KCMs. Furthermore, KControl is huge: a mechanism which switches the content 
of a category is necessary -- as Benjamin's and my prototype shows. Skipping 
the icon view and show everything(about 60-70 entries) would result in 
information overload(KAdmin or not).

Regarding MW, it is not an custom made solution, but a well established 
approach which the user knows. People compare it to why tabs are popular, 
multiple Konqueror windows and so forth, but the cases are incomparable: 1) 
The user doesn't switch between a MW-KControl's main area and an open config 
dialog, like between two web browser windows; 2) The windows types are 
different, we're talking about a main window+dialog and not main window+main 
window. Multiple windows is not a crime and solves the navigation task just 
as good as normal configuration dialogs do for applications. It's not 
confusing like two application-windows; dialogs stays on top and are smaller 
than the main window  -- that's why the usual MDI-is-confusing argument have 
a hard time to apply.


Aaron, you opposes a MW approach, says a SW navigation solution doesn't have 
to be "black & white", but we don't know what solution you have in mind, and 
what it practically means. What we know is our proposals are wrong, but you 
haven't shown what is better. Could you do an exact description of the 
solution you prefer(emphasizing the SW part) or a prototype, like others have 
done? That would bring new ideas, something to actually shoot down and show 
what you actually are talking about.
I found this screenshot of Mac OSX:
http://www.maccrazy.net/images/features/insidepanther/systempreferences.jpg

Do you mean exactly like that?(or what differs?)


I think, one thing we must look out for is the "make it configurable" 
"solution". There _is_ a real solution to this problem( :) ), but we just 
haven't found it yet, and we shouldn't resort to "let's make it configurable" 
as a "solution"(e.g. because we cannot agree). We can do better than that.


			Frans

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability