An idea for KDE4.0-desktop

[Janne Ojaniemi]

warning! Ideas presented in this post will propably evoke stong reactions in
some people :)! I originally made this post in kde-artist.org, but I'm hoping
that I will be able to spark more lively discussion here, and I would love to
hear some usability-related discussion about the proposal. The proposal
contains some radical changes to the way KDE bahes, so opinions are more than
welcome. I will now copy/paste my original essge from kde-artists.org:

For a long time people have been telling how KDE 4 will enable developers to
really change KDE. How it can be used to clean things up, and really make it
better, without being held back by it’s past. And in spirit of that, I have
had lots of ideas about KDE cooking in my head recently. While some of the
suggestions may be controversial, there is always a “method behind the
madness”. And still, my proposal is less radical than some other proposals I
have seen. Controversial as my suggestions might be, they always follow
certain guidelines. And in this proposal the guidelines are these:

1. Keep things simple! Everything in the desktop needs to be simple and easy
to use. Purpose of everything should be obvious to the user. If the user has
to think about what something does, it’s too complicated.
2. Remember Fitt’s law! Objects in the screen-borders are easier to access.
Objects in the screen-corners are the easiest of them all to access.
3. Make it visually pleasing! No unneeded clutter. Keep things smooth. No
borders, lines, gizmos and the like, unless they are absolutely needed.
4. In accordance with the vision for Plasma, desktop is a first-class citizen.

Without further talking, behold the desktop of KDE 4.0:

Loading Image...

(if anyone wants to mirror the image, be my quest)

My goal was to make it clean, smooth and uncluttered. I think I achieved my
goal. Of course that mockup looks largely like current KDE, since I used 3.4
as a basis for it. In 4.0, toolbars, windecs and the like would propably look
different.

What are the major changes in the desktop if compared to the current system
(not all changs are shown in the mockup, due to my poor graphical skills)?

1. Mac OS-style menubar. It is controversial, I know. But the advantages it
provides are substantial. And my approach has tried to minimize the
drawbacks.

2. What is that red thing in the top-right corner? It’s the “close
window”-button. What is it doing in there you ask? It’s an easy place to
close the app. You can now access that button with a flick of a wrist,
instead of having to hunt for the close window-button. The close
window-button on this suggestion is A LOT bigger than it is with traditional
approach, thanks to it being in the screen-corner. Read on for further
rationale in this text.

3. In the bottom-left corner, is the “Show Desktop”-button. This provides a
quick access to the desktop, turning desktop in to a first-class citizen. And
since it’s in the screen-corner, it’s easy to access.

4. In the bottom-right corner (not shown in the mockup) is Kompose-button.
This provides easy access to all running applications, no matter which
desktop they reside at. And, again, it follows Fitt’s law.

5. The green-thingy in top-left corner is the Kmenu/Ali. And before you talk
of “copying Windows” with that green button: it came about as a pair to the
red Close Window-button. Red button closes apps, green button launches apps.
Red button to close the system, green button to use the system. Of course,
the color-scheme could be changed.

By far, the two most controversial suggestions are the universal menubar and
the “universal close”-button (UCB). Universal Menubar has already been widely
discussed, but the UCB has not been discussed. And I do think it warrants
some serious consideration.

The arguments supporting the UCB are these:

1. It’s fast and easy to access.
2. It makes it more difficult to accidentally close an app, when you really
wanted to just minimize/maximize it (I have done so, I bet you have done so
as well)
3. It’s in consistent location.
4. It makes it possible to close all the running apps, without moving the
mouse (think of click-click-click-click-done)
5. Only the buttons the user use to manipulate the app-window itself
(minimise, maximise etc.) are actually in the window. Buttons that manipulate
the app (close) are elsewhere. Why should the button for terminating the app
be in the windec?

What objections can I hear?

1. You can only close the active app, not out-of-focus apps
2. It’s different from what we have now/what new users expect

Well, #1 can be fixed. By default, clicking on the UCB would close the active
window. Click & hold would drop down a menu with list of all running apps,
and the user could choose from there the one he wants to close. The menu
would also contain entry for logging out. If there are no apps running or the
desktop is in the forefront, the button would function as a log-out button.
This way the behavior of the button is consistant. Either it closes the
window, or it “closes the desktop”.

What about #2? Well, things change. KDE can’t tie itself to the past, nor can
it tie itself to other system (that is, KDE can’t be designed with Windows in
mind, so that Windows-refugees will have it easy in moving to KDE. KDE must
have an identity of it’s own). And differences in the system can be solved
with education and documentation. And besides, UCB is not that different if
you compare it to full-screen apps today. Tradition can’t stand in the way of
progress.

What about the Kmenu/ALI? It would be in the top-left corner. It could contain
few quick-launch buttons, and application categories, and nothing else.
Anything else would be too complex and too busy visually. Configuration and
the like be handled elsewhere: namely in the desktop’s menu. That is, when
the user clicks on the desktop, the menubar would show menu’s related to the
desktop. And there would be a menu for configuring the system. You might say
that it’s too inconvenient to configure the system like that. But the idea is
that you configure the system once, and then you just use it. Configuring the
desktop is not something we do every day, and it must not therefore be
uber-easy to access (note: I’m not talking about making it hard to configure
the system!).

And the universal menubar? One of the complaints I have heard is that it’s
difficult to know which application’s menubar is displayed. But this is
merely a question of implementation. For starters, the first application-menu
could be named after the application (like is OS X). That is, First menu in
Konqueror would be called “Konqueror”. Also, out-of-focus apps could be faded
in to the background, making it very obvious which application has the focus.

SUMMARY

This system would offer several good things. All important functions would be
very easy and quick to access. Launching applications, accessing menu’s,
closing apps, showing the desktop, managing between apps and so forth.
Regarding app-closing: even though it would be very easy to close the apps
thanks to UCB, it would be VERY difficult to close a wrong app by mistake. So
it offers all the good things of being easy and quick to access, without the
drawbacks.

Before condemning the proposal as ludicrous, give it a serious thought. Ask
yourself: "Why should the button that terminates the app be alongside buttons
that merely manipulate the app-window, in the windec?".

[James Ots]

Hi,

Your ideas sound interesting. Here are a few comments:

* How would one close individual windows - say tool windows for example? Would
they have a close icon on their windows? That probably wouldn't be a good
idea, because then you'd wonder why you couldn't close the main window in the
same way. The thing is, people don't generally think in terms of
applications, they think in terms of windows on the screen. I like the Mac
way of doing things - you can close all the windows a programme has open, but
it can still be running - you have to choose quit from the menu to kill the
programme. In which case, the close button is a window manipulation - it
closes the window.
* Is closing an app an action that needs to be so easily accessible that you
apply fitt's law to positioning the control? (Although I agree it's better
than putting the close button directly next to the maximise button!)
* Would the four buttons be hard coded to be attached to the corners of the
screen? Or to the panels which can be moved (at least at the moment - who
knows what Aaron has up his sleeve!)
* What would happen to me, where I have a twinview and a graphics tablet and
to switch screens on the tablet I move the pointer to the edge of the tablet
I want to move to. That goes for the existing way of doing things as well -
KDE really doesn't work well on my twinview setup.
* I like having the universal menubar, as I already have it. Even though all
my menu items are always on the left hand display, so I end up using the
keyboard to use it. But I do usually anyway, so it's a good way to get it out
of the way.

Erm, that's all for now. Hope I made at least a modicum of sense.

[Janne Ojaniemi]

Post by James Ots
Hi,
* How would one close individual windows - say tool windows for example?

If the windows are clearly part of a greater whole (toolbox-windows,
dialog-boxes etc.) they might have a close-button. But the application-window
would not contain one. And when user minimizes the main window, all the
toolboxes etc. would minimize with it.

Post by James Ots
That probably wouldn't be a
good idea, because then you'd wonder why you couldn't close the main window
in the same way.

Well, there really is not need IMO to be able to close the main-window, unless
the user plans to actully close the app. And in that case, the close-button
could be located elsewhere and not in the windec (which should be about the
window, and not the app. Let's turn Kwin in to _window_ manager, instead of
combined window manager/application-manager)

Post by James Ots
The thing is, people don't generally think in terms of
applications, they think in terms of windows on the screen. I like the Mac
way of doing things - you can close all the windows a programme has open,
but it can still be running - you have to choose quit from the menu to kill
the programme. In which case, the close button is a window manipulation -
it closes the window.

Man codes do something similar. But I don' really see any benefi of closing
the window, yet leaving the app running. If I do that on the Safari for
example, the re-launched app-window would not be where it was when I closed
it. So I see no benefit in closing the window. Maybe MacOS has the ability to
close the window, because their windowmanagement sucks and Dock is really bad
at handling running apps ;)?

Post by James Ots
* Is closing an app an action that needs to be so easily accessible that
you apply fitt's law to positioning the control? (Although I agree it's
better than putting the close button directly next to the maximise button!)

Part of the rationale in moving the button to the menubar is that that button
closes the application, and it shouldn't therefore be in the windec, since
the windec and the buttons there handle the window, not the app.

Post by James Ots
* Would the four buttons be hard coded to be attached to the corners of the
screen? Or to the panels which can be moved (at least at the moment - who
knows what Aaron has up his sleeve!)

Hardcoding things would be against the KDE-way ;). So the user could change
the defaults if he wants to. And there could be the choice of using "KDE
Classic" instead, which would re-create the current setup.

[Henrique Pinto]

Post by Janne Ojaniemi
1. Mac OS-style menubar. It is controversial, I know. But the advantages it
provides are substantial. And my approach has tried to minimize the
drawbacks.

I use menubar-on-top, I think it is great, but still would be a bad thing as
default, as non-KDE apps wouldn't use it, and thus it won't be consistent.

[Janne Ojaniemi]

Post by Henrique Pinto

Post by Janne Ojaniemi
1. Mac OS-style menubar. It is controversial, I know. But the advantages
it provides are substantial. And my approach has tried to minimize the
drawbacks.

I use menubar-on-top, I think it is great, but still would be a bad thing
as default, as non-KDE apps wouldn't use it, and thus it won't be
consistent.

That could be a problem. But it could be solved by

a) running KDE-only apps ;)

b) some sort of shared menubar-spec through Freedesktop.org.

[Joseph Garvin]

Why change the menu bar to be mac os style? I don't understand what
benefit this provides. _Maybe_ for Fitt's law, but then why don't we
also put the toolbar button say down the left or right sides? In the end
I'd think it'd be more confusing: the window is the application's
domain, so I expect the menus inside it to interact with it. Menus
outside beginning to affect things could be confusing for end users. I
assume mac users don't have a problem because that's how its always
worked for them.

Post by Janne Ojaniemi
warning! Ideas presented in this post will propably evoke stong reactions in
some people :)! I originally made this post in kde-artist.org, but I'm hoping
that I will be able to spark more lively discussion here, and I would love to
hear some usability-related discussion about the proposal. The proposal
contains some radical changes to the way KDE bahes, so opinions are more than
For a long time people have been telling how KDE 4 will enable developers to
really change KDE. How it can be used to clean things up, and really make it
better, without being held back by it’s past. And in spirit of that, I have
had lots of ideas about KDE cooking in my head recently. While some of the
suggestions may be controversial, there is always a “method behind the
madness”. And still, my proposal is less radical than some other proposals I
have seen. Controversial as my suggestions might be, they always follow
1. Keep things simple! Everything in the desktop needs to be simple and easy
to use. Purpose of everything should be obvious to the user. If the user has
to think about what something does, it’s too complicated.
2. Remember Fitt’s law! Objects in the screen-borders are easier to access.
Objects in the screen-corners are the easiest of them all to access.
3. Make it visually pleasing! No unneeded clutter. Keep things smooth. No
borders, lines, gizmos and the like, unless they are absolutely needed.
4. In accordance with the vision for Plasma, desktop is a first-class citizen.
http://img332.imageshack.us/my.php?image=kde4a8dn.jpg
(if anyone wants to mirror the image, be my quest)
My goal was to make it clean, smooth and uncluttered. I think I achieved my
goal. Of course that mockup looks largely like current KDE, since I used 3.4
as a basis for it. In 4.0, toolbars, windecs and the like would propably look
different.
What are the major changes in the desktop if compared to the current system
(not all changs are shown in the mockup, due to my poor graphical skills)?
1. Mac OS-style menubar. It is controversial, I know. But the advantages it
provides are substantial. And my approach has tried to minimize the
drawbacks.
2. What is that red thing in the top-right corner? It’s the “close
window”-button. What is it doing in there you ask? It’s an easy place to
close the app. You can now access that button with a flick of a wrist,
instead of having to hunt for the close window-button. The close
window-button on this suggestion is A LOT bigger than it is with traditional
approach, thanks to it being in the screen-corner. Read on for further
rationale in this text.
3. In the bottom-left corner, is the “Show Desktop”-button. This provides a
quick access to the desktop, turning desktop in to a first-class citizen. And
since it’s in the screen-corner, it’s easy to access.
4. In the bottom-right corner (not shown in the mockup) is Kompose-button.
This provides easy access to all running applications, no matter which
desktop they reside at. And, again, it follows Fitt’s law.
5. The green-thingy in top-left corner is the Kmenu/Ali. And before you talk
of “copying Windows” with that green button: it came about as a pair to the
red Close Window-button. Red button closes apps, green button launches apps.
Red button to close the system, green button to use the system. Of course,
the color-scheme could be changed.
By far, the two most controversial suggestions are the universal menubar and
the “universal close”-button (UCB). Universal Menubar has already been widely
discussed, but the UCB has not been discussed. And I do think it warrants
some serious consideration.
1. It’s fast and easy to access.
2. It makes it more difficult to accidentally close an app, when you really
wanted to just minimize/maximize it (I have done so, I bet you have done so
as well)
3. It’s in consistent location.
4. It makes it possible to close all the running apps, without moving the
mouse (think of click-click-click-click-done)
5. Only the buttons the user use to manipulate the app-window itself
(minimise, maximise etc.) are actually in the window. Buttons that manipulate
the app (close) are elsewhere. Why should the button for terminating the app
be in the windec?
What objections can I hear?
1. You can only close the active app, not out-of-focus apps
2. It’s different from what we have now/what new users expect
Well, #1 can be fixed. By default, clicking on the UCB would close the active
window. Click & hold would drop down a menu with list of all running apps,
and the user could choose from there the one he wants to close. The menu
would also contain entry for logging out. If there are no apps running or the
desktop is in the forefront, the button would function as a log-out button.
This way the behavior of the button is consistant. Either it closes the
window, or it “closes the desktop”.
What about #2? Well, things change. KDE can’t tie itself to the past, nor can
it tie itself to other system (that is, KDE can’t be designed with Windows in
mind, so that Windows-refugees will have it easy in moving to KDE. KDE must
have an identity of it’s own). And differences in the system can be solved
with education and documentation. And besides, UCB is not that different if
you compare it to full-screen apps today. Tradition can’t stand in the way of
progress.
What about the Kmenu/ALI? It would be in the top-left corner. It could contain
few quick-launch buttons, and application categories, and nothing else.
Anything else would be too complex and too busy visually. Configuration and
the like be handled elsewhere: namely in the desktop’s menu. That is, when
the user clicks on the desktop, the menubar would show menu’s related to the
desktop. And there would be a menu for configuring the system. You might say
that it’s too inconvenient to configure the system like that. But the idea is
that you configure the system once, and then you just use it. Configuring the
desktop is not something we do every day, and it must not therefore be
uber-easy to access (note: I’m not talking about making it hard to configure
the system!).
And the universal menubar? One of the complaints I have heard is that it’s
difficult to know which application’s menubar is displayed. But this is
merely a question of implementation. For starters, the first application-menu
could be named after the application (like is OS X). That is, First menu in
Konqueror would be called “Konqueror”. Also, out-of-focus apps could be faded
in to the background, making it very obvious which application has the focus.
SUMMARY
This system would offer several good things. All important functions would be
very easy and quick to access. Launching applications, accessing menu’s,
closing apps, showing the desktop, managing between apps and so forth.
Regarding app-closing: even though it would be very easy to close the apps
thanks to UCB, it would be VERY difficult to close a wrong app by mistake. So
it offers all the good things of being easy and quick to access, without the
drawbacks.
Before condemning the proposal as ludicrous, give it a serious thought. Ask
yourself: "Why should the button that terminates the app be alongside buttons
that merely manipulate the app-window, in the windec?".
_______________________________________________
kde-usability mailing list
https://mail.kde.org/mailman/listinfo/kde-usability

[James Ots]

I think one advantage of the MacOS style menubar is that the menubar is then
associated with the application, rather than with one window. It starts to
break the assumption that 'the window is the application', and makes it
easier to understand that an application can still be running when you can't
see its windows. It would also solve the problem of minimising things like
kmail when you click the close button - because the close button would always
mean close the window, not the application.

You know what? I never realised all that until I started typing it; in fact, I
wasn't a particular MacOS menubar advocate before, I just kind of liked it
like that. But now I like it for usability reasons. (Although at the moment
it doesn't work like it should).
--
Cheers
James Ots
www.jamesots.com

Post by Joseph Garvin
Why change the menu bar to be mac os style? I don't understand what
benefit this provides. _Maybe_ for Fitt's law, but then why don't we
also put the toolbar button say down the left or right sides? In the end
I'd think it'd be more confusing: the window is the application's
domain, so I expect the menus inside it to interact with it. Menus
outside beginning to affect things could be confusing for end users. I
assume mac users don't have a problem because that's how its always
worked for them.

[Laurent Rathle]

Post by James Ots
It starts to
break the assumption that 'the window is the application', and makes it
easier to understand that an application can still be running when you
can't see its windows.

I'm not sure of that, since when an application is docked on Mac OS X,
nopthing says in the menubar that it's still running. I have a friend who use
a Mac and she is often looking around in the dock to see what applications
are running or not when she need to free some memory space, for example.

Post by James Ots
It would also solve the problem of minimising things
like kmail when you click the close button - because the close button would
always mean close the window, not the application.

I think it's a question of getting use to some behavior. Mac OS X users are
used to the behavior of their software. But, for example, I'm always a little
confused with Mac application when I work on my friend Mac. It would take
some time for me to be on my ease with this behavior.

[Friedrich W. H. Kossebau]

My wild 3 cents:
What is a menu bar? Left over from ancient character based interfaces, kept
for those trained to use them? Collection of entries which hold commands or
other collections?

Related: Where are the tools on the toolbar, I see only buttons?

The toolbar as used in KDE is not really a toolbar. It's an alignment of
commands that happen to be presented by buttons and not simpe text entries
like in the menu.* There is hardly a principle difference between the menu
bar and the tool bar. The first is a collection of all commands made
available to the user, the latter simply one of often used commands, always
shown. Similar the RMB menu.

E.g. zooming: Why do we have to explicitly add an entry/button for Enlarge, an
entry/button for Shrink and menu/combo button for the actual and other zoom
levels, then wire them up to the view model? And repeat this for each and
every app? Why is there no "toolet" that adapts not just to one manually
wired signal/slot but automatically to a standardized interface? There is
much room for improvement!**

Global vs. local menu bar:
Global things work on the globally focussed object, local on the locally
focussed object (often there is even only one locally). So the workflow
advantage vs. screen estate is dependent if one often switches between
objects/windows or not. Both working styles are common, thus should be
supported.
Which to support/choose as default is left to what more people are trained to
do or prefer to do, please take numbers from your local randomizer.

* RMB on toolbar, choose text position, only text. Where is the real
difference to the menu bar?
** see doc centric approach, google for it.

Regards
Friedrich

[Janne Ojaniemi]

Why change the menu bar to be mac os style? I don't understand what benefit
this provides.

It provides following benefits:

- Menus are in constistent location. No matter where the app-window is, the
menu's are aways in exact same place

- It saves screen-space, since the menubar would not be repeated in each
app-window. And since user can only access one menubar at a time, having
several menubars is a waste

- It makes it faster to access the menu's because they take advantage of
screen-borders.

Canonical's usability-expert said this about per-window menu's:

"Every window that has menus puts them in a separate menu bar inside the
window. This (a) wastes screen real estate, (b) is confusing (even experts
occasionally click the wrong menu bar by accident), (c) does not work for
narrow windows (as demonstrated by the Gimp), (d) works badly for windows
near the bottom or right of the screen (for which menus unexpectedly open
upward or leftward), and (e) works even worse if those menus have submenus.

Worst of all, because under Fitt’s Law their vastly smaller target size
outweighs their somewhat closer proximity, (f) menu bars inside each window
are several hundred percent slower to use than a menu bar at the top of the
screen."

He makes sense. And he knows what he's talking about.

_Maybe_ for Fitt's law, but then why don't we also put the
toolbar button say down the left or right sides?

Compared to the menubar, toolbars can look very different from app to app. So
the change in app would be more drastic than with universal menubar. Also,
framing the desktop with bars on all sides would look very unpleasant.

In the end I'd think it'd
be more confusing: the window is the application's domain, so I expect the
menus inside it to interact with it. Menus outside beginning to affect
things could be confusing for end users. I assume mac users don't have a
problem because that's how its always worked for them.

Well, lots and lots of people are starting to use Macs, so it seems to me that
they do not find anything wrong with the Universal Menubar. I used to hate it
when I tried OS X, but now I have grown to appreciate it.

I feel that the biggest reason for opposing this change is NOT because it
would work badle, but because some people refuse to accept change.

[Aaron J. Seigo]

Post by Janne Ojaniemi
- Menus are in constistent location. No matter where the app-window is, the
menu's are aways in exact same place

yes, as far away from the context as possible ;)

Post by Janne Ojaniemi
- It saves screen-space, since the menubar would not be repeated in each
app-window. And since user can only access one menubar at a time, having
several menubars is a waste

unless you are only viewing documents, this is completely false.

consider 2 windows on screen at the same time. the menu in window 1 does not
take space away from window 2. when working in window 2, who cares that there
is a menu in window 1, unless of course you want to access its menus in which
case the mac way is slower.

Post by Janne Ojaniemi
- It makes it faster to access the menu's because they take advantage of
screen-borders.

and makes it harder to hit maximize window titlebars and assumes menus are
that important. consider that MS Vista is actually _demoting_ menus. there's
a reason for that.
assuming we're thinking of the same person, he was a graphic designer IIRC =)

Post by Janne Ojaniemi
"Every window that has menus puts them in a separate menu bar inside the
window. This (a) wastes screen real estate,

i've already addressed this issue. it's bogus and shows the fellow has very
little idea what he's really talking about -=(

Post by Janne Ojaniemi
(b) is confusing (even experts
occasionally click the wrong menu bar by accident),

this actually happens more often on MacOS than on Windows/KDE since with
"menubar in window" the context is obvious.

Post by Janne Ojaniemi
(c) does not work for
narrow windows (as demonstrated by the Gimp),

the GIMP has issues. using it as a guide for anything usability related is
laughable. narrow windows shouldn't need menus, or they should only need one
or two. look at kopete's contact window.

