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

List:       kde-usability
Subject:    Re: Single vs Multi Window KControl
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2004-08-01 0:01:55
Message-ID: 200407311801.56142.aseigo () kde ! org
[Download RAW message or body]

On Saturday 31 July 2004 05:17, Frans Englich wrote:
> * If we go for SW by having the navigation mechanism positioned outside the
> module viewing area(as our current kcontrol) it is hard to make KControl
> live up to the 800x600 requirement[1]

bah. we've done it with most kcontrols up to now and i see no limitation on 
doing it with all of them.

> and also have a good navigation 
> mechanism.

MacOS X. sorry to keep repeating this in this email, but they did it. so can 
we.

> An MW approach, as the two currently proposed, easily lives up 
> to that KDE UI Guidelines paragraph.

"easy way out". by making it harder to use, we make the windows a few dozen 
pixels smaller. i don't think that's a worthy trade off.

> * If we go for SW by fully hiding the navigation layout(which will be

>     * It makes learning easier
>     * It makes navigation easier since time is not spent on relocation
>     * It provides a feeling of solidness and comfortness; the navigation is
> stable, looks the same, and is a "reference spot" the user always know. It
> never suddenly disappears, and will always be visible behind the
> configuration dialog since they are smaller than the main window.

yes. and it's easier for the majority of users for whome multiple windows are 
a major pain rather than a nice thing.

> * MW means faster navigation since the navigation mechanism is not
> hidden(not faster as in how the user physically interacts, but the need of
> scanning the interface).

i couldn't agree LESS. please, look at how Apple did it on MacOS X to 
understand just how quick and slick a SW implementation can work. you assume 
an "either / or" situation where we either show ALL nav or show NONE. this is 
ignoring other options in between. think in colour, not black and white.

when i was engaged in KControl discussions on this very list last year i 
described quite clearly how one does not need to show ALL the navigation ALL 
the time for it to be navigable.

and again, MacOS X proves this point conclusively.

> Having the content of categories as an icon list in the configuration
> dialog[2] has the same drawback. The category cannot be viewed without
> opening a dialog and that makes Trial&Rrror and navigation in general much
> slower. 

agreed.

> However, the positive side is the "main" navigation then can be 
> made simpler, but I think the cost is too high. I solved it by adding an
> additional icon view[3] -- the window is still small and the layout is
> simple.

and there is no obvious connection between the top and the bottom. this is an 
interface that must be learned, and one that is not capable of exposing as 
much as the user wishes/needs (only one category at a time)

there is probably little to NO need to emphasize categories nearly so much by 
giving them that much screen real estate.

move out SysAdmin to the KDE Administrator's Tool (which should be MW) and 
we're down to 7 groups that should be easily displayed at once WITH the most 
important control panel destinations in each displayed.

> * Xandros' CTO explicitly states in an interview they prefer MW in
> KControl[2]. I don't know why they prefer it, but that is a vote for MW
> from a major linux distributor which targets regular users.

perhaps i should go get a job as the CTO of some minor distro too ;-)

Xandros, btw, is not a "major linux distributor". they are a small fish in 
that world. important to us as a valued user and promotre of KDE, but let's 
keep some perspective.

> * Someone stated MW is confusing for new users. 

that'd be me. =)

> Having a MW KControl  is 
> just as confusing as the desktop in general 

oh, so we should make it worse? and we should ignore the fact that many users 
simply use maximized widows and switch between them using the task bar, which 
renders the "they are used to it" idea moot, since they are realy _working 
around_ the problem rather than _getting used to it_?

> infinitum -- if that's ok, it must be alright with it in KControl too. It's

ok. so why does kmail have an all-in-one interface, like most every other 
email client? why does it put things all in different windows? because for 
the TASK it's more efficient. it does have popup windows (config, wizards, 
etc) and so do many control panels. but it keeps the main activity interface 
sane and well sorted.

something Apple mucked up on in MacOS X was putting the folder list in 
Mail.app in a "joined at the hip" sub window, specifically because this task 
really is well suited to a single window paradigm.

or we could go on to consider why tabbed web browsing is so amazingly popular 
among experienced and unsophisticated users alike once they discover it.

> like ordinary configuration dialogs, not worse. Remember, the configuration
> dialogs are, just as the ordinary ones, smaller than the main window, and
> always above the main window -- the former gives a sense of control, and
> the latter ensures they don't "dissapear" behind the main window.

you're kidding right? you want the control panels to float ABOVE the 
navigation? getting in the way, so you have to MOVE them aside to get to the 
navigation? the #1 strength of an MW approach is being able to do more than 
one thing at a time, the #2 strength is being able to access a larger nav 
area in an unfettered way and you are proposing to limit if not outright 
destroy those two benefits?

> In other words, I prefer MW because SW hinders efficient navigation, not

which is why MacOS X's SW implementation is so much easier to get around in 
compared to most MW implementations i've used? hm.

> because it allows /multiple/ configuration dialogs -- as someone pointed
> out that is used by power users, and I would like to emphasize that aspect
> should not rule our decision.

unlike a "KDE Administrator's Tool" most panels are orthogonal and needed one 
at a time. having multiple configs open (which you are thinking of hindering 
anyways, it seems) is not a useful win.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
_______________________________________________
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]