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

List:       kde-look
Subject:    Re: Copying the Windows interface
From:       Corrin Lakeland <corrin.lakeland () xtra ! co ! nz>
Date:       1999-08-28 23:24:33
[Download RAW message or body]

> [Most gnome programs use try]
> 
> The only GNOME program I know of that uses 'Try' is the gnomecc (aka GNOME
> control center), which is a special type of program. And even then, the
> 'try' feature of gnomecc is buggy -- and sometimes fails. It's also a
> confusing interface -- a user does try, and forgets he clicked try -- goes
> to quit gnomecc and sees an error message: 'Are you sure you want to discard
> settings from the following capplets?' This error message is just plain
> confusing to most people.

Ok, I like try because I can go through fiddling with features (what do the
different themes look like, etc).  Should something go wrong I know I can
always press the cancel button to get back to where I was.

What about a compromise? What would you think of <help,apply,ok,cancel> where
we change the cancel button to cancel applied changes?  That way 
everything works as it does before except apply doesn't disable cancel?

> Some interface experts think that Apply versus Okay is confusing -- although
> once you learn the difference (click Apply once and you'll never forget it).

I found it confusing when I first saw it (in KDE).  I don't really like it but
I do use it.

> Once people have learned one way, it's to confusing to start changing
> buttons on them. I dislike the inconstantly between gnome apps and gnomecc.

What do you think of the above?

>>> This forces you
>>> to either not see half your picture or resize the main window to a huge
>>> size
>>> so you can't work on something else at the same time.  I suspect Win95
>>> created this flaw because lusers complained they couldn't find their
>>> toolbar
>>> windows and I expect a little bit more from a unix user (especially when
>>> the
>>> middle button brings up a window list and virtual screens are standard).
> 
> No... That flaw became standard in Windows 2.0. ;-)
> 
>> Second, this is not at
>> /all/ a Windows thing.  I think you are confusing the MDI of Windows with
>> the
>> "extended" SDI of KIS.  The idea is not that you will open all of your
>> images/etc in one window.  The idea is that each image window has the
>> toolbars/etc on it, and you have multiple windows, each the size they need
>> to
>> be for the image and on the desktop they need to be on.
> 
> This is common in Linux for each window to have a separate menu bar /
> seprate button bar. The idea of this is to keep the controls as close on
> hand as possible -- therefore making it easier to access program functions
> and just make your experience faster (since they are always right next to
> the Window you are accessing.

I can handle separate menu bars and separate button bars because they fit the
window exactly and so do not waste any space.  I don't like pull off toolbars
being locked because no matter where you place two rectangles, the union of
their greatest bounds is going to be greater than the area of the two objects
(i.e. they waste space).

Incidentally, I always turn the button bar off when I can and I tried forcing
the menu bar to the top of the screen but I like auto switching windows too
much and if my mouse even clips another window on the way to the screen then
the menu bar changes so I put the menu bar back.
 
>> If you just want one toolbar/etc, you tear them off... my understanding is
>> that if they have been  torn off, there is only one copy of each tool bar,
>> not one per window.

That sounds good but it seems difficult with each toolbar being encapsulated
in its window.
>> There is also a plan to let each window control multiple images via a tab
>> bar,
>> to try to get the best of both worlds...
> 
> ekk... well at least it's optional. ;-)

Like KSpread handles multiple spreadsheets? I hated that when I first saw it but
I can tolerate it now.  The main problem with it is copying between windows.

>> I tend to agree... I'd much rather see extension to the concept of embedded
>> kpanel apps than docked control panels.  The former is much more useful and
>> flexible... see http://jblosser.firinn.org/screenshots/kde/kpanel.png for an
>> idea of what I mean.  I've no idea if the patch that made that shot possible
>> has made it into 2.0 or not... I hope so.
> 
> Are we referring to kicker versus kpanel? Kicker is suppost to be a
> replacement for kpanel, but it needs much work before it's release quality.
> When done, it should be as flexable as the gnome panel.
 
> 
>> I thought the idea of making the KControl modules accessible through the
>> main
>> menu was a  really good one.
> 
> I don't know anybody that could disagree with you.

No, Several people misunderstood me on this.  I think putting the modules
through the settings submenu was a great idea.  I'm referring to things which
are in the main menu but should be (IMHO) inside the Settings menu, or things
like kfind which should be inside the utilities submenu.

>> Anyway, I think the general idea is that you want features to be as
>> accessible
>> to new users as possible, so you have lots of things 'in their face' by
>> default.  Better for them to say "wow, lots of stuff to try" than "this
>> doesn't have any features, back to Windows".  There's a limit to this, but I
>> don't think KDE is near it.  The default main menu still easily fits in one
>> column on most displays.

I disagree with this.  I think it is better to have a simple UI with more
advanced commands buried for new users.  As they progress to user level two,
more things can be moved into the menu.  I'm thinking here of how we teach COMP
101 using 'Simplified finder' (or whatever it was called).

A few people here have mentioned writing multiple levels for users. 
Unfortunately nobody has gone and done this yet, I suspect because it is a very
difficult task and relies on most of KDE 2 to be finished before it can really
be begun.  This is a pity since it really would be a good feature, perhaps come
January I will have a bit more free time.

>> There's a limit to this, but I
>> don't think KDE is near it.  The default main menu still easily fits in one
>> column on most displays.

I think every operating system available now has gone well past it.  The only
'OS' which can be used easily by a completely new user was At ease by apple.  Do
people remember it? It was crippling to anybody beyond a complete novice stage.

>> Experienced users can add and remove things at their whim.  2.0 has much
>> better support for customising the main menu on a per user basis.

Yes, and per group, and lots of other neat things.  I particularly like the
idea that I can tell it to read <power user>'s config and just customise
anything they do which I don't like.
 
>>> I think these are examples of bad UI: meaningless buttons, hard to control
>>> windows, menu overload, inconsistent UI and arbitrary key configuration.
> Examples?

Well, I thought the things above were examples :-)

Buttons: Apply
Windows: KIS toolbars
Menus: Extra options at root level, size of the 'utilities' menu, Non KDE apps
       menu.
Key config: Meaning of home/end keys, meaning of C-s

> The correct UNIX way to stop an user from doing something stupid:
> 
> chown root ~someuser/.kderc
> chmod a-w g-w ~someuser/.kderc

Or alias restore cp -R /etc/default-settings/.??* /home/$*

Corrin
--
Corrin Lakeland <lakeland@cs.otago.ac.nz>             Phone 64 6 876 5219
Department of Computer Science                Faculty of Business Studies
University of Otago, New Zealand      Eastern Institute of Technology, NZ

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