Post by Janne Ojaniemi
(d) works badly for windows
near the bottom or right of the screen (for which menus unexpectedly open
upward or leftward), and

where "badly" is used as a synonym for "appears to the left instead of the
right". please.

Post by Janne Ojaniemi
(e) works even worse if those menus have submenus.

nascent impact.

Post by Janne Ojaniemi
Worst of all, because under Fitt’s Law their vastly smaller target size
outweighs their somewhat closer proximity, (f) menu bars inside each window
are several hundred percent slower to use than a menu bar at the top of the
screen."

you need to take a page from software optimization here: optimize the time
critical parts, don't care about the rest.

Post by Janne Ojaniemi
He makes sense. And he knows what he's talking about.

and how do you ballance his "points" against the issue of lacking context for
the menubar?

Post by Janne Ojaniemi
Well, lots and lots of people are starting to use Macs, so it seems to me
that they do not find anything wrong with the Universal Menubar.

it's like the dock. it's not the best way, but it's the mac way and you can
learn to work around it.

see, this argument that you just used is very wrong headed. let me give you
the example:

lots and lots of people are starting to use KDE, so it seems to me
that they do not find anything wrong with the KDE Control Center.
we should therefore not change it. in fact, Apple should think about using
it.

are you laughing yet? ;)

Post by Janne Ojaniemi
I feel that the biggest reason for opposing this change is NOT because it
would work badle, but because some people refuse to accept change.

that or it's just not such a hot idea.

[Maurizio Colucci]

Post by Aaron J. Seigo

Post by Janne Ojaniemi
- Menus are in constistent location. No matter where the app-window is, the
menu's are aways in exact same place

yes, as far away from the context as possible ;)

The point is not that they're far, because even though they are
farther away they are more reachable. The point is that the visual
encapsulation is broken, and the logical structure of the program is
less clear.

My two pence.

Maurizio

[Martijn Klingens]

Post by Maurizio Colucci

Post by Aaron J. Seigo

Post by Janne Ojaniemi
- Menus are in constistent location. No matter where the app-window is,
the menu's are aways in exact same place

yes, as far away from the context as possible ;)

The point is not that they're far, because even though they are
farther away they are more reachable. The point is that the visual
encapsulation is broken, and the logical structure of the program is
less clear.

After having used Mac style menu bars for almost a year in the past I have to
agree with both you and Aaron. Indeed the Mac menu bar adheres more to Fitt's
law, indeed it saves (a little) screen estate, but in practice it didn't make
me more productive, rather the contrary. It depends on usage patterns, but in
user friendly software you need the menu bar surprisingly little. I guess one
reason why the menu bar is important for Apple is because of their
single-button mice -- context menus are not available, so the menu takes a
more important place. That's guesswork though.

The one change from the mac that I still do use after I turned off mac menus
is the close button in the upper left corner. That way both the close button
and the maximize button are adhering to fitt's law, and those two *do* make
me more productive. I also have the nagging feeling that moving the mouse to
the upper left corner is easier than the upper right, speeding up the close
button even more, but I have no research to back that up.

[Aaron J. Seigo]

Post by Martijn Klingens
The one change from the mac that I still do use after I turned off mac
menus is the close button in the upper left corner. That way both the close
button and the maximize button are adhering to fitt's law, and those two
*do* make me more productive. I also have the nagging feeling that moving
the mouse to the upper left corner is easier than the upper right, speeding
up the close button even more, but I have no research to back that up.

i configure my window decos that way as well. close == move mouse left,
anything else == move mouse right. since close is probably the most common
thing i do, with maximize/restore the next, it really does help to
differentiate the locations they are in and yes it allows the to take
advantage of the screen edges.

i tried to get this changed for 3.4 btw, and met with strong resistance.
*sigh* oh well.

[Lauri Watts]

Post by Aaron J. Seigo

Post by Martijn Klingens
The one change from the mac that I still do use after I turned off mac
menus is the close button in the upper left corner. That way both the
close button and the maximize button are adhering to fitt's law, and
those two *do* make me more productive. I also have the nagging feeling
that moving the mouse to the upper left corner is easier than the upper
right, speeding up the close button even more, but I have no research to
back that up.

i configure my window decos that way as well. close == move mouse left,
anything else == move mouse right. since close is probably the most common
thing i do, with maximize/restore the next, it really does help to
differentiate the locations they are in and yes it allows the to take
advantage of the screen edges.
i tried to get this changed for 3.4 btw, and met with strong resistance.
*sigh* oh well.

I'm tempted to say just change it for KDE 4. It was that way around in KDE 1,
and (at least the way I remember it) was changed quite arbitrarily and
without discussion (and I among others protested after the fact), but by then
we were far into the KDE 2 release schedule. It's still the first thing I
change on a fresh desktop.

I don't remember seeing the discussion for 3.4, or I'd have been in there
fighting for the cause then.

Regards,

[Thomas Zander]

Post by Lauri Watts

Post by Aaron J. Seigo
i configure my window decos that way as well. close == move mouse
left, anything else == move mouse right.

...

Post by Lauri Watts

Post by Aaron J. Seigo
i tried to get this changed for 3.4 btw, and met with strong
resistance. *sigh* oh well.

I'm tempted to say just change it for KDE 4. It was that way around in
KDE 1, and (at least the way I remember it) was changed quite
arbitrarily and without discussion (and I among others protested after
the fact), but by then we were far into the KDE 2 release schedule.
It's still the first thing I change on a fresh desktop.
I don't remember seeing the discussion for 3.4, or I'd have been in
there fighting for the cause then.

</aol>

I've been using it in the left corner since I started using Guis, because
I started on the Amiga. The years that I used Windows machines have been
the inconsistent ones :)

- --
Thomas Zander

[Luciano Montanaro]

Post by Thomas Zander

Post by Lauri Watts

Post by Aaron J. Seigo
i configure my window decos that way as well. close == move mouse
left, anything else == move mouse right.

...

Post by Lauri Watts

Post by Aaron J. Seigo
i tried to get this changed for 3.4 btw, and met with strong
resistance. *sigh* oh well.

I'm tempted to say just change it for KDE 4. It was that way around in
KDE 1, and (at least the way I remember it) was changed quite
arbitrarily and without discussion (and I among others protested after
the fact), but by then we were far into the KDE 2 release schedule.
It's still the first thing I change on a fresh desktop.
I don't remember seeing the discussion for 3.4, or I'd have been in
there fighting for the cause then.

</aol>
I've been using it in the left corner since I started using Guis, because
I started on the Amiga. The years that I used Windows machines have been
the inconsistent ones :)

Hey a fellow Amigan!

Well, I've managed to stay away from Window most of the time, and I too am
in support of the change.

I also have used the "Mac Os like" menubar since it has been available, even
if it is a feature that is often overlooked in the development versions.

It would be nice if it could be agreed a way to have Gnome application
honour this preference too.

Luciano

[James Ots]

For 3.5 can we at least put three or four spacers between the close and
maximise buttons?
--
Cheers
James Ots
www.jamesots.com

Post by Lauri Watts
I'm tempted to say just change it for KDE 4. It was that way around in KDE
1, and (at least the way I remember it) was changed quite arbitrarily and
without discussion (and I among others protested after the fact), but by
then we were far into the KDE 2 release schedule. It's still the first
thing I change on a fresh desktop.
I don't remember seeing the discussion for 3.4, or I'd have been in there
fighting for the cause then.

[Martijn Klingens]

Post by Lauri Watts
I'm tempted to say just change it for KDE 4.

Me too. For one, such a behavioural change suits better in a major release.
Second, screenshots have to be redone for KDE 4 anyway. Third, the upper left
corner in a new KDE install is mostly useless, so why not make use of it?

Post by Lauri Watts
I don't remember seeing the discussion for 3.4, or I'd have been in there
fighting for the cause then.

Same here.

[Florian Graessle]

Post by Aaron J. Seigo
i tried to get this changed for 3.4 btw, and met with strong resistance.
*sigh* oh well.

Then let's do that for KDE4. I suppose you won't get too much resistance
- if any at all - from other usability folks. A lot of them including me
are already using it that way. Also one will notice that this
configuration is gaining popularity if one sneaks around community
forums and watches people's desktop screenshots.

So I guess it has somewhat proven itself to be a good thing :)

[David Laban]

Post by Aaron J. Seigo
i configure my window decos that way as well. close == move mouse left,
anything else == move mouse right.

I just realised: because most things that use tabs were written for the
current layout of the close button, they work the other way round. I would
quite like to see the tabs [globally] configurable to go the other way round
too if we're going to change the position of the close button. More as an
experiment than anything else really. If we're going to be changing the way
we automatically move to hit close, we might as well be consistant

[Aaron J. Seigo]

Post by David Laban

Post by Aaron J. Seigo
i configure my window decos that way as well. close == move mouse left,
anything else == move mouse right.

I just realised: because most things that use tabs were written for the
current layout of the close button, they work the other way round. I would
quite like to see the tabs [globally] configurable to go the other way
round too if we're going to change the position of the close button. More
as an experiment than anything else really. If we're going to be changing
the way we automatically move to hit close, we might as well be consistant

very good point. ok.. i'm now running with the close button in the corner all
by itself rather than the left so it's consistent with tabs. perhaps some of
the others on this list could try it as well...

i should test this out on non-kde users and see what the reaction is
("maximize the window", "close the window", etc)

[Martijn Klingens]

Post by Aaron J. Seigo
very good point. ok.. i'm now running with the close button in the corner
all by itself rather than the left so it's consistent with tabs. perhaps
some of the others on this list could try it as well...
i should test this out on non-kde users and see what the reaction is
("maximize the window", "close the window", etc)

I'm not sure I follow you, what exactly did you change? Oh, and how does it
affect SDI people like me who only use tabs in konsole? :)

[Aaron J. Seigo]

Post by Martijn Klingens

Post by Aaron J. Seigo
very good point. ok.. i'm now running with the close button in the corner
all by itself rather than the left so it's consistent with tabs. perhaps
some of the others on this list could try it as well...
i should test this out on non-kde users and see what the reaction is
("maximize the window", "close the window", etc)

I'm not sure I follow you, what exactly did you change?

the style section in my kwinrc now has this:

[Style]
BorderSize=1
ButtonsOnLeft=AI__HM
ButtonsOnRight=__X
CustomButtonPositions=true
PluginLib=kwin3_plastik
ReverseBIDIWindows=true

Post by Martijn Klingens
Oh, and how does it
affect SDI people like me who only use tabs in konsole? :)

konsole also has the close tab button on right right (or left in LTR =)

[Alan]

Post by Martijn Klingens
The one change from the mac that I still do use after I turned off mac
menus is the close button in the upper left corner. That way both the close
button and the maximize button are adhering to fitt's law, and those two
*do* make me more productive. I also have the nagging feeling that moving
the mouse to the upper left corner is easier than the upper right, speeding
up the close button even more, but I have no research to back that up.

Ditto - Alan

[Janne Ojaniemi]

Post by Martijn Klingens
The one change from the mac that I still do use after I turned off mac
menus is the close button in the upper left corner. That way both the close
button and the maximize button are adhering to fitt's law

Only if the app is maximised. If the app is not maximised (like it usually
is), then it does not benefit from Fitt's Law. Although there is a benefit of
not accidentally closing the app when the user really wanted to
minimize/restore the app.

[Martijn Klingens]

Post by Janne Ojaniemi
Only if the app is maximised. If the app is not maximised (like it usually
is), then it does not benefit from Fitt's Law. Although there is a benefit
of not accidentally closing the app when the user really wanted to
minimize/restore the app.

