[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: Single vs Multi Window KControl
From: Frans Englich <frans.englich () telia ! com>
Date: 2004-08-20 20:23:34
Message-ID: 200408202023.34376.frans.englich () telia ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic