[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-19 21:43:21
Message-ID: 200408192143.21975.frans.englich () telia ! com
[Download RAW message or body]


Yes, a late reply. I haven't found the interest for it.

On Sunday 01 August 2004 00:01, Aaron J. Seigo wrote:
> 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.

What you're saying is "KControl have always violated the HIG, and I don't see 
why we should continue so". That paragraph in the HIG is unambiguous, and you 
can start a separate thread questioning its relevance -- and I and others 
will explain why it is important to users with small screens, and all other 
users. You will have to elaborate beyond "bah" and why that HIG paragraph 
should be ignored(is there anything else in the HIG which you say "bah" to, 
and which we should know about?).

>
> > and also have a good navigation
> > mechanism.
>
> MacOS X. sorry to keep repeating this in this email, but they did it. so
> can we.

We can't use that kind of arguments, it will end in in madness. For example, I 
can find some vendor that uses my idea, use your argument, and then we can 
rant about whom's "backer" which is most important. Let's debate with 
theoretical arguments(the ideas itself) and independent user reports(as 
should be done in any other case).

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

You can say that about anything, if, as you do, assume it's a non issue. 

> by making it harder to use,

Your assertion without rationalis. 

> 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.

I'm not saying it's a "nice thing", so don't state that. I argue it is good 
for regular users(not bells and whistles), and that is what you will have to 
confront. It is confortable for you, since you "give me an argument" which 
suits you, and which you then can defeat.

>
> > * 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.

I have no access to Mac OSX, I've seen screenshots on the main layout with the 
icons -- more or less what Benjamin and I have done, but not the navigation 
mechanism. Do you have screenhots/links illustrating that?


>
> 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, 

Good point. But I would consider it quickly learned. It should also be 
remembered it is just as arbitrary as KMail's Inbox/Message areas, and 
Konqueror's main area/navigation panel.
It is possible that the interface could be changed to better communicate the 
relationship(labels for example), but the overhead could also be worse than 
the "trial&error learning". User testing could solve such a problem(perhaps 
relevantive can do it, if it becomes relevant).

> 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.

Right, I also prefer a main area where all categories and all their contents 
are shown at once -- but KControl have 59 KCMs, 10 categories(excluding 
Konqueror's 'Web Browser' with 10 entries). I would prefer the one you 
describe but it doesn't fit in reasonable. I assume Benjamin wants such a 
solution too, realized it didn't work, and put the the categories' content in 
the dialog's icon list.
I've removed 6 KCMs by removing/merging duplicate options(and actually removed 
only one option which was a security concern), and written one new KCM.  
There's not a high political pressure for keeping KControl's content small 
and relevant for regular users, and until that changes we have a huge 
KControl(KAdmin or not). However, with an icon view we're in the right 
direction since it easily allows an transition to the Mac OS X 
approach(assuming I've understood you correctly).

But try to show all categories and modules in one window -- it doesn't work. I 
tried, and Benjamin tried probably too, and we found alternative solutions 
instead.

> 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 ;-)

Indeed, and then you would have vote as in "opinion"(we two aren't voting, 
we're trying to solve a problem). I'm trying to fold in feedback from the 
corporate side, those who are closest to our users. Well, let's hope they 
aren't lurking.

>
> 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?

First of all, don't snip like that. That sentence continued with "-- the 
window paradigm is fundamental."
My point, especially with the second part, is that saying "using configuration 
dialogs is confusing and a big no no" is like throwing the absolute core of 
graphical environments in the bit bucket. Windows are fundamental, and my 
approach is just as good/worse as that. In other words, if it's unsuitable to 
use configuration dialogs in KControl, we should rethink how configuration is 
displayed in normal applications(Settings->Configure App...) and the windows 
paradgim in general. And AFAIK, those config dialogs in apps works fine.

> 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.

I won't discuss KMail because that's a completely different scenario -- it can 
be suitable for its task as you say. The question is whether MWs is suitable 
for KControl's task, so let's discuss that. 

>
> 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 

I'm not arguing that. The ability to have multiple config windows appeals to 
power users, AFAIK -- which I couldn't care less about. I wrote that at the 
end of the previous mail:
"I prefer MW because SW hinders efficient navigation, not 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."

If you find that important, it's your argument, not mine, and you can hence 
not argue against me on that point.

I like MW because of it's navigation properties, I don't think people have a 
need to put away a window, in the way as a word document, when they are 
configuring. 

> #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.

Further above, you write I take away the #1 strength of having multiple 
windows. Here, you write it's not needed, which is agreeing with me. You 
broke the paragraph right after my negation("efficient navigation, not"), and 
since my argument then says the opposite, you opposes and says exactly the 
same thing as me("people don't need multiple configs open"). 


			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]