Do you ever close unfocused windows?

[hop-frog]

Maybe this sounds like a really stupid question, but this is the explanation for why I asked:

I am sure you understand the advantage of having the file menu fixed at the top of the screen (like a mac) as opposed to having them fixed at the top of each program.

What if I were to extended this concept further so that the actual close and hide buttons were placed in the top of the screen along with this menu bar? One disadvange that I can see is that you have to focus on a window before you can close this.

Would this be a problem for usability? Anyone care to throw around some ideas or constructive criticism?

[AdaHacker]

That's an interesting notion. Frankly, though, I don't see the advantage of it. As you say, putting the close/hide buttons on at the top of the screen would certainly make it more awkward to close a window without using the keyboard. Seeing as pretty much every other interface I've ever seen puts those buttons right on the window, it's bound to cause confusion as well and thus hurt usability.

More importantly, there doesn't seem to be any real benefit to this other than the novelty of it. Perhaps you gain that extra quarter inch of screen space taken up by the window title bar, but that's about it. And even that's not a good thing because then the user has nothing to grab the window with. Sure you could use the borders, but they're pretty small and can be hard to grab. (Ever try to control a trackball to within the two pixels a window border occupies? With your left hand? It's not as easy as you might think.) And if you're going to keep the title bar, why not leave the normal things in it?

This is a cool idea, but I don't see this being worth the problems it would cause.

[hop-frog]

I was thinking that the advantage might be in the easier access of the buttons, but I'm not quite sure. Here is a quote from this (http://www.asktog.com/columns/022DesignedToGiveFitts.html) column on usability:

The other four [prime] pixels are located, on average, as far away from the mouse pointer as you can get. Their distance, however, is more than made up for by their target size, which is infinite in two dimensions. These magic pixels are the four corners of the screen. Throw the mouse in any direction you desire and the odds are overwhelming that if you threw it with enough velocity, it will end up in one of those four corners. This presupposes a properly designed acceleration function for the mouse.

The buttons would be the same size as those on any other window manager, but because they would be in the corners of the screen they would take advantage of these "prime" pixels.

I'm not certain how well this would work though and I am not sure if I should use any of the lower corners of the screen.

Perhaps you gain that extra quarter inch of screen space taken up by the window title bar, but that's about it. And even that's not a good thing because then the user has nothing to grab the window with.

I would keep the titlebar because the window's title is important. Otherwise it could be moved to the side as seen in MicroGUI themes.

[AdaHacker]

Well, I guess that makes sense. I'm still not sure how well it would work, but it makes sense. It would definitley take some getting used to, but it could be doable. I do have a few thoughts for you, though....

First, you definitely want the close/iconify buttons to be bigger than the standard window manager buttons. Most WMs use buttons that are slightly smaller than the title bar. If you're going to move them to a menu at the top of the physical screen, there's no excuse for them to not vertically fill the menu bar.

Second, what do you do with windows that have no menu? For example, many terminal emulators and games don't need a menu. I suppose this isn't a huge problem, but it seems kind of silly to take up the entire top of the screen for two buttons. It wouldn't make that much of a difference from a usability standpoint, but it's not really esthetically pleasing.

Thrid, is an implementation issue. Since this is JustLinux.com, I'm assuming you're thinking of doing something like this under X. I don't know how you think this would be implemented, but to me, it sounds like a toolkit issue, as that's what normally controls the menus. However, in a UNIX environment, the window manager controls window focus. It strikes me that most window managers support some kind of "focus follows mouse" option, which would completely break this. Of course, focus-follows-mouse isn't really conducive to a top-of-screen menu to begin with, but that's a different story. So, to do this in UNIX, you're left in the unenviable position of either hoping that nobody uses focus-follows-mouse (yeah, that'll happen) or finding some way to keep them from using it (easier said than done). Who said configurability is always a good thing?

This might actually work. I think we would probably need to see this in action before we could really tell, though. It would make an interesting experiment.

[hop-frog]

Originally posted by AdaHacker Second, what do you do with windows that have no menu? For example, many terminal emulators and games don't need a menu. I suppose this isn't a huge problem, but it seems kind of silly to take up the entire top of the screen for two buttons. It wouldn't make that much of a difference from a usability standpoint, but it's not really esthetically pleasing.
I see. I checked and KDE has this problem and I'm not sure how Apple handles this. As for the appearance, many Enlightenment themes have a bar running across the top similarly so I know if it is done right it can look good.

Thrid, is an implementation issue. Since this is JustLinux.com, I'm assuming you're thinking of doing something like this under X. I don't know how you think this would be implemented, but to me, it sounds like a toolkit issue, as that's what normally controls the menus.
KDE already can do the Mac-like menu thing for KDE applications (and it doesn't work very well). For experimenting purposes and because I am a newbie programmer I am not going to be modifying KDE. Instead I will be modifying an early version of Aewm. This will be just to see whether the close/hide button idea will work. It would not actually use the file menu thing to begin with, but if it works I might try to make it at least run at the same time as modified version of KDE's Mac-like menu.

However, in a UNIX environment, the window manager controls window focus. It strikes me that most window managers support some kind of "focus follows mouse" option, which would completely break this. Of course, focus-follows-mouse isn't really conducive to a top-of-screen menu to begin with, but that's a different story. So, to do this in UNIX, you're left in the unenviable position of either hoping that nobody uses focus-follows-mouse (yeah, that'll happen) or finding some way to keep them from using it (easier said than done). Who said configurability is always a good thing?
I'll have to take a poll to see how many people use focus-follows-mouse. I've always used click-to-focus.