Well, the app is almost always in the corners with kwin and other sane window
managers. What's missing is to impement fitt's law in kwin for those corners,
something I miss a lot in fact. The chances that I want to resize a window at
the screen edge are almost nil, the chances that I would intend a Fitt's
behaviour are the rest, i.e. almost certain :)

Not sure if this reasoning applies to the rest of the KDE using population
though.

[Joseph Garvin]

Post by Martijn Klingens
Well, the app is almost always in the corners with kwin and other sane window
managers. What's missing is to impement fitt's law in kwin for those corners,
something I miss a lot in fact. The chances that I want to resize a window at
the screen edge are almost nil, the chances that I would intend a Fitt's
behaviour are the rest, i.e. almost certain :)
Not sure if this reasoning applies to the rest of the KDE using population
though.

How about this -- if Kwin does window snapping to move an app into a
corner, then the corner pixel is considered part of the button, just
like if you had the window maximized? I think this would work quite
nicely with Kwin having Fitt's law improvements.

[Martijn Klingens]

Post by Joseph Garvin

Post by Martijn Klingens
Well, the app is almost always in the corners with kwin and other sane
window managers. What's missing is to implement fitt's law in kwin for
those corners, something I miss a lot in fact. The chances that I want to
resize a window at the screen edge are almost nil, the chances that I
would intend a Fitt's behaviour are the rest, i.e. almost certain :)
Not sure if this reasoning applies to the rest of the KDE using population
though.

How about this -- if Kwin does window snapping to move an app into a
corner, then the corner pixel is considered part of the button, just
like if you had the window maximized? I think this would work quite
nicely with Kwin having Fitt's law improvements.

I'd make that the corner LINE, but the border is much thicker than that, so
indeed this is an awesome suggestion!

Aaron, what are your thoughts on this? Should we ask Lubos for this or do you
foresee negative consequences?

[Aaron J. Seigo]

Post by Martijn Klingens
Aaron, what are your thoughts on this? Should we ask Lubos for this or do
you foresee negative consequences?

good news! all the sane window decorations already do this.
the insane ones don't, and that's how i tell them apart. ;)

plastik, for instance, does this right. as does smoothblend. we just need to
make a rule that any window decoration that is shipped with KDE by default
must do so as well. it's really not that hard to implement.

[Dan Doel]

Post by Aaron J. Seigo
good news! all the sane window decorations already do this.
the insane ones don't, and that's how i tell them apart. ;)
plastik, for instance, does this right. as does smoothblend.

Does plastik do this in 3.5? In 3.4 (and before), it does it if the
window is maximized, but not if it is merely snapped into the corner,
as they were suggesting.

Thus, only people with smallish monitors who run everything maximized
can take advantage of this, currently (heck, I didn't even run
everything maximized on my 17" CRT, but I'm a youngster).

[Aaron J. Seigo]

Post by Dan Doel

Post by Aaron J. Seigo
good news! all the sane window decorations already do this.
the insane ones don't, and that's how i tell them apart. ;)
plastik, for instance, does this right. as does smoothblend.

Does plastik do this in 3.5? In 3.4 (and before), it does it if the
window is maximized, but not if it is merely snapped into the corner,
as they were suggesting.

ah, just snapped into the corner. no, it doesn't currently, but that should
also be trivial to add. i'll see if i can get this done for 3.5

[Joseph Garvin]

Post by Aaron J. Seigo

Post by Dan Doel

Post by Aaron J. Seigo
good news! all the sane window decorations already do this.
the insane ones don't, and that's how i tell them apart. ;)
plastik, for instance, does this right. as does smoothblend.

Does plastik do this in 3.5? In 3.4 (and before), it does it if the
window is maximized, but not if it is merely snapped into the corner,
as they were suggesting.

ah, just snapped into the corner. no, it doesn't currently, but that should
also be trivial to add. i'll see if i can get this done for 3.5

Holy crud, I made a usability suggestion that may actually appear in KDE !_!

[Martijn Klingens]

Post by Aaron J. Seigo

Post by Dan Doel
Does plastik do this in 3.5? In 3.4 (and before), it does it if the
window is maximized, but not if it is merely snapped into the corner,
as they were suggesting.

ah, just snapped into the corner. no, it doesn't currently, but that should
also be trivial to add. i'll see if i can get this done for 3.5

Thanks. This is especially useful since I turned off Plastik's horrible new
default of turning off resize borders on maximized windows, I still want to
be able to resize or move them. Plus, I have lots of windows maximized only
in one direction, and the mixture looks horrible, as does the jumping if I
maximize the other direction as well.

[Maurizio Colucci]

Post by Martijn Klingens

Post by Aaron J. Seigo

Post by Dan Doel
Does plastik do this in 3.5? In 3.4 (and before), it does it if the
window is maximized, but not if it is merely snapped into the corner,
as they were suggesting.

ah, just snapped into the corner. no, it doesn't currently, but that should
also be trivial to add. i'll see if i can get this done for 3.5

Thanks. This is especially useful since I turned off Plastik's horrible new
default of turning off resize borders on maximized windows, I still want to
be able to resize or move them.

True. OTOH this way the scrollbar does not touch the edge of the
screen, so it's more difficult to reach. Reaching the scrollbar
without looking is something you get used to, if you use gnome for a
while.

I wonder if we could have both benefits together? I mean, both being
able to resize maximized windows, and having the scrollbar touch the
edge of the screen.

Maurizio

[Martijn Klingens]

Post by Maurizio Colucci
True. OTOH this way the scrollbar does not touch the edge of the
screen, so it's more difficult to reach. Reaching the scrollbar
without looking is something you get used to, if you use gnome for a
while.

Interesting. I've never had that option, so I never got used to it. Plus, I
mostly use the scroll wheel. Sounds pretty useful even for me nevertheless.

Post by Maurizio Colucci
I wonder if we could have both benefits together? I mean, both being
able to resize maximized windows, and having the scrollbar touch the
edge of the screen.

Technically the entire row of pixels on the screen edge can be special cased
by the window manager/decoration, and if the mouse is there it could dispatch
synthetic mouse over/click events to the last pixel inside the border. That
way it's even independent of the toolkit, i.e. it would even work with Gtk
apps.

But I don't know enough about this low-level X stuff, so I can't judge how
complex the code would be and how robust.

[Luciano Montanaro]

Post by Maurizio Colucci

Post by Martijn Klingens

Post by Aaron J. Seigo

Post by Dan Doel
Does plastik do this in 3.5? In 3.4 (and before), it does it if the
window is maximized, but not if it is merely snapped into the
corner, as they were suggesting.

ah, just snapped into the corner. no, it doesn't currently, but that
should also be trivial to add. i'll see if i can get this done for
3.5

Thanks. This is especially useful since I turned off Plastik's horrible
new default of turning off resize borders on maximized windows, I still
want to be able to resize or move them.

True. OTOH this way the scrollbar does not touch the edge of the
screen, so it's more difficult to reach. Reaching the scrollbar
without looking is something you get used to, if you use gnome for a
while.
I wonder if we could have both benefits together? I mean, both being
able to resize maximized windows, and having the scrollbar touch the
edge of the screen.

The borders are not always free for use. For example I have a kasbar on the
right of my desktop. So removing the border when maximizing makes the
window ugly without any gain in usability.

On the other hand I do not feel much the need to reach the scrollbar with
the mouse very often. I either use the scroll wheel, or use the paginating
keys. At most, I use the scrollbar as an indication on where I'm in the
document I'm looking at. Am I alone in this?

By the way, I'm just noticing the kmail composer window has a couple of
pixel border around the main text widget, so even when maximized, there
would be no fitts-law advantage in having it borderless.

Luciano

[Lubos Lunak]

Post by Maurizio Colucci

Post by Martijn Klingens

Post by Aaron J. Seigo

Post by Dan Doel
Does plastik do this in 3.5? In 3.4 (and before), it does it if the
window is maximized, but not if it is merely snapped into the corner,
as they were suggesting.

ah, just snapped into the corner. no, it doesn't currently, but that
should also be trivial to add. i'll see if i can get this done for 3.5

See instructions in my other mail ;).

Post by Maurizio Colucci

Post by Martijn Klingens
Thanks. This is especially useful since I turned off Plastik's horrible
new default of turning off resize borders on maximized windows, I still
want to be able to resize or move them.

True. OTOH this way the scrollbar does not touch the edge of the
screen, so it's more difficult to reach. Reaching the scrollbar
without looking is something you get used to, if you use gnome for a
while.

If I'm not mistaken, some KDE apps insert one pixel there anyway (#75859), so
just removing the KWin's border would not be of much help.

Post by Maurizio Colucci
I wonder if we could have both benefits together? I mean, both being
able to resize maximized windows, and having the scrollbar touch the
edge of the screen.

I think the only reasonable way to achieve this no KWin border. To make the
resizing still possible, there could be some kind of overlapping resize
handle, a bit like the one in BII's bottom-right corner, but not overlapping
to the outside but rather to the inside. Ok, to make it simple, like in the
attached mockup :). Technically it'd be sufficient to have it just one pixel
wide, but since it would cover only part of the edge in order to allow having
both the scrollbar and the resize handle right at the edge, it'd probably
have to be thicker in order to be visible.

Then there are of course the boring details like how big part of the edge
should it take, where it should be positioned, and who will write the code. I
have such a strange feeling this would need a small help from the KWin core
to work, but it'd be mostly decoration work.

PS: Yes, that is the toplevel menubar in the screenshot. I'm perfectly happy
with it and I think it beats the normal menubar on any day of the week, after
one learns to use it properly. I don't think it'd be a good default though.

[Martijn Klingens]

Post by Lubos Lunak

Post by Maurizio Colucci
I wonder if we could have both benefits together? I mean, both being
able to resize maximized windows, and having the scrollbar touch the
edge of the screen.

I think the only reasonable way to achieve this no KWin border.

Not sure, see attachment. The red parts are the 'magic' regions. The window
borders will act normally EXCEPT when the mouse is at the very edge, i.e. the
red line AND the edge of the window is also the edge of the screen.

In that case mouse activity (at least clicks and drags, perhaps even motion)
is not handled by the deco, but instead replicated to the application with
the pixels transposed to the inner line.

There will still be a border, but at the edge of the border there will be a
part of the application again.

As for implementing this, I guess an event filter would indeed be mostly
enough, together with some knowledge about whether the mouse is at a screen
edge.

As for the inner pixels, a hack would be to transpose clicks to 'window edge -
X pixels', which would probably effectively solve the issue. The true
solution would require a LOT of app support and would mean transposing to
just the inner window edge and have the app implement the event filters to
complete fitt's law and/or remove the borders otherwise.

Maybe I can give this a shot at aKademy. Will you be around to help if needed?

[Lubos Lunak]

Post by Martijn Klingens

Post by Lubos Lunak

Post by Maurizio Colucci
I wonder if we could have both benefits together? I mean, both being
able to resize maximized windows, and having the scrollbar touch the
edge of the screen.

I think the only reasonable way to achieve this no KWin border.

Not sure, see attachment. The red parts are the 'magic' regions. The window
borders will act normally EXCEPT when the mouse is at the very edge, i.e.
the red line AND the edge of the window is also the edge of the screen.

I think the parts are way too magic regions. There's no indication whatsoever
that the decorations borders next to the scrollbar etc. don't act like
expected and users trying to resize the window at that edge most probably
wouldn't like this much.

