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 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
. 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, s too complicated.
2. Remember Fs law! in the screen-borders are easier to access.
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:
(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. 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 S-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? Is the close
-button. What is it doing in there you ask? Is 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 LT 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 D-button. This provides a
quick access to the desktop, turning desktop in to a first-class citizen. And
since s in the screen-corner, 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 Fs law.
5. The green-thingy in top-left corner is the Kmenu/Ali. And before you talk
of copying W 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. course,
the color-scheme could be changed.
By far, the two most controversial suggestions are the universal menubar and
the universal -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. Is 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. Is 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. 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. Is 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 .
What about #2? Well, things change. KDE t tie itself to the past, nor can
it tie itself to other system (that is, KDE 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 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 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 s menu. That is, when
the user clicks on the desktop, the menubar would show s related to the
desktop. And there would be a menu for configuring the system. You might say
that 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: Im not talking about making it hard to configure
the system!).
And the universal menubar? of the complaints I have heard is that s
difficult to know which 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 S X). That is, First menu in
Konqueror would be called K. 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 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
kde-usability (AT) kde (DOT) org

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.

Janne wrote:

>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 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
>. 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, s too complicated.
>2. Remember Fs law! in the screen-borders are easier to access.
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:
>
>
>
>(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. 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 S-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? Is the close
>-button. What is it doing in there you ask? Is 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 LT 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 D-button. This provides a
>quick access to the desktop, turning desktop in to a first-class citizen. And
>since s in the screen-corner, 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 Fs law.
>
>5. The green-thingy in top-left corner is the Kmenu/Ali. And before you talk
>of copying W 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. course,
>the color-scheme could be changed.
>
>By far, the two most controversial suggestions are the universal menubar and
>the universal -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. Is 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. Is 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. 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. Is 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 .
>
>What about #2? Well, things change. KDE t tie itself to the past, nor can
>it tie itself to other system (that is, KDE 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 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 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 s menu. That is, when
>the user clicks on the desktop, the menubar would show s related to the
>desktop. And there would be a menu for configuring the system. You might say
>that 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: Im not talking about making it hard to configure
>the system!).
>
>And the universal menubar? of the complaints I have heard is that s
>difficult to know which 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 S X). That is, First menu in
>Konqueror would be called K. 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 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
>kde-usability (AT) kde (DOT) org
>
>

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Le Lundi 8 A 2005 12:14, James a *:
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 S 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.

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

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Monday 08 August 2005 12:57, Joseph Garvin wrote:
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 Fs 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 S X, but now I have grown to appreciate it.

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

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Sunday 07 August 2005 23:17, James wrote:
Hi,

Your ideas sound interesting. Here are a few comments:

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

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

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 MS has the ability to
close the window, because their windowmanagement sucks and Dock is really bad
at handling running apps ;)?

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

* Would the four buttons be hard coded to be attached to the corners of the
screen? 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.

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Sunday 07 August 2005 23:44, Henrique Pinto wrote:
Em Sun 07 Aug 2005 14:52, Janne escreveu:
1. Mac S-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.

kde-usability mailing list
kde-usability (AT) kde (DOT) org

2005/8/8, Aaron J. Seigo <aseigo (AT) kde (DOT) org>:
- 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

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Aaron J. Seigo wrote:

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

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

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


>
>>(b) is confusing (even experts
>>occasionally click the wrong menu bar by accident),
>
>>
>
>this actually happens more often on MS than on Windows/KDE since with
>"menubar in window" the context is obvious.

It does? Where's the data? ;)

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

kde-usability mailing list
kde-usability (AT) kde (DOT) org

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

kde-usability mailing list
kde-usability (AT) kde (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)

NS+1GURPCKmZJhbfkpk=
=Jlr0
PGP SIGNATURE

Am Dienstag, 9. August 2005 01:42, schrieb Aaron J. Seigo:
Monday 08 August 2005 03:17, Joseph Garvin wrote:
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

kde-usability mailing list
kde-usability (AT) kde (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)

jIb9ia/7NZ1gQ+Nrpv+KEAU=
=X
PGP SIGNATURE

Aaron J. Seigo wrote:
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 :)

kde-usability mailing list
kde-usability (AT) kde (DOT) org

PGP SIGNED MESSAGE
Hash: SHA1

Tuesday 9 August 2005 02:32, Lauri Watts wrote:
Tuesday 09 August 2005 01.34, Aaron J. Seigo wrote:
i configure my window decos that way as well. close == move mouse
left, anything else == move mouse right.

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
PGP SIGNATURE
Version: GnuPG v1.2.5 (GNU/Linux)

lPwJzQJz+chZDdCFrCHLbJU=
=kZVK
PGP SIGNATURE

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Am Dienstag, 9. August 2005 03:29, schrieb Aaron J. Seigo:
Monday 08 August 2005 06:18, Friedrich W. H. Kossebau wrote:
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.

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

Friedrich

kde-usability mailing list
kde-usability (AT) kde (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)

HnHeKI9FZsYu5z+4cyMdK0s=
=oHo4
PGP SIGNATURE

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

Monday 08 August 2005 23:12, Aaron J. Seigo wrote:
Monday 08 August 2005 12:08, Janne wrote:
Monday 08 August 2005 12:57, Joseph Garvin wrote:
- 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.

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

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 S X in this aspect (although it doesn't seem to have
universal menubar, but the actual windows resemble S X). So, if we are in
the "Follow Vista"-mode, we should remove menubars from windows ;).

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

assuming we're thinking of the same person, he was a graphic designer IIRC
=)

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

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.

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.

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.

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 S X and
KDE with Mac S-style menubar, and I have no problems with it. And from
seeing newbies use S X, they don't seem to have any problems associating the
menubar with the app.

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

Your comparison is not valid. In S 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.

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Tuesday 09 August 2005 20:11, Alan wrote:
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.

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.

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 S X does IM). And second:
the menubar actually says which app it belongs 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.

Is that a valid reason to NT 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?

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.

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Tuesday 09 August 2005 00:24, Martijn Klingens wrote:
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

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.

kde-usability mailing list
kde-usability (AT) kde (DOT) org

Alle 19:11, 09 agosto 2005, Alan ha scritto:
Sunday 07 August 2005 18:52, Janne wrote:
Without further talking, behold the desktop of KDE 4.0:

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)
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 MS (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

kde-usability mailing list
kde-usability (AT) kde (DOT) org