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

List:       kde-look
Subject:    Re: Copying the Windows interface
From:       "Andrew B. Arthur" <arthur99 () global2000 ! net>
Date:       1999-08-28 19:37:54
[Download RAW message or body]

> Corrin Lakeland [corrin.lakeland@xtra.co.nz] wrote:

>> 1. Apply buttons are the most stupid piece of interface I have ever seen.
>> Trying out settings is a great idea but if I don't like them I want to be
>> able to change them back, without having to manually reset everything I've
>> changed.

>> Gnome has a far better idea with the 'Try' button and I REALLY thing
>> KDE should remove all apply buttons in favour of try (it isn't even much more
>> programming).

/me opens like 5 different GNOME programs, and notices the button standard
looks like this:

[Help] [Apply]               [Cancel] [Okay]

(basically the same as KDE)

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.

> If this is done, what if you have a dialogue open that you want to make
> multiple changes to, one at a time?  This is what apply does now.

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

> While I
> think 'try' sounds like a decent idea, it's not at all the same functionality
> as 'apply', so I don't see a reason to remove one in favor of the other.

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.

>> 2. KImageShop subwindows can't be dragged outside the main window.  Is this a
>> bug in kimageshop or koffice, or a really bad UI `feature'?

I don't think anybody has really don't lots of interface assessment of
KImageShop.

I have to agree this is definatly a major flaw.

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

> Well, first, KIS, is in very, very early development.

heh. I didn't even realize KIS existed yet.

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

Traditionally, high-resolution monitors, big screens and video cards were
expensive -- so you were limited to screens of 800 x 600 pixels or less on
PC's. Traditionally UNIX machines have been high-end hardware that supported
high resolution monitors / video cards. That's the main reason why on Mac OS
traditionally, only the front application menus / button bars showed -- and
were locked (or defaulted to the top of the screen), so you could fit as
many windows as possible on that 512x348 res. screen.

Modern PC's have no problems with a lack of screen space (most Linux
machines run at 1024x768 or better) -- so we can use a slightly more space
wasting interface, in order to increase productivity. I really don't mind
this at all.

> 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 handy for little screens.

> There is also a plan to let each window control mutliple images via a tab bar,
> to try to get the best of both worlds...

ekk... well at least it's optional. ;-)

I hate interfaces like that -- they place a lot of redundant info on the
screen -- and just look stupid (who needs extra tab bars on there screen --
we have kicker to switch between windows).

>> 3. Docking into kpanel is currently working well but leads to stupid things
>> in the windows world.

Don't dock as many programs.

>> I've seen screens where 1/2 of the taskbar length is taken up by docked
>> programs.

hehe... show offs...

>> In windows (but not in KDE yet) these seem to
>> be control panels that the authors thought were too important to only go in
>> the control panels folder.

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

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

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

>> I think these are examples of bad UI: meaningless buttons, hard to control
>> windows, menu overload, inconsistent UI and arbitrary key configuration.

Examples?

>> Now, if you have come from the windows world then perhaps you will disagree
>> and the Windows way will make sense to you, but those of use who don't come
>> from the windows world would like to see these windows quirks easy to change.

Funny, I don't come from the Windows world (I rarely have ever used a
Windows / MS-DOG machine). I have worked with Mac OS for quite a few years
though.

>> particularly concerned by talk about making some settings (e.g. trash icon)
>> compulsory, in my opinion the operating system should NEVER prevent the user
>> from doing something (at most it should warn them).

The correct UNIX way to stop an user from doing something stupid:

chown root ~someuser/.kderc
chmod a-w g-w ~someuser/.kderc

That will restrict anybody (besides) root from messing with an dangerous
setting. That's the whole point of permissions

>> Just because you can't
>> think of a good reason to do something doesn't mean it should be stopped,
>> especially in a multi-user system where every user has their own settings
>> (If users must share an account then root can chmod the settings files to
>> read only).

Yep.


Thanks,

Andrew Arthur a.k.a. AArthur
arthur99@global2000.net
AIM: arthur998

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