Post by Martijn Klingens
In that case mouse activity (at least clicks and drags, perhaps even
motion) is not handled by the deco, but instead replicated to the
application with the pixels transposed to the inner line.
There will still be a border, but at the edge of the border there will be a
part of the application again.
As for implementing this, I guess an event filter would indeed be mostly
enough, together with some knowledge about whether the mouse is at a screen
edge.

No. Event filters work just inside the application. The scrollbar is the
application's, the border is KWin's. KWin would need to know which parts of
the border should forward mouse operations. And I don't think adding toolkit
support for this would be trivial.

Post by Martijn Klingens
As for the inner pixels, a hack would be to transpose clicks to 'window
edge - X pixels', which would probably effectively solve the issue. The
true solution would require a LOT of app support and would mean transposing
to just the inner window edge and have the app implement the event filters
to complete fitt's law and/or remove the borders otherwise.
Maybe I can give this a shot at aKademy. Will you be around to help if needed?

Yes, except for the last three days. But given the non-obvious nature,
relatively small gain (how often would you actually use this?) and the amount
of work I don't think your proposal would be really worth it.

[Martijn Klingens]

Post by Lubos Lunak
I think the parts are way too magic regions. There's no indication
whatsoever that the decorations borders next to the scrollbar etc. don't
act like expected and users trying to resize the window at that edge most
probably wouldn't like this much.

It's only the LINE that would act magical, the rest of the border still allows
resizing.

Post by Lubos Lunak
Yes, except for the last three days. But given the non-obvious nature,
relatively small gain (how often would you actually use this?) and the
amount of work I don't think your proposal would be really worth it.

Can't judge the amount of work, so i trust you there :)

[David Laban]

Post by Maurizio Colucci
I wonder if we could have both benefits together? I mean, both being
able to resize maximized windows, and having the scrollbar touch the
edge of the screen.

I don't know if it's really worth confusing people who're trying to resize
windows just for the sake of putting the scrollbar at the edge of the screen.
Especially when most people (including my school) only buy mice with scroll
wheels when they replace dead mice nowadays anyway. I wouldn't be surprised
if they've stopped making two button mice actually, so it's only laptop users
that would benefit, and once you've been using a laptop for about a month,
you get used to using the cursor keys

*shrug* maybe it's just how I use the computer, but I don't think the
scrollbar is important enough warrant a strict adherence to fitt's law
anymore. I'm probably the only one.

I do quite like Martijn's idea though, and I reckon if you gave the scrollbar
a keramic-esque round bit that sticks out all the time, it wouldn't look too
awkward. I wish you the best of luck obviously, because even if it's not
*that* useful, it's still pretty cool :D

[Martijn Klingens]

Post by David Laban
I don't know if it's really worth confusing people who're trying to resize
windows just for the sake of putting the scrollbar at the edge of the screen.

This whole idea is based on the assumption that you don't normally resize a
window from the screen edge inwards, but rather from the other side outwards,
so the window border at the edge of the screen can be used for that.

It'd require usability testing to see if this assumption is true (I guess it
is), but I'm no expert and I have no figures.

Post by David Laban
Especially when most people (including my school) only buy mice
with scroll wheels when they replace dead mice nowadays anyway.

I have a scroll mouse too, but I still use the scroll bar rather often if I
want to scroll pages at a time rather than lines or when I want to move the
scrollbar to a distinct position by middle mouse click. So mouse wheel or
not, scroll bars are not obsolete yet, even for wheel mice. :)

[Maurizio Colucci]

Post by Martijn Klingens
I have a scroll mouse too, but I still use the scroll bar rather often if I
want to scroll pages at a time

Actually, it is the same for me. I actually don't like to reach for
the keyboard just to scroll a page down, e.g. when I am browsing
something. (And I am not always near the keyboard anyway, e.g. I
browse the internet while in bed :-) ).

So I use the scrollbar for paging, and it's nice when it's along the
edge of the screen. In Firefox, which does not have a one-pixel
border, you get used to it.

OTOH, if there was a _big_ button to page up and down, I wouldn't need
a scrollbar along the edge of the screen anymore.

Maurizio

[Thomas Zander]

Post by Maurizio Colucci
OTOH, if there was a _big_ button to page up and down, I wouldn't need
a scrollbar along the edge of the screen anymore.

Hihi; there is.
The empty part under the scrollbar-knob is that big button. Click in the
empty area and see it scroll up/down one page.

- --
Thomas Zander

[Maurizio Colucci]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Maurizio Colucci
OTOH, if there was a _big_ button to page up and down, I wouldn't need
a scrollbar along the edge of the screen anymore.

Hihi; there is.
The empty part under the scrollbar-knob is that big button. Click in the
empty area and see it scroll up/down one page.

Of course, that's what we were talking about. The point is that it's
not at the edge. So it should be at least four times as wide,
considering how often I use it.

Here's what: why don't we make all widgets automatically resize
themselves according to their usage frequency?

[Friedrich W. H. Kossebau]

Post by Maurizio Colucci

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Maurizio Colucci
OTOH, if there was a _big_ button to page up and down, I wouldn't need
a scrollbar along the edge of the screen anymore.

Hihi; there is.
The empty part under the scrollbar-knob is that big button. Click in the
empty area and see it scroll up/down one page.

Of course, that's what we were talking about. The point is that it's
not at the edge. So it should be at least four times as wide,
considering how often I use it.
Here's what: why don't we make all widgets automatically resize
themselves according to their usage frequency?

That is a good idea, but cannot be followed singely on. There are more aspects
to the appearance of a GUI. Like esthetics, semantics, learned parallels in
the real world.

Another problem would be the dynamics due to this, which gives the user less
control and might irritate him (like the dynamic menus by MS). A better
solution would be to still collect the usage informations in the background
but only adapt to/suggest a new interface on the user's explicit command.

Regards
Friedrich

[Thomas Zander]

 PS: Yes, that is the toplevel menubar in the screenshot. I'm perfectly
happy with it and I think it beats the normal menubar on any day of the
week, after one learns to use it properly. I don't think it'd be a good
default though.

I have the focus-follows-mouse; which is incompatible with this. So I hate
the toplevel menubar probably as much as you hate focus-follows-mouse :-)

- --
Thomas Zander

[Manuel Amador]

Post by Martijn Klingens
Thanks. This is especially useful since I turned off Plastik's horrible new
default of turning off resize borders on maximized windows, I still want to
be able to resize or move them.

To be incredibly, perfectly honest, if you did large amounts of window
resizing, you should have already learnt the ALT+Right mouse button and
ALT+Left mouse button a long time ago. Once I did, it felt like such a
relief: I have not used window borders for the past two years! It's so
much faster and easier to use that I routinely try to enlarge/shrink and
move windows using that trick on computers with Microsoft Windows.

Post by Martijn Klingens
Plus, I have lots of windows maximized only
in one direction, and the mixture looks horrible, as does the jumping if I
maximize the other direction as well.

[Lubos Lunak]

Post by Martijn Klingens

Post by Joseph Garvin

Post by Martijn Klingens
Well, the app is almost always in the corners with kwin and other sane
window managers. What's missing is to implement fitt's law in kwin for
those corners, something I miss a lot in fact. The chances that I want
to resize a window at the screen edge are almost nil, the chances that
I would intend a Fitt's behaviour are the rest, i.e. almost certain :)
Not sure if this reasoning applies to the rest of the KDE using
population though.

How about this -- if Kwin does window snapping to move an app into a
corner, then the corner pixel is considered part of the button, just
like if you had the window maximized? I think this would work quite
nicely with Kwin having Fitt's law improvements.

I'd make that the corner LINE, but the border is much thicker than that, so
indeed this is an awesome suggestion!

I think just the corner pixel is enough. If the point is just ramming the
mouse into the screen corner, you don't need more. The remaining part of the
corner could be still used for resizing (I suppose in such case the corner
should be made "bigger" so that one can move the mouse 50pixels below the
corner tip and still get diagonal resizing).

Post by Martijn Klingens
Aaron, what are your thoughts on this? Should we ask Lubos for this or do
you foresee negative consequences?

You can ask indeed, I'll just queue you up with all the other pending kwin
things. Or you can give it a shot yourself, it should be fairly trivial. I
think it'd just require modifying mousePosition() to return PositionCenter
for that point so that the mouse pointer doesn't change, and then handle the
mouse press/release in eventFilter(). Just
kdebase/kwin/lib/kcommondecoration.* should be all that needs altering. Feel
free to ask if you need anything more.

[Janne Ojaniemi]

Post by Janne Ojaniemi

Post by Martijn Klingens
The one change from the mac that I still do use after I turned off mac
menus is the close button in the upper left corner. That way both the
close button and the maximize button are adhering to fitt's law

Only if the app is maximised.

Correction: Windows do not follow Fitt's law even if they are maximised. I
just tried hitting the Close-button on a maximised window, and it does NOT
take advantage of screen-corners. This is with default Plastik on 3.4.2

[Aaron J. Seigo]

Post by Janne Ojaniemi

Post by Janne Ojaniemi

Post by Martijn Klingens
The one change from the mac that I still do use after I turned off mac
menus is the close button in the upper left corner. That way both the
close button and the maximize button are adhering to fitt's law

Only if the app is maximised.

Correction: Windows do not follow Fitt's law even if they are maximised. I
just tried hitting the Close-button on a maximised window, and it does NOT
take advantage of screen-corners. This is with default Plastik on 3.4.2

you need to turn off the option to move/resize maximized windows. this is
currently the default in svn.

[Manuel Amador]

I know this thread is dead, but I would like to make a radical
suggestion which I guess would keep the Mac OS menu on top and Windows
menu on app camps content.

Merge the titlebars and menus.

(/me ducks and covers)

[V] File Edit View Edit Evolution - Mail [_][^][X]

On the justifications:

- we'd save the space everyone is bitchin about wasting in the title
bars
- we'd comply with Fitt
- put some use for those wasted title bars in maximized windows!
- already dialogs and the like do not have menubars
- bleh!

On the technical feasibility:

This is certainly technically possible, right? Albeit it would need
some cooperation between KWin and the applications that wish to support
this.

On how it would look:

I have NO idea past my ascii depiction (see above), but it certainly
would be interesting.

How bout that for KDE 4?

[Sean Lynch]

This has already been similarly implemented as a windows decoration
(http://kdelook.org/content/show.php?content=19455) unless I am mistaken as
to the implementation.

-Sean

Post by Manuel Amador
I know this thread is dead, but I would like to make a radical
suggestion which I guess would keep the Mac OS menu on top and Windows
menu on app camps content.
Merge the titlebars and menus.
(/me ducks and covers)
[V] File Edit View Edit Evolution - Mail [_][^][X]
- we'd save the space everyone is bitchin about wasting in the title
bars
- we'd comply with Fitt
- put some use for those wasted title bars in maximized windows!
- already dialogs and the like do not have menubars
- bleh!
This is certainly technically possible, right? Albeit it would need
some cooperation between KWin and the applications that wish to support
this.
I have NO idea past my ascii depiction (see above), but it certainly
would be interesting.
How bout that for KDE 4?

[Manuel Amador]

Yes but the deco still has window border, negating Fitt's law.

Post by Sean Lynch
This has already been similarly implemented as a windows decoration
(http://kdelook.org/content/show.php?content=19455) unless I am mistaken as
to the implementation.
-Sean

Post by Manuel Amador
I know this thread is dead, but I would like to make a radical
suggestion which I guess would keep the Mac OS menu on top and Windows
menu on app camps content.
Merge the titlebars and menus.
(/me ducks and covers)
[V] File Edit View Edit Evolution - Mail [_][^][X]
- we'd save the space everyone is bitchin about wasting in the title
bars
- we'd comply with Fitt
- put some use for those wasted title bars in maximized windows!
- already dialogs and the like do not have menubars
- bleh!
This is certainly technically possible, right? Albeit it would need
some cooperation between KWin and the applications that wish to support
this.
I have NO idea past my ascii depiction (see above), but it certainly
would be interesting.
How bout that for KDE 4?

_______________________________________________
kde-usability mailing list
https://mail.kde.org/mailman/listinfo/kde-usability

[Jason Keirstead]

Post by Manuel Amador
Yes but the deco still has window border, negating Fitt's law.

The only way such a thing would comply with Fitt would be if all the windows
were maximized all the time. And if that is your case, then why have a Wm at
all.

The whole point of the Mac OS bar is that a window doesn't need to be
maximized to comply with Fitt.

[Maurizio Colucci]

Post by Jason Keirstead
The only way such a thing would comply with Fitt would be if all the windows
were maximized all the time. And if that is your case, then why have a Wm at
all.

That's actually a good question, since forcing the user to manage the
size and position of windows is nothing but a design error, due
programmers' lazyness, which we are perpetrating through the years.

Maurizio

[Maurizio Colucci]

Post by Maurizio Colucci
That's actually a good question, since forcing the user to manage the
size and position of windows is nothing but a design error, due
programmers' lazyness, which we are perpetrating through the years.

curiosity begs me to ask: do you really think that programmers are lazy?

Considering how often we press the WONTFIX button and pretend a
problem does not exist? You bet!

Just kidding. What I meant was that the problem might have
originated out of lazyness. "Look, let's just allow the user to do
whatever he wants with windows and let's get this over with". But no
big deal. Bye

Maurizio

[Joseph Garvin]

Post by Aaron J. Seigo
unless you are only viewing documents, this is completely false.
consider 2 windows on screen at the same time. the menu in window 1 does not
take space away from window 2. when working in window 2, who cares that there
is a menu in window 1, unless of course you want to access its menus in which
case the mac way is slower.

I think what he meant was that extra space is taken up in each window by
the existence of the menu, thus taking up more screenspace. If I have
two windows open, I'm drawing the menu twice, so maybe 80x15 extra
pixels are used for each window open. The more windows open, the more
pixels you're saving, and the more documents you can probably get open
at once without any of the windows _overlapping_. It seems to waste much
more space horizontally than vertically (menus are the same height no
matter how you scale the window).

Post by Aaron J. Seigo
- It makes it faster to access the menu's because they take advantage of
screen-borders.
and makes it harder to hit maximize window titlebars and assumes menus are
that important. consider that MS Vista is actually _demoting_ menus. there's
a reason for that.

I've read the occasional Vista article, but I'm not sure what you're
talking about. Googling for "vista demoting menus" didn't help. Link me?

Post by Aaron J. Seigo

Post by Janne Ojaniemi
"Every window that has menus puts them in a separate menu bar inside the
window. This (a) wastes screen real estate,

i've already addressed this issue. it's bogus and shows the fellow has very
little idea what he's really talking about -=(

Assuming you understood what he said :P

Post by Aaron J. Seigo

Post by Janne Ojaniemi
(b) is confusing (even experts
occasionally click the wrong menu bar by accident),

this actually happens more often on MacOS than on Windows/KDE since with
"menubar in window" the context is obvious.

It does? Where's the data? ;)

Post by Aaron J. Seigo

Post by Janne Ojaniemi
(d) works badly for windows
near the bottom or right of the screen (for which menus unexpectedly open
upward or leftward), and

where "badly" is used as a synonym for "appears to the left instead of the
right". please.

Where "badly" is used as a synonym for "inconsistent."

The only thing I can see going against this is the context issue, but I
don't weigh that too strongly. Users would learn the same behavior that
they have in every other app -- menu actions work on what is currently
selected. Most of the time when you have an application with multiple
windows it's for document viewing, in which case the menus for each
window are going to be identical anyway, and users are going to be
clicking inside the document's window anyway (previously to select its
menu, now to just select the window itself).

In some sense, KDE apps already do this. Nobody complains that there
isn't a separate menubar for each tab under Konqueror do they?

[Aaron J. Seigo]

Post by Joseph Garvin

Post by Aaron J. Seigo
unless you are only viewing documents, this is completely false.
consider 2 windows on screen at the same time. the menu in window 1 does
not take space away from window 2. when working in window 2, who cares
that there is a menu in window 1, unless of course you want to access its
menus in which case the mac way is slower.

I think what he meant was that extra space is taken up in each window by
the existence of the menu, thus taking up more screenspace. If I have
two windows open, I'm drawing the menu twice, so maybe 80x15 extra
pixels are used for each window open. The more windows open, the more
pixels you're saving, and the more documents you can probably get open
at once without any of the windows _overlapping_. It seems to waste much
more space horizontally than vertically (menus are the same height no
matter how you scale the window).

22 vertical pixels hasn't made a realistic difference for years. and
overlapping or maximized windows are the norm mor for reasons of the
horizontal than the vertical IME.

Post by Joseph Garvin

Post by Aaron J. Seigo
- It makes it faster to access the menu's because they take advantage of
screen-borders.
and makes it harder to hit maximize window titlebars and assumes menus are
that important. consider that MS Vista is actually _demoting_ menus.
there's a reason for that.

I've read the occasional Vista article, but I'm not sure what you're
talking about. Googling for "vista demoting menus" didn't help. Link me?

if you look at screenshots of Vista, the menus aren't at the top of the window
anymore. it's shoved down below with the toolbars.

Post by Joseph Garvin

Post by Aaron J. Seigo

Post by Janne Ojaniemi
"Every window that has menus puts them in a separate menu bar inside the
window. This (a) wastes screen real estate,

i've already addressed this issue. it's bogus and shows the fellow has
very little idea what he's really talking about -=(

Assuming you understood what he said :P

perhaps my mistake is in assuming he's discussing modern computers and not
macs from 1984 that have 9 inch screens.

Post by Joseph Garvin

Post by Aaron J. Seigo

Post by Janne Ojaniemi
(b) is confusing (even experts
occasionally click the wrong menu bar by accident),

this actually happens more often on MacOS than on Windows/KDE since with
"menubar in window" the context is obvious.

It does? Where's the data? ;)

heh. bleh. how about this: years of using macs personally and application of
basic principles? =)

Post by Joseph Garvin

Post by Aaron J. Seigo

Post by Janne Ojaniemi
(d) works badly for windows
near the bottom or right of the screen (for which menus unexpectedly open
upward or leftward), and

where "badly" is used as a synonym for "appears to the left instead of the
right". please.

Where "badly" is used as a synonym for "inconsistent."

this happens with context menus as well. and i don't think people are exactly
that hard of understanding. it's not like they pop out differently or the
interaction model is different. our visual processing is actually pretty well
tuned for these kinds of spatial issues.

Post by Joseph Garvin
The only thing I can see going against this is the context issue, but I
don't weigh that too strongly.

this is perhaps the most important thing, however.

Post by Joseph Garvin
Users would learn the same behavior that
they have in every other app -- menu actions work on what is currently
selected.

of course they'll learn. that's not the point. the point is whether it's
effective or not.

Post by Joseph Garvin
Most of the time when you have an application with multiple
windows it's for document viewing, in which case the menus for each
window are going to be identical anyway, and users are going to be
clicking inside the document's window anyway (previously to select its
menu, now to just select the window itself).

and which document are you working on when the menu is the same? when the menu
changes it's actually MORE obvious which document you are working on.

Post by Joseph Garvin
In some sense, KDE apps already do this. Nobody complains that there
isn't a separate menubar for each tab under Konqueror do they?

no, because the menu is always in the correct context and it's bleedingly
obvious which tab the menus are going to act on because only one is visible
at a time.

[Friedrich W. H. Kossebau]

Post by Aaron J. Seigo

Post by Joseph Garvin
In some sense, KDE apps already do this. Nobody complains that there
isn't a separate menubar for each tab under Konqueror do they?

no, because the menu is always in the correct context and it's bleedingly
obvious which tab the menus are going to act on because only one is visible
at a time.

Yes and no. If you want to close a tab (neglecting the RMB) you first have to
select the tab. ;)

But rather tabs think about splitted views like with konqueror*. This is what
Joseph surely had in mind. You see all views but first have to change focus
to get the app menu to work on a view. And nearly noone seems to have claimed
to get menu bars per view. Well, perhaps only power users use it and know
about shortcuts or RMB.

* Those who will rewrite Konqueror should take KMDI, add the split feature and
then reuse KMDI for Konqueror, BTW ;) If we do not even come up with some
more clever shell...

Friedrich

[Aaron J. Seigo]

Post by Friedrich W. H. Kossebau
But rather tabs think about splitted views like with konqueror*. This is
what Joseph surely had in mind. You see all views but first have to change
focus to get the app menu to work on a view. And nearly noone seems to have
claimed to get menu bars per view. Well, perhaps only power users use it
and know about shortcuts or RMB.

split views causes all sorts of problems for people due to it not being overly
obvious which is the active one. great for clicking around in the views, hell
for using commands external to the views.

[Friedrich W. H. Kossebau]

Post by Aaron J. Seigo

Post by Friedrich W. H. Kossebau
But rather tabs think about splitted views like with konqueror*. This is
what Joseph surely had in mind. You see all views but first have to
change focus to get the app menu to work on a view. And nearly noone
seems to have claimed to get menu bars per view. Well, perhaps only power
users use it and know about shortcuts or RMB.

split views causes all sorts of problems for people due to it not being
overly obvious which is the active one.

Only due to a currently bad visual markup. One can easily tell which floating
window is focussed, something similar is possible with (splitted) views
inside a window.

Friedrich

[julian oliver]

Post by Aaron J. Seigo

Post by Janne Ojaniemi
- Menus are in constistent location. No matter where the app-window is, the
menu's are aways in exact same place

yes, as far away from the context as possible ;)

Post by Janne Ojaniemi
- It saves screen-space, since the menubar would not be repeated in each
app-window. And since user can only access one menubar at a time, having
several menubars is a waste

unless you are only viewing documents, this is completely false.
consider 2 windows on screen at the same time. the menu in window 1 does not
take space away from window 2. when working in window 2, who cares that there
is a menu in window 1, unless of course you want to access its menus in which
case the mac way is slower.

i agree. i've been reading Raskins justification for this, and toying
around with an OSX Tiger desktop alongside. i've found that this
'finder' top-menubar paradigm is actually alot more work than KDE offers
already. it's difficult to mentally manage and topographically one dimensional
in comparison to that of application client window-specific menus.

for instance, i found that when having two image displays open from two
different applications in OSX, i was having to 'test' which belonged
to which application by reading for changes in the top menu bar.

it's no wonder OSX users need a pager/client overview as ridiculous as 'Expose'.

the only gain in real estate is area per window client, and that gain is slight.
in that sense this model does have a case.

Fitts Law however does have an argument where pointer targets are concerned.
it's seems these guys are taking that up the mountain:

http://www.symphonyos.com/

julian
--
_ _ _
___ ___| |___ __| |_ _ __ __ _ _ _| |__ ___
(_-</ -_) / -_) _| _| '_ \/ _` | '_| / /(_-<
/__/\___|_\___\__|\__| .__/\__,_|_| |_\_\/__/
|_http://selectparks.net

Artist in Residence IT University of Copenhagen
Department of Digital Aesthetics and Communication
Rued Langgaards Vej 7
DK-2300 København S
http://game.itu.dk
skype: julianoliver

NB: email sent in HTML format will not be read.

[Joseph Garvin]

Post by julian oliver
it's no wonder OSX users need a pager/client overview as ridiculous as 'Expose'.

I don't know if they 'need' it. It just kicks everything else six ways
to Sunday and looks damn cool.

Kompose will let you do the same in KDE but isn't nearly as spiffy looking.

[Janne Ojaniemi]

I'm glad that my proposal has sparked as much discussion as it has :).

Post by Aaron J. Seigo

Post by Janne Ojaniemi
- Menus are in constistent location. No matter where the app-window is,
the menu's are aways in exact same place

yes, as far away from the context as possible ;)

Even though they would be a bit further away from the context, they would be a
lot easier to access since they are in screen-corner.

Post by Aaron J. Seigo

Post by Janne Ojaniemi
- It saves screen-space, since the menubar would not be repeated in each
app-window. And since user can only access one menubar at a time, having
several menubars is a waste

unless you are only viewing documents, this is completely false.
consider 2 windows on screen at the same time. the menu in window 1 does
not take space away from window 2. when working in window 2, who cares that
there is a menu in window 1, unless of course you want to access its menus
in which case the mac way is slower.

As it was already mentioned, I was referring to the fact that having several
menubars visible in the screen in the same time wastes screen-space. Yes, we
have high-resolution screens these days (mine runs at 1280x1024), but we
shouldn't waste space anyway. I still feel sometimes that I could use more
screen-space.

Post by Aaron J. Seigo
and makes it harder to hit maximize window titlebars and assumes menus are
that important. consider that MS Vista is actually _demoting_ menus.
there's a reason for that.

AFAIK, the menu's in Vista are only demoted in IE 7, where the menubar is for
some weird reason under the tab-bar. In other screen-shots I have seen, the
windows don't seem to have any menubar. I'm not sure what they have done with
it, but the actual windows don't seem to have menubars (apart from IE7), so
even Vista resembles OS X in this aspect (although it doesn't seem to have
universal menubar, but the actual windows resemble OS X). So, if we are in
the "Follow Vista"-mode, we should remove menubars from windows ;).

Post by Aaron J. Seigo
assuming we're thinking of the same person, he was a graphic designer IIRC =)

In his website he says he's an "interface designer".

Post by Aaron J. Seigo
i've already addressed this issue. it's bogus and shows the fellow has very
little idea what he's really talking about -=(

it's not bogus. I just think that you misunderstood what was meant by it.

Post by Aaron J. Seigo
where "badly" is used as a synonym for "appears to the left instead of the
right". please.

When something is inconsistent, it's bad.If some menu always open to the left
(for example) but it suddenly open to the right, it's bad. User expects it to
behave in certain way, and when it doesn't, it causes confusion.

Post by Aaron J. Seigo
you need to take a page from software optimization here: optimize the time
critical parts, don't care about the rest.

Time critical parts are the tasks the user does more or less manually. And
accessing menu's is one of those tasks.

Post by Aaron J. Seigo
and how do you ballance his "points" against the issue of lacking context
for the menubar?

You mean that the menubar is in the top of the screen, while rest of the app
is elsewhere? I don't really see that as a problem. I have used both OS X and
KDE with Mac OS-style menubar, and I have no problems with it. And from
seeing newbies use OS X, they don't seem to have any problems associating the
menubar with the app.

Post by Aaron J. Seigo
see, this argument that you just used is very wrong headed. let me give you
lots and lots of people are starting to use KDE, so it seems to me
that they do not find anything wrong with the KDE Control Center.
we should therefore not change it. in fact, Apple should think about using
it.
are you laughing yet? ;)

Your comparison is not valid. In OS X, the menubar is used ALL the time. In
KDE, the menubar is used all the time. In KDE (or just about any system), the
tool to configure the system is only used rarely. You are comparing something
that is central to the way the UI works, to something that is used very very
rarely.

[Alan]

Post by Janne Ojaniemi
http://img332.imageshack.us/my.php?image=kde4a8dn.jpg

Yes, the Mac-style menu bar at the top of the screen does follow Fitt's law
but Fitt is not God - he just has some good ideas.

As screens get larger and larger - think 21" plus - it gets annoying to move a
mouse pointer all the way to the top of the screen just to close a small
window which may be located at the bottom of the screen.

I work with a printing pre-press department and 21" screens are the norm and
we are starting to think about even larger screens. The kit is mostly Mac and
I find when I use a Mac that sweeping the mouse all over the desk to access
the menu then the window I'm working on a PITA.

The other problem with the single Mac-style menu is when you have multiple
windows open on the screen - it's not always immediately obvious which window
the current menu bar refers to.

Fitt may be right that it's more difficult to hit the menu bar on the window
itself but most of us seem to manage it without much trouble.

Alan

PS. It shouldn't be Fitt's Law, just Fitt's Proposal.

[Janne Ojaniemi]

Post by Alan
As screens get larger and larger - think 21" plus - it gets annoying to
move a mouse pointer all the way to the top of the screen just to close a
small window which may be located at the bottom of the screen.

Put the point is that with those menu's in a screen-border, you can move the
pointer the much quicker because you do not have to carefully place the
cursor over the menu.

Post by Alan
I work with a printing pre-press department and 21" screens are the norm
and we are starting to think about even larger screens. The kit is mostly
Mac and I find when I use a Mac that sweeping the mouse all over the desk
to access the menu then the window I'm working on a PITA.

Most people dont have 21" screen. And even mac-users with those humungous
Apple-screen seems to manage just fine.

Post by Alan
The other problem with the single Mac-style menu is when you have multiple
windows open on the screen - it's not always immediately obvious which
window the current menu bar refers to.

Yes it is. For starters, the out-of-focus window look different from the
active app (KDE could do this even better than OS X does IMO). And second:
the menubar actually says which app it belongs to.

Post by Alan
Fitt may be right that it's more difficult to hit the menu bar on the
window itself but most of us seem to manage it without much trouble.

Is that a valid reason to NOT think of ways on how to improve the GUI? Most
users seemed to manage just fine with KDE 1.1, should the progress therefore
stop there?

Post by Alan
PS. It shouldn't be Fitt's Law, just Fitt's Proposal.

Well, the law basically says that objectins in screen-borders and corners are
easier/faster to access that those that are not. And that is a fact, they
are.

[Martijn Klingens]

Post by Janne Ojaniemi

Post by Alan
As screens get larger and larger - think 21" plus - it gets annoying to
move a mouse pointer all the way to the top of the screen just to close a
small window which may be located at the bottom of the screen.

Put the point is that with those menu's in a screen-border, you can move
the pointer the much quicker because you do not have to carefully place the
cursor over the menu.

This is true for objects that are close to the screen edge anyway. However, on
larger screens the time needed for travelling the mouse to a Fitt's Law edge
is still larger than the amount of time needed for the more precise movement
of a menu bar in the window.

The smaller the screen, or the more maximized windows you have, the bigger the
advantage of Fitt's Law.

Post by Janne Ojaniemi

Post by Alan
The other problem with the single Mac-style menu is when you have
multiple windows open on the screen - it's not always immediately obvious
which window the current menu bar refers to.

Yes it is. For starters, the out-of-focus window look different from the
the menubar actually says which app it belongs to.

You are aware that Alan is not making this up, but refers to his OWN
experience, right? I know more mac-using people who have the same problem.
Sure there is the different look of unfocused windows, but that doesn't help
all that much for most people.

Most people on this list who did actual observations conclude that mac-menus
are deemed better than they are in practice. And having used them myself as
well I can only agree with them.

As Aaron said, back in the 1984 Apple II days they made sense. People hardly
used more than one app at the same time -- heck, the system didn't even have
the resources for that back then. Screen resolutions were a fraction of even
the laptop screens. On modern systems people have a LOT more windows open and
screens are bigger. Toolbars and context menus replaced menu bars as the main
entry point. What used to be the most frequent action (menu bars) is now
second after the close/maximize buttons, and even in the cases where the menu
is in frequent use (mostly poorly designed apps if it happens regularly) it
is often too far from the screen edge to make Fitt give a benefit.

Post by Janne Ojaniemi
Is that a valid reason to NOT think of ways on how to improve the GUI?

No.

Post by Janne Ojaniemi
Most users seemed to manage just fine with KDE 1.1, should the progress
therefore stop there?

No.

But: Is changing to Mac menus progress? I for one dare saying it is not, it
would be regress instead.

Post by Janne Ojaniemi
Well, the law basically says that objectins in screen-borders and corners
are easier/faster to access that those that are not. And that is a fact,
they are.

... but only if the saved positioning time outweighs the extra travel time as
I said above :)

[Harijs Buss]

Post by Martijn Klingens
But: Is changing to Mac menus progress?

Absolutely not.

Post by Martijn Klingens
I for one dare saying it is not, it would be regress instead.

Yes. Specially on big screen (21", 1600x1200 in my case).
And I absolutely NEVER use maximized windows. There are usually about a dozen
windows open on my 2 virtual desktops all the time. As fast as I would be
able to afford this, there will be 2 real LCDs on my desk. It is fast and
easy to use multiple windows.

Certainly people are different. That's why nobody should overgeneralize (like
"everybody uses maximized windows"... ). They don't. Add new features if
necessary but don't take off old ones.

Personally I am very happy with Advanced -> Special Windows Settings. It is
just what I had wanted all the time since I started to use Linux and KDE. My
sincere "Big Thanks!" to people who developed this feature!

Post by Martijn Klingens
... but only if the saved positioning time outweighs the extra travel time
as I said above :)

Exactly. On big high resolution screens it doesn't. And bigger screens are
main direction of development, we all are going to have cheap but good big
screens in near future as LCD production becomes cheaper. Remember what
happened to memory ;-)

Harry

[Mikolaj Machowski]

Post by Harijs Buss

Post by Martijn Klingens
But: Is changing to Mac menus progress?

Absolutely not.

Post by Martijn Klingens
I for one dare saying it is not, it would be regress instead.

Yes. Specially on big screen (21", 1600x1200 in my case).
And I absolutely NEVER use maximized windows. There are usually about a
dozen windows open on my 2 virtual desktops all the time. As fast as I
would be able to afford this, there will be 2 real LCDs on my desk. It
is fast and easy to use multiple windows.
Certainly people are different. That's why nobody should overgeneralize
(like "everybody uses maximized windows"... ). They don't. Add new
features if necessary but don't take off old ones.

You also overgeneralizes. Standard monitor at the moment is 17" with
1024x768 and 2 steps more. In a year it will be probably 19".

People don't maximize their windows if application isn't doing this
automatically. But at the same time they are rarely keeping more than
one window open at the time.

m.

[James Ots]

Post by Mikolaj Machowski
People don't maximize their windows if application isn't doing this
automatically.

I do sometimes.

Post by Mikolaj Machowski
But at the same time they are rarely keeping more than
one window open at the time.

I nearly always do so.

Post by Mikolaj Machowski

Post by Alan
The other problem with the single Mac-style menu is when you have
multiple windows open on the screen - it's not always immediately obvious
which window the current menu bar refers to.

Yes it is. For starters, the out-of-focus window look different from the
the menubar actually says which app it belongs to.

I've been using Mac-style menus for a couple of years at least now, and I
still sometimes go for the menu when the wrong window is selected. Although
it hasn't put me off entirely yet. I guess I just use the mouse on the
menubar so infrequently that I find it more useful to have the menu out of
the way.

Anyway, I've been reading all the arguments and I'm now persuaded that the
Mac-OS menu would be a bad default. Even though I like it.

[julian oliver]

Post by James Ots
Anyway, I've been reading all the arguments and I'm now persuaded that the
Mac-OS menu would be a bad default. Even though I like it.

Macs are mostly bought as personal machines.

people make a choice to buy an Apple and so work a little harder to learn and thus
appreciate the interface. as a default useability paradigm they're pretty challenging
however. personally i find the mouse-work (look up, point up) to be a boring yo-yo
and i tire of it quickly. it's obviously more mouse-work than that of the
current KDE model, there's little argument there (visualise working in
the Gimp across OSX and then KDE, trace the mouse trajectory).

however with learning something entirely new always comes a sense of ownership, internal reward. people earn their Apples and seem to enjoy this. switchers to Macs or the Gnome DE rant about how much they like the change itself, as a positively refreshing experience.
the change they are speaking of is from that the 'windows layout'.

it's a completely different market i think. KDE has bigger fish to fry
it seems; an industrial strength, flexible 'general utility' DE. it may
not be as 'loved' as others, but it will be far more widely and
comfortably deployed.

julian
--
_ _ _
___ ___| |___ __| |_ _ __ __ _ _ _| |__ ___
(_-</ -_) / -_) _| _| '_ \/ _` | '_| / /(_-<
/__/\___|_\___\__|\__| .__/\__,_|_| |_\_\/__/
|_http://selectparks.net

Artist in Residence IT University of Copenhagen
Department of Digital Aesthetics and Communication
Rued Langgaards Vej 7
DK-2300 København S
http://game.itu.dk
skype: julianoliver

NB: email sent in HTML format will not be read.

[Alan]

On Friday 12 August 2005 01:23, julian oliver wrote:
<snip>

pretty challenging however. personally i find the mouse-work (look up,
point up) to be a boring yo-yo and i tire of it quickly. it's obviously
more mouse-work than that of the current KDE model, there's little argument
there (visualise working in the Gimp across OSX and then KDE, trace the
mouse trajectory).

</snip>

This is my contention with the Mac-OS menu positioning on larger monitors.
Back in the days of yore when I owned a 'Fat' Mac (with a whole 20Mb HDD!)
and the 9 inch B&W screen the fixed menu position was just fine.
Now I run a 19 inch CRT and look longingly at matching TFTs and I know, as the
technology moves on, workstation screens are just going to get bigger and
bigger so moving a mouse all over the desk to get the pointer from a small
window at the bottom of the screen to a menu at the top just seems damn
stupid. Yes, I have heard of mouse acceleration - tried it and hate it!

The Mac paradigm is fine for small screens - when I get my A1 size, curved,
panoramic super high-definition monitor (I can dream can't I?) a menu miles
away from my working window is really going to be lunacy.

- Alan

[Lubos Lunak]

Post by Alan
<snip>

pretty challenging however. personally i find the mouse-work (look up,
point up) to be a boring yo-yo and i tire of it quickly. it's obviously
more mouse-work than that of the current KDE model, there's little
argument there (visualise working in the Gimp across OSX and then KDE,
trace the mouse trajectory).

Wrong.

Post by Alan
</snip>
This is my contention with the Mac-OS menu positioning on larger monitors.
Back in the days of yore when I owned a 'Fat' Mac (with a whole 20Mb HDD!)
and the 9 inch B&W screen the fixed menu position was just fine.
Now I run a 19 inch CRT and look longingly at matching TFTs and I know, as
the technology moves on, workstation screens are just going to get bigger
and bigger so moving a mouse all over the desk to get the pointer from a
small window at the bottom of the screen to a menu at the top just seems
damn stupid.

And wrong again.

Or perhaps not that wrong actually, since you both admit you don't really
count as you've both barely tried it. I've been using it since quite some
time and on my 19" 1280x960 (used to be even 1400x1050) I can faster select a
menu entry from the bottom of the screen than a toolbar icon from the upper
half of the screen. Especially when I use the mouse mostly with my left hand
to be more effective with the right hand with the keyboard. And I can move
the mouse from the bottom to the top of the screen without raising my hand
and there's still a reserve. So much for more mouse work.

Anyway, what's the point of this discussion? Pretty much everybody here
agrees the macmenu would be bad as a default, and it would be bad as a
default for a couple of reasons. So why still beat the dead horse, is this
some kind of a chit-chat forum?

[Mikolaj Machowski]

Post by James Ots

Post by Mikolaj Machowski
People don't maximize their windows if application isn't doing this
automatically.

I do sometimes.

Problem with you, me and most people on this list - they not qualify as
common users :) Even usability tests aren't fully free from distortion.
People who are taking part in them are usually acting slightly different
than in day to day activities.

I have few "objects" and observing them without letting them to knew
that they are under observation. Few most common observations (and hotly
discussed here):

- they have problems with context menus
- they don't like to have more than one window opened
- they don't really understand difference between one and double click.
For them one click everywhere is Good Thing(tm)!

Post by James Ots

Post by Mikolaj Machowski
But at the same time they are rarely keeping more than
one window open at the time.

I nearly always do so.

See above.

Post by James Ots
Anyway, I've been reading all the arguments and I'm now persuaded that
the Mac-OS menu would be a bad default. Even though I like it.

I agree. I also like Mac-OS menu but for "my" users it could be very
confusing with more than one window open.

m.

[Maurizio Colucci]

Post by Mikolaj Machowski
- they don't like to have more than one window opened

How true... every non-power windows user I know (actually I know four)
closes a program before opening another. Including Explorer. This way,
they avoid using the taskbar at all. I really don't know why they do
that. Is it just to avoid using the taskbar?

Maurizio

[John Tapsell]

No, they do it because they are afraid their computer will crash if they use
too many programs at once. They don't want to overwork their PC because its
very expensive for them to get fixed if it breaks.

Post by Maurizio Colucci

Post by Mikolaj Machowski
- they don't like to have more than one window opened

How true... every non-power windows user I know (actually I know four)
closes a program before opening another. Including Explorer. This way,
they avoid using the taskbar at all. I really don't know why they do
that. Is it just to avoid using the taskbar?
Maurizio
_______________________________________________
kde-usability mailing list
https://mail.kde.org/mailman/listinfo/kde-usability

[Joseph Garvin]

Post by John Tapsell
No, they do it because they are afraid their computer will crash if they use
too many programs at once. They don't want to overwork their PC because its
very expensive for them to get fixed if it breaks.

I can vouch for my mom actually saying this. Windows stability standards
make it just about true :P

Post by John Tapsell

Post by Maurizio Colucci

Post by Mikolaj Machowski
- they don't like to have more than one window opened

How true... every non-power windows user I know (actually I know four)
closes a program before opening another. Including Explorer. This way,
they avoid using the taskbar at all. I really don't know why they do
that. Is it just to avoid using the taskbar?
Maurizio
_______________________________________________
kde-usability mailing list
https://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
kde-usability mailing list
https://mail.kde.org/mailman/listinfo/kde-usability

[Manuel Amador]

Post by Joseph Garvin

Post by John Tapsell
No, they do it because they are afraid their computer will crash if they use
too many programs at once. They don't want to overwork their PC because its
very expensive for them to get fixed if it breaks.

I can vouch for my mom actually saying this. Windows stability standards
make it just about true :P

/me joins to this chorus
I've been told by easily more than five individuals that I break their
computers because I usually do large navigation sessions in parallel,
opening multiple browser windows. Phrases like "NONOOO, it's going to
freeze" are quite common around me and Windows computers.

...no, I do not hang computers on purpose.

Post by Joseph Garvin

Post by John Tapsell

Post by Maurizio Colucci

Post by Mikolaj Machowski
- they don't like to have more than one window opened

How true... every non-power windows user I know (actually I know four)
closes a program before opening another. Including Explorer. This way,
they avoid using the taskbar at all. I really don't know why they do
that. Is it just to avoid using the taskbar?
Maurizio
_______________________________________________
kde-usability mailing list
https://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
kde-usability mailing list
https://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
kde-usability mailing list
https://mail.kde.org/mailman/listinfo/kde-usability

[Ian K]

Post by Mikolaj Machowski

Post by James Ots
Anyway, I've been reading all the arguments and I'm now persuaded that
the Mac-OS menu would be a bad default. Even though I like it.

I agree. I also like Mac-OS menu but for "my" users it could be very
confusing with more than one window open.
m.

Hi there,
The only problem I see with the MAC OS X menu, is compatability. I like
it also,
but its in the way when GTK (or other) programs are active, as they dont
work
with it.

I think it is a bad default, although it should remain an option. I just
dont think it is
"good" enough to use regularly, since 50% of the programs dont like it.

Also, towards contributing to this 'thread' as a whole, I quite dislike
having applicatrions
fully maximized. I like to see my desktop and such. Only exception is a
Web Browser.
Cheers,
Ian

[ra1n]

Post by Alan

Post by Janne Ojaniemi
http://img332.imageshack.us/my.php?image=kde4a8dn.jpg

Yes, the Mac-style menu bar at the top of the screen does follow Fitt's law
but Fitt is not God - he just has some good ideas.
As screens get larger and larger - think 21" plus - it gets annoying to
move a mouse pointer all the way to the top of the screen just to close a
small window which may be located at the bottom of the screen.

There are still keyboard shortcuts, I saw a lot of mac users using them, and
they speed up the work (this is true on kde too)

Post by Alan
I work with a printing pre-press department and 21" screens are the norm
and we are starting to think about even larger screens. The kit is mostly
Mac and I find when I use a Mac that sweeping the mouse all over the desk
to access the menu then the window I'm working on a PITA.
The other problem with the single Mac-style menu is when you have multiple
windows open on the screen - it's not always immediately obvious which
window the current menu bar refers to.

This is not right, the window decoration gives immediately the idea of the
currently active window, on MacOS (but I think on the baghira theme too) the
name of the currently active app it's shown on the menubar, both those things
help a lot in identifying the active window :-D

[s***@obso1337.org]

Post by Janne Ojaniemi
http://img332.imageshack.us/my.php?image=kde4a8dn.jpg

Uhm.. Apple has patents with the fixed top menu like that. Is that legal,
even though you arnt technically selling KDE?

[Aaron J. Seigo]

Post by s***@obso1337.org

Post by Janne Ojaniemi
http://img332.imageshack.us/my.php?image=kde4a8dn.jpg

Uhm.. Apple has patents with the fixed top menu like that. Is that legal,
even though you arnt technically selling KDE?

we've been shipping kde with that functionality for a couple years now.

[Joseph Garvin]

Post by Alan
I work with a printing pre-press department and 21" screens are the norm and
we are starting to think about even larger screens. The kit is mostly Mac and
I find when I use a Mac that sweeping the mouse all over the desk to access
the menu then the window I'm working on a PITA.

I think that's a bit skewed. Printing and Graphs department/shops always
have larger monitors. Out of all the desktops I've seen at my college,
mine has the largest monitor and it's only 19". And having to move the
mouse too much to get across the screen is a mouse sensitivity issue,
not a usability one.

[Aaron J. Seigo]

Post by Joseph Garvin
mine has the largest monitor and it's only 19". And having to move the
mouse too much to get across the screen is a mouse sensitivity issue,
not a usability one.

i'd just note that things like "mouse sensitivity" are usability related =)

[Joseph Garvin]

Post by Aaron J. Seigo

Post by Joseph Garvin
mine has the largest monitor and it's only 19". And having to move the
mouse too much to get across the screen is a mouse sensitivity issue,
not a usability one.

i'd just note that things like "mouse sensitivity" are usability related =)

True, but in this case I don't think counts against the idea. At worst
it might be necessary to write some code to change sensitivity default
based on resolution.

[Janne Ojaniemi]

I must say that even though my proposal has not received glowing endorsement,
I'm happy to see that it sparked a lively discussion which even created some
improvements for KDE :). Thanks!