The Waning of the Overlapping Window Paradigm?

Bingo Foo asks: "The paradigm of movable, overlapping windows on the desktop has been around, and indeed dominant, for a long time. The original motivation for this was to mimic sheets of paper on a desktop. This is a useful metaphor, but may be a bit limiting given the capacity a computer has for automation of the layout and display of "desktop" objects. Lately, I have been pleased to see an increase in 'framing,' 'docking,' 'stacking,' and 'tabbing' being used, starting most conspicuously with frames in the web. More significantly, it has shown up as an application workspace paradigm that improved previously crappy MDI implementations in programs like Visual Studio and KDevelop. In my opinion, the most promising experimental application, even if still immature, is one of the neatest window managers around, ion. Does anyone else see a time when movable, tear-off docking and automated full-time tiling completely take over from the free-floating manually arranged desktops of today?"

Comments

space

[modemboy]

Seems to me overlapping is needed in this day of 17" monitors. As soon as we have excess monitor space these paradigms will take over, but for now I need to be able to hide stuff on my monitor easily.

Re:space

[uchian]

A feature I would like to see is sort of a compromise - the ability to join two windows together and make the line at which they touch act like a splitter, and the two windows together act as a single window.

Unfortunately I never seem to have the time to wade through the code of my favourate window managers to find out if this would be easy to do :-(

Re:space

[modemboy]

So, most current windowed gui's are based on the idea of a desktop, with file folders, documents you shuffle bach and forth, etc. Seems like what people are asking for here are some of the normal office desktop tools, tape, stapler, scissors, pen, etc. So, should there be a gui that has this kanda stuff, a stapler to link/stack documents, tape to bind stuff, scissors to split, pen to annotate. Any other tools that would work like this?

Re:space

[uchian]

XMMS does it already.

That's not quite how I mean. As an example, take Kate, the KDE editor. It has 3 panels - a tree view to the left, and to the top right an editor and below it (bottom right) an xterm.

I would like to be able to, as a user, create this same layout using, say, konqueror, nedit and an xterm. I'd do something to tell the window manager to stick them together, and I would be able to resize the edges, and have it affect all of the windows. And save the configuration so I can start it up again easily.

OK, kate already exists so I don't need to do this, but how about if I wanted an instant messanger attatched to the side of it, an irc client underneath it, and a news ticker underneath that, and I want it all to act as a single window, where I can resize any set of the programs without overlapping?

Hey, go the whole hog and find an easy way to send messages from one of the programs to another and bingo! the user suddenly can create his very own programs out of small components - the gui equivalent of the command line philosophy perhaps?

Re:space

[mini me]

Interesting, now all you need after that is the ability to draw pipes between the windows, say drag the output of your xterm to your IM chat window and so it will send the output of your xterm to whomever you want via your IM software. The xterm might be a bad example, but you get the idea.

Finally.....

[moniker_21]

"...you should hardly ever have to touch the mouse again to move between windows.
My friends always laugh at me when I say that I hate using the mouse because when I'm really tooling along on my computer reaching for the mouse slows me down....I'm glad someone else finally understands this!

Re:Finally.....

[blair1q]

/. bt, dt:

Interesting Keyboard/Mouse Combo

Re:Finally.....

[Doktor Memory]

My friends always laugh at me when I say that I hate using the mouse because when I'm really tooling along on my computer reaching for the mouse slows me down....I'm glad someone else finally understands this!

Your friends are laughing at you because, although using the keyboard "feels" faster, nonetheless you are wrong.

Re:Finally.....

[dollargonzo]

i dont know about you, but for me it sure is faster to type this message than going to a menu to select each letter. If yuo are saying that it REALLY takes me 2 seconds to type each letter, then this message would be done in QUITE a while, when in fact it took me about 40 seconds to write. (sorry, 42,43)....the point being that in the beginning it is ALWAYS faster to reach for the mouse than press the keycodes, but after a while, when ppl get used to the key codes, they become a lot faster, because yuo dont need ANY hand-eye coordination. all yuo need is the memory of where the keys are. When most ppl begin to learn to type, it takes them a while, but when those same users learn to touch type, typing, say 100 words a minute is much faster than going to a menu to select every letter. same with command sequences. i have gotten REALLY used to emacs command sequences, and switching buffers, for example, as outlined in another comment is pretty DAMNED fast.

Re:Finally.....

[Doktor Memory]

Basically what you (and most of the other responders here) are saying here is, "My subjective recollection trumps their scientific measurement, damnit!"

Sorry, but the world doesn't work like that.

Nobody's saying that using the meta-key shortcuts doesn't feel faster than mousing to a menu. Heck, Tog explicitly acknowledges that it feels faster to the user. All they're saying is that when you actually sit down with a stopwatch in a controlled environment it just isn't so.

Don't believe him? Don't believe me? The joy of the scientific method is that you don't have to -- just get yourself a copy of the original study, recruit a bunch of your friends, buy yourself a stopwatch and prove it to yourself. You'll probably be very surprised by the results.

Re:Finally.....

[Doktor Memory]

Noone thinks of Ctrl+C when they need to copy stuff, they just put their pinky on the Control key, and press the key which is about 7 cm to the right and 2 cm above.

Sorry, but the guys who actually sit around with stopwatches (and, occasionally, EEGs and CAT scanners) to quantify this sort of thing disagree with you.

Think of muscle memory as the instruction prefetch cache on a CPU. Yes, if you "hit" the cache, you'll execute the instruction faster than if you didn't. But there's still a delay involved, and (important bit here) some caching strategies are more efficient than others.

Keyboard shortcuts are a lot more intuitive to muscle memory than mouseitems can ever get.

The research that Tog cites proves the exact opposite of this claim. Where is the you research supporting it?

Re:Finally.....

[Dixie_Flatline]

I don't buy it. For one thing, his comments are too wide-sweeping to be taken seriously.

For example, consider a user wanting to close a window. The user has two choices. She can type Ctrl-W and close it, or take her hands off of the keyboard (which she was using) and go for the little 'x' in the corner to close the window.

If we apply Fitts' law, we can come up with some numbers for it.

Fitts' law: a + b log2 (D / S + 1)
a and b are experimental values, but we can use 50 and 150 for them, respectively. (I'm getting these numbers from 'The Humane Interface' by Jef Raskin. No, I'm not pulling them out of my ass.)

The 'x' in the corner of my window is about 5mm a side. By my rough calculations, from the middle of my window (assuming the window takes up most of the screen, as my IE window currently does), I have to travel about 15cm to the 'x'. That's 150mm. So, S = 5mm, D = 150mm.

Our equation is then:

50 + 150 log2 ( 150 / 5 + 1) = 793 ms

It's generally agreed that it takes about 0.25 seconds to even get moving once you have your hand on the mouse. The propagation time of your hand to the mouse is probably another 0.5s at least. So, you're looking at about 1.5s to get to where you want.

By comparison, it takes about 0.2s to tap a key on the keyboard. If we assume that the user taps first one key, then another, we have a total time of 0.4s. (I'm also getting these numbers from 'The Humane Interface'.) Mental preparation time for the actual action is about 1.35s, but you have to mentally prepare for an action regardless of whether it is a typing action, or a mousing action. We can ignore it to simplify things. Since the 'ctrl' key can sometimes be odd to reach, we'll even ramp it's time to type up to 0.75ms. We're still looking at a total time of 0.95ms.

That was just to close a window. Selecting menu items (once you've successfully moused to the menu) is even longer. Time saving devices like the Apple (NeXT) dock speed some things up considerably.

Fitts' law explains why it's easier to use the Mac menu system, where the items are up against a barrier (the edge of the screen). It ends up making a larger effective target. This is also why the dock is effective.

Long and the short of it: an expert user is probably better off sticking to the keyboard. While I appreciate the research that Apple does (I honestly believe they know quite a lot more about UIs than basically everybody), this guy's assessment that it takes a full 2 seconds to do anything with the keyboard is pretty far out there, and I don't see any references to papers or any published results.

I often find that it's slower to use the keyboard, but it saves me the trouble of moving my hand on and off the mouse, which amounts to a comfort thing at the end of the day.

Re:Finally.....

[forii]

Think of muscle memory as the instruction prefetch cache on a CPU. Yes, if you "hit" the cache, you'll execute the instruction faster than if you didn't. But there's still a delay involved, and (important bit here) some caching strategies are more efficient than others.

Okay, I agree with you here. But let's just think about this. The difference is that you can create muscle-memory for specific keys (you've probably done so for typing regular text, for instance). You are able to do this because you know where every key is on the board. Where's the "ctrl" key? You already know exactly where it is. Where's the 'v' key? You don't even *think* about it, you know know how to hit it, and you've easily pasted something.

Now let's take the other method. Where's the "paste" command? You know, automatically, that it is in the "Edit" menu. You reach over to grab the mouse. Where is it? While limited by the size of the mousepad, it can be in any number of places. But you grab it. Now, where is the Edit menu? Is your window in the normal place in the screen? Is the cursor always in the same spot? Probably not, so now you have to drag the cursor from its (normally non-optimal) location over to the Edit menu that can be anywhere on your display, and and only THEN select "Paste".

The difference is that there are so many variables in using the mouse, that it is very difficult to develop a usable muscle memory. Don't believe me? Wait until you go to someone's computer where the mouse has a different acceleration value, or a different mouse-click speed, etc. etc. Then your muscle memory disappears. I'm not saying that a keyboard is infallable (I'd be lost on a Dvorak keyboard, for instance), but the changes needed for my muscle memory to be hindered are much greater.

Long Story Short: A keyboard is simpler, with less variables, which makes for a easier time learning to do tasks quickly.

The research that Tog cites proves the exact opposite of this claim. Where is the you research supporting it?

Um, I didn't see ANY research cited in Tog's article. I just saw him claim that the research shows it. Where's the reference? Actually, I'll just claim that the research proves that Tog is wrong, and provide the same amount of references that he does, right here:

Re:Finally.....

[lukel]

Your friends are laughing at you because, although using the keyboard "feels" faster, nonetheless you are wrong.

Isn't the extent to which it interrupts your train of thought more important than speed? I would speculate that the reason the keyboard feels faster is that it interrupts your train of thought less.

Re:Finally.....

[DGolden]

But is that with the ctrl key in its stupid PC place, or where it should be (where the Caps Lock key is on "modern" keyboards).

Personally, I use ctrl:swapcaps in my XF86Config, so that the Caps Lock key becomes Ctrl. I'm pretty certain (at least, my little brother with a stopwatch timing 20 trials certain, then me timing him) that it takes me/him more time to reach the mouse than press a ctrl-key combo. Even reaching up to press an F-key is faster than going for the mouse - I've always been a fan of an always-visible panel on the screen, with a block of function names + corresponding keys.

That said, I've been investigating a "fast" (tens of words per minute) way to "type" with mice/trackballs - I'll probably do a public release in a few weeks, depending on (a) time commitments (b)whether I can remember how to code in anything other than the Java which has so rotted my brain, and most importantly (c) whether it really is fast. :-)

Re:Finally.....

[Doktor Memory]

2. Muscle memory doesn't work with the mouse

What a weird assertion to make. Why on earth would you believe such a thing? Unless you're moving your mouse via telekinesis, your fine motor control is very much involved in the process.

Re:Finally.....

[rho]

Did you read the linked articles?

It's not simply the physical motion that affects the speed: it is the mental interruption where the brain has to stop it's current task, retrieve the key-commands, then return to the previous mental task that causes the users to slow down.

I've measured my programming speed between Emacs and BBEdit: it's very close, but BBEdit comes out on top (for most things -- there are some tasks that Emacs is so obviously superior it's not even funny). But please don't hold up Emacs command keys as a good example -- Emacs without a mouse is horribly, horribly slow.

But believe what you want.

Re:Finally.....

[Doktor Memory]

For example, consider a user wanting to close a window. The user has two choices. She can type Ctrl-W and close it, or take her hands off of the keyboard (which she was using) and go for the little 'x' in the corner to close the window.

Aha, now we're descending from the general case to a specific case. And in this specific case, you're quite right: the "window-close" widget in just about every WIMP interface out there takes forever and a day (relatively speaking) to get a lock on. The metaphor has stuck with us primarily because nobody's thought of a better method yet.

That was just to close a window. Selecting menu items (once you've successfully moused to the menu) is even longer.

That depends on one huge-arse variable: where the menus are.

In the Windows world (and that of its imitators, Gnome and KDE), the menus are placed in the top of the floating window. A terrible mistake, and it makes them dog-slow to use for all of the reasons that you mention and a few more as well -- since the location of the menu onscreen isn't predictable, you can't even use muscle memory to make up for the other defects in the design.

Put the menus in a predictable location (e.g. the top of the screen, with frequently-used menus closer to the corners) and the situation changes dramatically. Deeply nested hierarchical menus reduce the effect a bit, but that's the visual equivilant of adding more modifier keys: hopefully you keep the must-used actions closest to the top of the "tree".

Re:Finally.....

[mj6798]

Muscle memory (for the most part) doesn't work with current interfaces because the mouse performs relative positioning. Even if you put the menu bar along a screen edge, as in the Macintosh interface, you still need visual feedback of the mouse cursor position in order to position the mouse.

There are a few mouse-based interfaces where muscle memory works: the mouse wheel (in a very simple way), multiple mouse buttons, and pie menus. You will notice that the Mac uses none of those, but rather clings to a notion of "simplicity". Simplicity sells machines, but it doesn't make for an efficient user interface once people have used the machine for a few months or years.

Re:Finally.....

[Ian Bicking]

Mental preparation time for the actual action is about 1.35s, but you have to mentally prepare for an action regardless of whether it is a typing action, or a mousing action. We can ignore it to simplify things.

This is where Tog seems to be crack, IMHO. He does take account of the mental preparation for the keystroke, but seems to think that there is no such preparation for the mousestroke -- or that it somehow occurs during the actual movement.

This is simply silly -- deciding what you want to do, and how you need to do it, is a constant for any interface that is at all natural.

Some say that a keyboard interface is not as natural as a mouse interface. But that's silly too -- as though there something natural about moving the mouse around and hitting menus. The visual interface tends to be more self-documenting. But for actions that are taken on a regular basis this isn't important -- actions like closing a window, opening a URL, searching for a string, copy, paste... yada yada yada, there are hundreds of these that we can easily keep in our heads if we use the computer often enough -- which is at least true for everyone here at slashdot, if not for every Mac user.

I think the interface that is best for the novice user is no longer being fair to the average computer user of today, who is not a novice (or at least does not want to be), and who uses their computer a great deal more. It's difficult for people to move from novice to experienced when they aren't naturally inclined to do so -- however, they would benefit from that transition, and they need that more than they need easy interfaces.

The keyboard interface that is analagous to the mouse interface might be what you get with M-x in Emacs, or tab completion on the command line. It's vaguely self-documenting, and not necessarily faster than a mouse-based interface. These are interfaces best served to deal with a very large array of options with which the user is not particularly familiar.

However, I find the keyboard vastly more reliable and general an interface than the mouse for any medium that is not strictly visual -- which is most of what I (and most people) use the computer for. By not visual, that would include language or symbol based... which can be visual too, but I can't think of the right word to distinguish them.

Re:Finally.....

[Ian Bicking]

You can't do that sort of experiment scientifically without committing a great deal of time.

Tog is considering a novice user populace, one who hasn't become accustomed to their tools. But that's not a realistic test -- everyone who uses the computer much will become accustomed to their tools. If they don't use the computer much, then they don't even matter that much, because there isn't that much total time to be saved on the interface.

You want me to take a bunch of people who know Emacs and test their time doing some editing task against their time using a mouse-based editor? I don't need to bother with the experiment to tell you those people will be way, way faster in Emacs. And even if I did the experiment, it wouldn't mean anything, except maybe that people can become much faster at actions with experience.

If I was to take those people and force them to use particular tools for at least three months (if not more) for real tasks, and then test them, then I could say something about the efficiency of the interfaces. Otherwise the experiment means nothing to the average slashdotter who uses their tools extensively. In fact, it says little to the average person who uses a computer extensively -- which is a really large population.

Any experiment that doesn't take account of a human's ability to learn and fully assimilate seemingly nonintuitive actions is flawed. If you are creating an interface for a fire alarm, where a person might use it a few times in their lifetime, then the kinds of experiments Tog is using are appropriate. That ain't how computers are used.

Re:Finally.....

[Ian Bicking]

What it comes down to is that if you spend the majority of your time in a small handful of programs, keyboard interfaces are far faster. If you are a casual/semicasual computer user (read: 95% of users), the mouse is almost always faster.

95% sounds way off to me. Lots of people with no inclination to use computers end up using them 8 hours a day, because that's what their work entails. Just about everyone with an office job is in this position now.

Even cashiers use a computer extensively -- only we forget that's what the cash register is. And I have never seen a cash register with a mouse (though some -- not many -- have touch screens).

Re:Finally.....

[Dixie_Flatline]

I totally agree with you; if you don't have shortcuts memorized, they aren't going to be faster. That may seem like an oversimplification, but there's no arguing with it.

It's sort of like touch-typing. If you don't have the keys memorized, you can look at them, and it'll sort of help...but you're at a disadvantage to anyone that instinctively knows the keys.

It's really second nature to me to use my emacs movement keys. I use them on the bash command line, in emacs, and in practically every UNIX program (ie. netscape, opera, whatever...) I'm so used to them that I'm often trying to use them in windows and other places that don't support them. Thank goodness OSX lets you edit the keybindings for keys! My TextEdit editor is now all I really need to be happy for notes OR code.

That all sort of falls into place with your second paragraph...switching is a pain. This is why standardization on an interface is actually good. Forget the arguments about being able to choose what everything looks like/acts like. By standardizing, at least a little, you never feel out of place.

Of course, you could argue that the command line is all the standardization you'd ever need...

Re:Finally.....

[epsalon]

Until you move over to the Windows world, where it's Alt-F4. Just as fast, but there's that little internal lookup function, where you have to think "wait, I'm in a MS program, it's not Ctrl-W, it's Alt-F4". Now, once that info's availible, then it's easy to close the other windows (Alt-Tab, Alt-F4, repeat), but the first 500 times you do it, you have to remember what you are doing. And then, when you switch to another system, you have to remember what the command is there. I'd be appalled if there was a little counter that counted how much time I wasted typing "ls" at an MS-DOS command prompt, or DIR at a bash prompt.

You can solve this by using KDE, so Alt-F4 still works, and aliasing dir to ls and vice versa on both machines.
Also, you can trivially use only one desktop OS....

Re:Finally.....

[Dixie_Flatline]

>That depends on one huge-arse variable: where the menus are.

Absolutely. Like I hinted at, Fitts' law will tell you that going to a menu like the Macintosh ones is fast and easy. However, a memorized hot-key will still be faster depending on where the menu item is in the menu.

Studies show that the 2rd or 3rd item is usually the fastest to get to. If your menu item is nested, you also have to take into account the possibility of overshoot, etc.

There is certainly a balance somewhere in there. I like my hot-keys, but I can't deny the usefulness of menu items. In the UNIX world, however, where everything is text-driven (mostly) anyway, it's usually faster to do some memorization.

In the OSX world (where I'm happily typing this from, I might add), the GUI actually extends the interface experience. I'm much more willing to use the mouse now than I was before. In Windows, I feel crippled. I haven't put any time into memorizing the interface, so I'm constantly using the mouse to get things done, and I feel like the productivity is draining out of me when I do it....

Re:Finally.....

[scrytch]

Fitts' law explains why it's easier to use the Mac menu system, where the items are up against a barrier (the edge of the screen). It ends up making a larger effective target. This is also why the dock is effective.

The reason they put it there was because macs had a screen not much bigger than a GameBoy, and a menubar in the application window would eat valuable real estate.

One user interface issue I ran into all the time with macs was "having the wrong app in the foreground" when selecting a menu item. I didn't do this, it was users I helped. I don't care how much math you draw on the blackboard, this particular training issue was proof enough for me that you don't get something for nothing.

What kills me is the taskbar in windows. They could have had it extend all the way to the bottom, but there's this gutter of dead space between the buttons and the bottom of the screen. I recently used windows XP, which has a much fancier taskbar, but forgot to test whether that gutter is still there.

I think Fallout 2 may have actually gotten it right -- you right-click items for a popup menu, it pops up a menu of large icons and moving the mouse up and down constrains the pointer to the menu. Anyway, I end up teaching people to tap the alt key to toggle to the menu in Windows apps. Fitt's law is about aim, why aim when you don't have to?

Re:Finally.....

[Dixie_Flatline]

I can believe that they put the menu bar up there for reasons other than good design. However, the fact remains that it has a good side-effect, or it IS good design, or whatever.

When I was first learning to use my Mac, I also always had the wrong app in the foreground. It's just something you have to get used to. That's in contrast to Fitts' law, which can't be defeated over time. It has less to do with the user, and more to do with our instruments and interface. Without changing the interface, you can't change the result of the equation.

The Taskbar in windows is something that I often cite when I complain about the Windows interface. It's bad, but so close to being good.

And finally, I agree about not aiming if you don't have to. That's the whole point of keyboard accelerators. No aiming, no pointing, no fuss, no muss.

Re:Finally.....

[Error27]

"I disagree."

Me too. It is silly to say that short cut keys don't speed things up. The articles he cites are from 1989 and 1992. Things have changed since then.

For example, I think now Tog would encourage programers to use standard short cut keys instead of saying that people should be able to configure them. And things like having a menu bar have become standard practices instead of being a new idea.

"Alt-tab, for example, is much faster than reaching for the mouse and moving it to the window and clicking, although a single key to switch applications would be nice."

One of the cool things about Enlightenment is that you can configure your windows to "lower" when you right click on the title bar. I configure almost all my windows to take up the full screen. This way to switch between windows instead of typing alt-tab I just throw my mouse to the top of the screen and right click followed by a left click.

With windows or a Mac you have to move the window around and resize things because they don't have this "lower" feature.

Alt-tab is only good if you already have your hands on the keyboard. Most of the time I use my computer for reading and not for typing so this isn't true.

I wish more people would realize the value of a "lower window" on right click feature so that I wouldn't have to hack themes and add it in. It's really important if you have lots of windows open at a time. Right now I have 3 full screen windows and 6 minimized windows as well as licq, xmms and gkrellm open. To cycle through the whole list with alt-tab takes a long time.

Re:Finally.....

[Tachys]

I looked for the Gutter under windows, and it is gone. It looks like it is there but if you press your mouse pointer against the corner you can still hit the button. You can also ram your mouse pointer on the bottom-left corner to hit the start menu.

Re:Finally.....

[crucini]

I respect Tog...

Why? These cited pages are the first writing of Tog I have read, and there are no words to convey the lack of respect I feel for him. His argument consists of repeated appeals to an alleged study to which he provides neither a link nor a citation. His claim of a two second delay to choose a control key is so far from my experience (including observation of others, so put away the amnesia theory) that I regard him as not only wrong, but dishonest. To say that I am skeptical of his "study" is like saying that I am skeptical of Elvis's repeated visits to the land of the living.

Re:Finally.....

[crucini]

It's not simply the physical motion that affects the speed: it is the mental interruption where the brain has to stop it's current task, retrieve the key-commands, then return to the previous mental task that causes the users to slow down.

Why does this not apply to the mouse? You claim that it takes me an appreciable amount of time to remember ":wq". Why would it not take me an appreciable amount of time to remember "file->exit"?

I think the reason I am irritated by this nonsensical theory is that I find vi a very good fit to the way I think about editing a document. You speak of "mental interruption" but I experience more mental interruption in dealing with a GUI.

Re:Finally.....

[Karellen]

Yeah, like the specifics he used were any use.

The one actual study he did that he cited was so contrived to be untrue. With a paragraph, replace all occurrences of 'e' with '|'

Keyboarders, 99 secs
Mousers, 50-odd secs

Huh? I'm sorry, but

:%s/e/|/g

is a hell of a lot quicker than the method he said mouse users were forced to use. And I'm sure emacs users have a Ctrl-Shift-Meta- key combination to do the same sort of thing.

OK, that keyboard example does assume that paragraph is the only one in the whole document that you're editing. So, to make it slightly more selective

:%s/e/|/gc

Will ask you to replace each occurrence of 'e' with '|'.

Alternatively, if you don't want to check any lines above where you currently are

:.,$s/e/|/gc

Will check from the current line to the end of the document, and you can cancel the search/replace as soon as you've reached the end of the bit you need to change.

All I can say is that mousing is probably faster than keyboarding _if_ you're using an application that has a totally shitty brain-dead keyboard interface that doesn't actually allow you to use your keyboard effectively. And if you're playing with a stacked deck like that, don't be surprised if you get the results you want.

Give a mouser and a keyboarder a _task_ to complete, and let them use their own choice of tools (e.g. vi for text editing) to accomplish it.

K.

Re:Finally.....

[ChaosDiscord]

Tog is wrong.

Or more specifically, Tog is overgeneralizing. His research quite reasonably focuses on casual users of software. This does't make sense for people who make heavy use of a particular piece software. Moving your hand off the keyboard when doing heavy duty text data entry is a huge speed hit. It's a big speed hit for transcription, for entering order information, for typing source code, for writing a novel.

A mouse is a great and important invention. But it's not a silver bullet. Tog has made the mistake of generalizing his fairly specific research into faulty universal solutions. When I saw Tog's article on how traffic engineers are stealing his life I realized that his ego was completely out of control. The man has grown too comfortable living on his prior research. He's become closed minded, a mistake in a field that is still very young.

Mice are great. Going back to the keyboard only days is a hideous mistake. But keyboard shortcuts can provide a very real speed boost for frequent operations.

Re:Finally.....

[Error27]

Not if your hands are already on the mouse...

Re:Finally.....

[Karellen]

You want me to take a bunch of people who know Emacs and test their time doing some editing task against their time using a mouse-based editor?

Even that's a little unfair.

The most accurate test of all would be to set up a series of common (and not so common) _goals_ to be completed (such as that 'replace all occurrences of 'e' with '|' in a paragraph test), and then let keyboarders and mousers attempt to solve them with their own choice of tools, and see who's faster.

Bet the keyboarding vi or emacs users thrash the bollocks off of the mousers.

Re:Finally.....

[rho]

I ask again: did you read the fucking articles?

Tog addresses this very concept: you think you're faster, but they found that people aren't faster with keyboard shortcuts. That was the study, that was the finding. End of fucking story.

People lie, the stopwatch doesn't. Dammit, when did ignorance become a point of view?

Re:Finally.....

[crucini]

You certainly have a lot of confidence in the validity of this study. Would you mind providing a link to it? Not to Tog's paraphrase, but to the study itself.

The fact that a vendor came up with a study showing their approach to be superior is not surprising. Have you seen the Microsoft study showing that desktop Unix has a higher TCO than desktop Windows? It's pretty convincing. Until you read it. Then you realize that they are assuming every Unix user has to have a Windows PC as well.

End of fucking story.

Far from it. Even if the alleged study were publicly available, methodologically sound, peer-reviewed, and conducted by experienced scientists, the story would not be over. Since the study so far meets none of these criteria, I'm not sure the story has even begun.

Maybe I'm just stubborn

[pete-classic]

but this falls into the "I want the computer doing what I say, not what it thinks I want." category.

I mean, it is a personal preference, but I don't want a system that refuses to arrange windows the way I want because "it knows what's best" for me.

So, my answer to your question is "no."

-Peter

Re:Maybe I'm just stubborn

[elmegil]

How about when I want two windows to be of such a size that they take up more than 50% of my window space? I *don't* want magically expanding and contracting windows, and I *do* want the window I'm currently doing something in to be of sufficient size to be useful, so there are times when overlapping is all there is for it.

A good example: I do computer support, and sometimes I'm looking at the logs for two computers to compare and contrast events between them. I need a certain amount of the log to be present, I need enough width that line wraps don't hose the legibility of the log, and I need to switch between the two windows easily to compare them. If they overlap, a front button (handy on my Sparc workstation) lets me switch between them without mousing, and away I go.

If I had to make the two windows fit on screen at the same time, it would be an enormous pain.

It's all about giving me the freedom to work how I work best; if any window manager refuses to allow me to use the paradigm I know and love, I won't fscking use it.

Re:Maybe I'm just stubborn

[Znork]

You're wrong. There's nothing more annoying than applications that mess up window overlap. I use it all the time every day, which I suspect anyone who has multiple threads of attention or work going on at any point in time.

A computer desktop without window overlap is like a 50 cm square desk. Sure, you could use it, but the overhead of picking reference litterature out of the shelf, reading it, putting it back, going back to writing what you were writing, etc would make it annoying in the extreme. There's a reason why desks usually are not made like that.

Yes, it would look tidy. It would also be a serious PITA for people who actually have work to do which doesnt just involve our heads and a single paper.

Re:Maybe I'm just stubborn

[nickjennings]

Man, I think alot of people posting here have no idea what Ion is really like. You *can* overlap windows in Ion. You just design the frameset for them. For example:

I have a left frame that is the height of two xterms stacked, this is god for programming, on the right, I have two seperate frames each the size of an xterm (one long frame on left, two regular sized frames on right).

in each of these frames I can have as many xterms as I want (or any other type of program). To move between frames, I use Alt-, to cycle through the xterms in that frame I use Alt-tab.

On the bottom, I have a very short frame that is as wide as the entire screen, this is great for log files, and I can easily switch between them.

Re:Maybe I'm just stubborn

[DGolden]

A computer desktop without window overlap is like a 50 cm square desk.

Well, why not make the screen like a window onto an infinite desktop, that smooth scrolls when the mouse goes to the borders?

That way, the windows don't have to overlap, and they can take up as much space as you want...

It might be good to stop the scrolling when you reach "empty space", so you don't get lost, but otherise, I'd say that'd be quite a workable plan - particularly if combined with a little pinned-to-screen desktop-in-miniature that you can click on to shortcut jump to a particular window...

Re:Maybe I'm just stubborn

[DunbarTheInept]

I used to use fvwm2 that way - it had an option to allow things to work like that (mostly - the desktop was not infinitely large, but you could scroll the viewport over your desktops.) But it had some practical problems that I'm not sure how to fix:

1. - Speed vs memory: Either it's slow, or a memory hog (but not both at once). Either you allocate a virtual framebuffer in memory that is huge enough to store the entire pannable desktop space, which can be absurdly large, or you 'forget' all data drawn outside the current viewport, but if you do that, then you have to issue massive redraw requests to the apps every time you scroll the viewport a few more pixels, and that's incredibly slow.
2. - The tendency to forget where your mouse is on the screen is normally not a big deal. But it gets really annoying when wiggling it around (to try to see it) ends up panning the viewport because the mouse was near the edge of the screen.

Re:Maybe I'm just stubborn

[elmegil]

[overlapping windows] are in reality very ineficient.

It just takes a different approach

Ion is the best tool I've ever used for doing this

These sounds just like the arguments for why I should give up my archaic (but very well understood by me) vi editor and use that other one (you know, Eight Megs And Constantly Swapping?). By all means if you work better with Ion, great. But as far as I'm concerned, you can have my overlapping windows when you pry them from my cold dead hands. And I don't mean completely obscuring overlapping I mean partially overlapping.

Re:Maybe I'm just stubborn

[pete-classic]

Well, that's why they make vanilla and chocolate.

As I said, it is a personal preference. The actual question at had was "Does anyone else see a time when movable, tear-off docking and automated full-time tiling completely take over from the free-floating manually arranged desktops of today?" I don't think that I am unique in my preference for overlapping windows, so I don't think that they are going to go away.

Now, I'm not saying that your response or opinion is invalid, but why would you post what you did in response to someone who likes overlapping windows?

In other words, you seem to think that the fact that I like them is not a valid point of view so "we are going to take it away."

Do you really believe that I shouldn't have this choice?

The more I read your post the more trouble I have believing it. The "no" at the beginning seems to say "No, your reaction to this isn't valid. Your tastes are wrong."

That blows my mind. I mean, if someone asked slashdot "With all the cool new flavors of Doritos, does cool ranch have a future?" and I replied, "Yes, it does, because I (and people like me) like cool ranch. And you replied "With the advent of eXtreme Doritos there is no reason you should ever eat cool ranch." That's horseshit. Again, to be clear, I don't give a shit if you overlap your windows, or eat cool ranch doritos. The idea that "we" (whoever that is) should take that option away because you don't happen to see a need for it is horseshit too.

Now I'm hungry, luckilly I have some vanilla Blue Bell in the freezer!

-Peter

Re:Maybe I'm just stubborn

[nickjennings]

These sounds just like the arguments for why I should give up my archaic (but very well understood by me) vi editor and use that other one (you know, Eight Megs And Constantly Swapping?).

Actually, that'd be the other way around (switching to vi, from that other... well, you know).

I see your point, and I'm not trying to get people to switch if they don't want to. I'm merely trying to clear up some of the confusion about how Ion handles frames and tabs. (I know it was a little confusing to me, untill I started to play around with it).

To each his own.

Re:Maybe I'm just stubborn

[Paul Komarek]

So many answers in this thread talk about wanting overlapping windows. I'd like to point out that the utility of overlapping windows comes partially from "focus-follows-mouse" behavior (without "autoraise"). You can look at both logs at once, while scrolling through both without changing which is in front.

If you don't have focus-follows-mouse, the bottom window is less useful because it is static.

-Paul Komarek

Re:Maybe I'm just stubborn

[DGolden]

Well, the speed vs memory thing is not insurmountable. The data-forgetting apporach would probably work reasonably well on modern systems. If you do it the with the "2D platformer scrolling" method, then it should be fast enough ('cmon , if it was fast enough on my Amiga years ago, a 1GHz PeeCee should be able to cope...):
Basically,

.........
...bbb...
...bAb...
...bbb...
.........

A- tiled screen
b- tiled virtual framebuffer extent
.- "forgotten"+ regenerated on-demand.
As the screen scrolls, part of the b region becomes A, some of the b region becomes . , and some of the . region becomes b.

This is how many 2D games have scrolled since time immemorial - sometimes b was a border size smaller than an entire screen (usually 8,16, or 32 pixels wide). Making each b the size of an entire screen would probably be worthwhile in this day and age.

The forgetting where the mouse is thing could be annoying, but you could give the desktop edges a bit of resistance, so you have to push against them for a bit before they start moving.

Re:Maybe I'm just stubborn

[pete-classic]

I'm not sure you really understood my post. First, I clearly stated that I don't understand who "we" is.

I think everything you said is fine. I think it is a cool experiment myself.

But the question at hand was are overlapping window window managers going to go way. I think the answer is clearly no.

I'm not saying that it shouldn't. I'm saying that it is not. I don't think I said anything about any conspericy to take the feature away. What I took issue with is that Fellgus really seemed to be saying that the option for overlapping windows shouldn't exist, and that my tastes in the matter are wrong.

I don't see how someones tastes can be wrong.

So, no conspiracy, no melodrama, I just don't like being told that I am wrong to like something aesthetic.

-Peter

Re:Maybe I'm just stubborn

[Paul Komarek]

In case you aren't aware of it, window managers supporting focus-follows-mouse typically support "sloppy-focus", a.k.a. "enter-only". This is like focus-follows-mouse, but allows you to move the mouse cursor out of the focused window without the window losing focus -- as long as you don't move the mouse to a new window!

-Paul Komarek

Re:Maybe I'm just stubborn

[Paul Komarek]

Well, with 9 virtual desktops I usually have at least a little room between windows. ;-) Also, the "click-to-focus" modes I've seen usually focus for a click anywhere in the window. For X copy-n-paste, this gives focus to the window you're copying from.

In the end, of course, it's a personal thing. I started with click-to-focus in Windows 3.0, but once I found focus-follows-mouse I never went back.

-Paul Komarek

Re:Maybe I'm just stubborn

[Lars Arvestad]

I thought this was they way to go and was very excited to find fvwm2 (as DunbarTheInept above) support this feature. However, using it was quite a different issue. I found myself throwing the mouse left and right to get the screen to center where I wanted it. I was so used to rely on the display borders to act as mouse stoppers, that whenever I moved focus to another window, I would also scroll the desktop simply because I always hit the screen edges with the mouse.

This style of desktop also had, for me, the unfortunate side effect of distributing the windows over a too large estate. This meant that when I suddenly wanted to windows close to each other, it was always hard to setup because they were far away from each other on the virtual desktop.

I gave the whole thing up.

OS X

[Have Blue]

Once again, Apple is ahead of the curve... Look at their latest applications: iTunes, Disk Utility, System Preferences, iMovie, Final Cut Pro. They either use a single window for nearly all functionality (only bringing up new ones for things like Open and Preferences) or they take over the entire screen, a throwback to computing "modes" that the Mac was developed to avoid in the first place.

Re:OS X

[pete-classic]

So Apple is "ahead of the curve" by being the first to abandon the technique that they developed the Mac specifically for?

I'm I the only one who thinks this sounds like crazy talk?

-Peter

alpha channel...

[Anonymous Coward]

would be nice to have transparent windows that you could see thru with an easy way of increasing transparency and opacity as required.

Re:alpha channel...

[griffjon]

This actually available in OSX (duh) and in Win2k (and XP, I presume). For 2k (and prolly XP) you have to buy an addon called WindowFX that does all sort of crazy UI things, but the best reason is to be able to set transparencies. Also, virtual desktops (to allow for multiple, full-screen apps to run parallel would be great to see worked into the mainstream (I hear XP has an implementation of this, and, of course, Linux WMs have done this for ages).

I'd love to see more intelligent auto-arrangement of windows, as long as I could specify what intelligent meant and override it.
The best possible improvement to UI would be more features available to reduce reliance on the mouse for basic computing needs, and more education about these. Everyone--even my dad--should know alt-tab switches windows, and ctrl-tab switches focus within an app (sometimes).

Transparency of course reduces the number of window switches you have to make if you can keep an eye on one window while computing above it, and helps that way.

Re:alpha channel...

[Osty]

This actually available in OSX (duh) and in Win2k (and XP, I presume). For 2k (and prolly XP) you have to buy an addon called WindowFX that does all sort of crazy UI things, but the best reason is to be able to set transparencies. Also, virtual desktops (to allow for multiple, full-screen apps to run parallel would be great to see worked into the mainstream (I hear XP has an implementation of this, and, of course, Linux WMs have done this for ages).

There's no need to buy anything. There are a number of freeware and shareware apps out there that will manipulate alpha blending in 2K/XP, mainly due to the fact that it's pretty damned easy to do programmatically. Also, alongside the more generic, modify-every-window type of apps, there are more specifically-targetted applications of alpha blending. For instance, there's <shameless-pimpage>Lucidamp for Winamp 2.x (I'll be working on a Winamp3 version soon that will hopefully be cross-platform, leveraging XFree86 4's new XRender extensions eventually) and my hack of the PuTTY win32 ssh client.<shameless-pimpage>

Also, if you're interested in adding alpha blending support to your win32 applications (called "Layered Windows" in win32 parlance), you can check out this MSDN page. Layered windows also go well with XP Visual Styles, so if you write win32 code, make sure you leverage side-by-side Common Controls to keep everybody happy.

Re:alpha channel...

[Score Whore]

Transparent (really transparent) terminals in OS X are quite nice.

No shit brother. I like seeing what's behind my monitor without having to lean to one side or stand up...

Re:alpha channel...

[DGolden]

Personally, I use the key labelled "caps Lock" as my Ctrl key, 'cos then ctrl-key combos are fast+easy to type. :-)

If you want to do this, add the line

Option "XkbOptions" "ctrl:swapcaps"

to the keyboard inputdevice section of your XF86Config.

Ick!

[vanyel]

That's the one thing keeping me from switching to Opera on my Windoze boxes: I can't stand not being able to get multiple windows up on my desktop. I feel like General Zod and company in that window pane prison in Superman.

Re:Ick!

[crisco]

Yeah, I've gotten pretty good replacing the Alt-Tab with Ctrl-Tab, bonus points cause it works on the Linux version of Opera also. Opera has it's own memory problems though, seems to like lots of it on Win2K.

Interesting

[selectspec]

It never really occurred to me, but I don't ever use "free" windows anymore. My windows are always maximized, and I use a combination of atl-tab and workspace shifting to navigate between them.

I used to have 4 xterms neatly arranged sharing an entire screen, but I haven't done that in a while.

I don't like apps that have framed views which are not easily hidden, such as msdev and kdeveloper. I much prefer an xemacs approach, where I can zap in and out frames as I see fit, with a quick keystroke. Perhaps you can do the same with msdev and kdeveloper, but I'm used to emacs.

Re:Interesting

[spongman]

Perhaps you can do the same with msdev

yes you can, there's a keyboard shortcut for opening each of the dockable frames (eg the Visual C++ 2.0 bindings use Alt-2 for the output window, Ctrl-K for the callstack, etc...) and once the focus is in a dockable window you can use Escape to return to the current MDI child, or Shift-Escape to close the dockable window.

Xerox did not have it

[jchristopher]

Actually, I believe that Xerox did NOT have overlapping windows, it only appeared to. In the book "Infinite Loop" by Michael Malone, it talks about how someone at Apple Computer (Bill Atkinson? I can't remember) had such a difficult time duplicating what he thought he saw at Xerox.

In reality, it was very difficult to duplicate, because it did not yet exist. Atkinson (Apple) ended up creating the algorithims to do overlapping windows on his own. At some point he was in a car accident, and there was alot of concern, because at that point, he was the only one in the world that had the knowledge.

Re:Xerox did not have it

[Simon Brooke]

Actually, I believe that Xerox did NOT have overlapping windows, it only appeared to.

Then you believe wrong.

I personally used Xerox 1108 ('Dandelion') and 1186 ('Daybreak') machines from 1984 until 1988. They definitely, without question or possibility of doubt, had multiple overlapping windows, and, indeed, all the features of a modern WIMP environment. Xerox Stars, Dolphins, Dorados, Dandetigers and a number of other Xerox machines (including the Smalltalk ones whose model designations I've forgotten) had multiple overlapping windows at least as far back as 1978. It's probable (but I don't know this for a fact because I never saw one) that the Alto also had multiple overlapping windows, at least in it's Smalltalk mode.

Re:Xerox did not have it

[WolfWithoutAClause]

There's atleast three fairly simple ways to do overlapping windows:

a) draw the window into a buffer, and then only copy the bits of the buffer to the screen that are visible.

b) have a draw routine that only draws a square part of the screen at a time, and then call it multiple times for squares that make up the visible portion

c) draw the whole window into a buffer and then mask off the pixels that aren't visible using bitblt techniques

There may be others, not sure which one Xerox or Apple used.

Re:Xerox did not have it

[Simon Brooke]

While they definitely did have overlapping windows, at least some systems which ran on these machines had strange restrictions as to output and stacking order.

Sorry, I was there, I used 'em, I programmed 'em. Remember these were the machines for which the BITBLTer was developed. Certainly every window was stored as a bitmap, but that bitmap could be anywhere, and you could write to it anywhere. It most emphatically did not have to be on top of the stack or even visible. There were no operations which you can perform on a modern WIMP that you could not perform on an 1108 in 1984. No restrictions at all. None.

Windows Solutions

[Angry Black Man]

For those of you who use Windows, Cristi Posea has written a nice window docking code. It allows you to dock objects inside ActiveX containers. Until recently there were some major flaws in the code. However, Greg Winkler has fixed them all with this. You may want to take a look at it: Docking CSizingControlBar objects inside ActiveX containers by Greg Winkler.

GNOME, KDE, CDE, etc...

[ekrout]

I think the key things that seperates GNOME, KDE, and CDE (and to a certain extent, OpenWindows and HP VUE) from the rest of the window managers is the concept of underlying services that facilitate communication between apps. In Windows, it's OLE (or COM or whatever they call it nowdays). In CDE, it's ToolTalk; in GNOME, it's CORBA (I don't know what it is in KDE).

You see this underlying communication in various ways: the most obvious is Drag-and-Drop between apps (or the desktop and apps). It also shows up in inter-app communication with documents (think Excel spreadsheet embeded in a Word Doc).

I'd almost consider WindowMaker an environment. It has most of the hooks that Enlightenment and Kwm have for their underlying services, and can work nicely in a GNOMEish or KDEish setup.

I think when people say "environment", they're referring to the whole shebang: backend libraries and daemons that provide Inter-app communication, a Window manager that uses those backend facilities, and apps that also are aware of the available functionality. Integration is the key here: all the parts need to be aware (and use) eachother, and not just be able to function next to eachother.

No

[Stephen VanDahm]

I certainly hope that this never comes to pass. Sometimes it's OK, like when Konsole allows you to have multiple shells in the same window and select them via tab-like buttons. But the GUI design of KDevelop and other apps like it is bad enough to ensure that I never use them. Why? Because I use a laptop for all my computing stuff, and the laptop only has a 800x600 display. I can't have all these tiled and paneled windows screwing up my workspace. When space is tight, it's nice to control exactly where you want your stuff to be displayed on the screen.

Steve

Re:No

[TotallyUseless]

I think overlapping windows and choosing from a window menu of some sort would make more sense. For me, showing the window im not currently working on is a waste of space. I dont like working in a real small window, and when I use a laptop, the current window usually ends up taking up most of the screen. Some tiled setup with tiny windows would not work for me at all. I think the thing to notice here tho in this discussion, is there are a lot of perfectly valid arguments pointing in both directions on this. Seems the answer to me would be something that would allow you to switch between whichever mode you preferred or needed at the time, overlapping or paned.

Re:No

[spudnic]

While working, I tend to keep all of my windows maximized, switching between them with alt-tab. It gives me maximum real estate for the app that I am currently concentrating on.

Overlapping windows allows me (if needed) to pop up a smaller window over the app that I'm working on without resizing it.

The only use I can see for running all of your apps in tiny windows is for making cool screenshots of themes.

Windows 1.0

[fireproof]

Yeah, I've seen that time. It was called Windows 1.0.

Seriously, after looking at the ion screen shots, I can't imaging that being terribly useful to me. I've found that enviroments like Window Maker are most suited to my work style, but I'm certainly willing to admit that maybe my workstyle has been influenced too much by the reigning paradigm in UI.

I'd think that having stuff auto-tiled for me would annoy me to no end, but I think I'll try out ion and see how it works. Maybe I'm wrong.

Everything comes around again...

[aussersterne]

Back in the late '80s for a while I owned a small OS-9 computer (some of you will guess which one) which used to lay its windows out this way. As time went on and Windows and X became bigger items, I started to desire those "overlapping windows" and eventually moved to Linux in '93 or so to get them.

Now you're telling me that tiled, edge-to-edge windows are the wave of the future? I don't know. How about some sort of compromise which allows overlapping windows but doesn't "require" them to the same extent as today's desktops? I'm not sure I'd really like to do away with them altogether... sometimes you just run out of display space, and I'm not really interested in 45" of computer display.

Re:Everything comes around again...

[PurpleBob]

The compromise is multiple desktops, offered by practically every window manager there is. I'm surprise the submitter didn't mention them.

Since windows tend to be maximized most of the time, multiple desktops are an effective way of dealing with many of them, and then you can still have a desktop with small overlapping windows.

Re:Everything comes around again...

[DGolden]

Multiple desktops aren't quite good enough in most implementations I've seen (enlightenment comes close) - I've been spoiled by Amiga pubscreens.

Later versions of AmigaOS, in conjunction with common Amiga GUI toolkits such as MUI, allowed you to _persistently_ associate an application with a particular "screen" (a named virtual desktop). - So you could set your web-broswer to always open on its own screen called "Internet" for example, while your word processor opened on another screen called "Work", as did your spreadsheet.

The automatic creation/destruction of screens on an as-needed basis, the persistence of the application associations with particular screens, and the ability to name each screen, tend to be missing from X window managers. You flicked between screens by clicking the top-right hand corner of the screen, and you could drag them up and down to partially expose screens behind.

The "pub" in "pubscreen" comes from the fact that more than one application could use the same screen - in earlier versions of the AmigaOS, each application tended to use its own screen anyway, rather than being under user control.

I miss screens!

Ditching the old GUI paradigm

[Anonymous Coward]

That's one disappointing thing about today's GUIs, that there's no dialogue. The technology exists for the computer to, say, anticipate your next move, complete it ahead of time, and wait for you to tell it if it "done good" or not. For example, completing commands at a UNIX shell prompt is quite possible (in fact, it's been done before) and useful. One of these days (it's always "one of these days") I'm going to write a shell that does this.

Windows are a useful abstraction of display space and a useful way of dealing with user input. I wouldn't want to try to program a GUI without them. However, I'm not convinced that overlapping windows are not an unnecessary and cumbersome user interface element. I myself am an advocate of non-overlapping tiles as an efficient way for a user to manage his screen space.

Some say the web browser is the most popular GUI program. But the Web browser suffers from a whole host of problems. Just like the CD player programs that looks like the front of a CD-ROM driver, Web browsers only support plodding motion through the Web. The Forward/Back/Stop formula has got to go. A really slick Web browsing scheme that I saw at U. of Maryland, I think, provides a visual browsing history in the form of miniature views of past Web pages you've visited, with more recently visited pages still visible at about half the size of the page you're presently at, and pages visited very long ago appearing very small. I don't recall if the hyperlinks on the miniature pages could be activated, but I think that they *should* be, as that would make it really easy to move from one page to another if, say, you're at a Web directory of some sort.

Re:Ditching the old GUI paradigm

[forii]

The technology exists for the computer to, say, anticipate your next move, complete it ahead of time, and wait for you to tell it if it "done good" or not

Hey, this is a great idea! I can just imagine it:

You want to show your boss some documentation you found on the web. You click on "open location", and your computer, ever so helpfully, types in your favorite porn site, bringing up a bevy of blonde beauties on your screen. Embarrassed, you then hit the "done bad" button, and your computer
types in a new site, bringing up pictures of studly, muscular men on your page.

You hit the "done bad" button again, and try to laugh it off to your boss. You finally convince your computer to go to the website that you want, and when you try to download the specs, your computer auto-completes your request, downloads the file, and closes. Except that you don't know where the computer decided to put your downloaded file!

You then go to "find file" (after hitting the "done bad" button again) to find the file that the helpful operating system put somewhere on your hard drive, and start to type in the name of the downloaded file. Five aborted attempts at name-completion later (including the guesses "readme.txt", "Readme.txt", and "README.TXT"), you finally locate where the file was placed (in the /flesh/movies/ directory, incidentally)

"Halleluja", you tell your boss, as you open up the downloaded specifications. Time to print them out! You convince the operating system to open up the print menu (after telling it "done bad" for bringing up the "open file" menu four times in a row), and it automatically prints one copy to give to your boss. Great!

Whoops, except that you wanted another one for yourself. Hitting the "done bad" button again, you (eventually) get one more copy printed, and your boss walks away, happy to have his copy of the specification, and happy to have a few new URLs to check once he closes his office door.

Grateful that the operating system had allowed you to accomplish something, you hit the "done good" button a few times, and go out to get a cup of coffee. Mission Accomplished!

Those who will not learn the lessons of history

[Simon Brooke]

... are doomed to repeat them.

Remember that the Xerox movable overlapping windows paradigm appeared at a time when tiled and framed paradigms were widespread (Symbolics, TI Explorer, a whole range of other systems) and quickly became universal because it worked better. It still does.

Sure, there are issues in navigating the stack of windows, particularly if you use desktops as cluttered as I tend to; sure, less sophisticated computer users may find these navigation problems difficult. But focus, visibility, prominence and accessibility are in the hands of the user, and that's where they belong

No - but maybe a mix of the two

[Shade, The]

The problem is with dumping moveable windows altogether is that you lose immediate manual control. For instance if you want a specific window in a certain place, under the current system you can just drag it over. With a framed/fixed approach this wouldn't be as easy. However a mix of the two would certainly be nice, and to a certain extent, this is what is happening: the taskbar in Windows and KDE for instance, dock-apps in Windowmaker & co., apps embedded into the KDE kicker and so forth. But moveable windows still have their advantages, and will probably be around for a while yet (at least until we get cool 3D desktops like we see in the movies!)

Re:No - but maybe a mix of the two

[reverius]

I think you're kind of missing the point of a fixed frame desktop.

With movable windows, the only real reason you would want to move a window is to get it out of the way for something else.

With a fixed frame desktop, you don't need to do this, ever... nothing overlaps. There's nothing to move.

Resizing is another matter entirely... but I have a feeling that will be handled well by such applications (like the window manager ion).

I think that going from movable windows to a fixed-frame desktop will be like switching from a low-level language to a high-level one. Those who are used to C will complain that Java (or Perl, or other high-level languages) won't let you control memory... but new programmers will be thankful that you don't have to. :)

Re:No - but maybe a mix of the two

[Bryan Andersen]

I think that going from movable windows to a fixed-frame desktop will be like switching from a low-level language to a high-level one. Those who are used to C will complain that Java (or Perl, or other high-level languages) won't let you control memory... but new programmers will be thankful that you don't have to. :)

Yes, both moveable windows and fixed frame styles have their uses, but they also don't work for all applications. A fixed frame desktop is fine for an instrument, even preferable, but when the application mix isn't known it falls flat on it's face quite quickly. Better flexibility in what a user gets to do at the window manager level is what is needed. As an example I want it so my MP3 player of choice comes up in virtual window #1 with its song selection list to show up right next to it. As is right now I have to switch to virtual window #1, start the MP3 play, wait for it to load, move it to the desired location, open up the song selection list, resize and move it to wher I want it. If at any point I swith to a differnt virtual window while the MP3 player is loading it shows up in that window, not in #1 where started it and want it.

The analogy of low level versus high level language dosen't fit. Matter of fact I'd say you have it reversed. A fixed position window manager is really a lower level example of a moveable pane window manager.

Yes.. if optional..

[MikeFM]

I think tabs and frames are a common interface now because of popularity in web interfaces and they've proven to be useful. Docking and stacking has always been rather useful. I don't want forced to have a 2D grid of windows though. I like it made easy to align windows to a grid and to other windows and like it when I can stick them together so if I move, open/close, etc one the others will follow. I also am really waiting for the day that KDE/Gnome stop chasing Windows and put some really useful features such as pie menus, cluster menus, and gesture support in rather than all the nasty pull down menus and icons. At least Mozilla is supporting these things so any Mozilla-based apps should be able to also.

It has to prove itself.

[VA Software]

Microsoft's new Visual Studio.NET implements some, if not all of this. Windows can be either free floating, docking or added to a tabbed set.
I've not used it much yet, so I don't know what layout I'll end up using.

At the moment it is set up the same as my VC 6 layout - workspace in the top left. Output/Build windows tabbed in the bottom right and the editor window taking up the entire right hand side - I like to see lots of code at once.

The default view was way too busy - for example it showed compilation errors twice - once in the standard compiler output window, and once in a new "tasks" window that allows you to tick off the errors once you've dealt with them. Maybe this is useful for one of the other languages .NET supports, but it isn't how I work with C/C++.

It would be nice if this flexiblity with floating/docking/tabbing was in the window manager instead of the application; although, to be honest, developer studio is the only application I use with a large number of internal windows. Most applications are much simpler - tending towards a single view on a single set of data.

Re:Here's why the mainstays for Linux development

[mgkimsal2]

Start at the ground up. Get ahold of the source of a weak windowmanager like fvwm, that has all the basic guts you need to work from. Ask yourself what makes sense to you as a user, NOT what makes sense because you've seen the same thing in Windows. Give Linux its own look. Try to avoid imitating other platforms. Build it because it makes sense to build, not because "Windows has it". The sheer number of things that Windows has wrong with its UI would require a completely separate article to discuss them in detail. Think about how to represent things differently. Is there a better way to represent the same information? Do you really want an OS that resembles a browser? Think, ask, and move. Learn, modify, and repeat.

What if I want to put in a feature because it makes sense *AND* "Windows has it"? What kind of moral dilemma does that bring up? Refuse something sensible, because it's in Windows? Or implement an idea, and have people like you blast it because it's "copying"? Hmmm.... Really not sure which one I'd choose... Why not discuss those things "wrong" with the Windows UI then? Really - back it up - write an article - post a link to it here. I'd love to read it - because for as much as I think there are some screwy things with various versions of Windows, *every* Linux UI I've used has been worse by a huge margin, either in terms of speed, or refusal to have standard ways of doing things across all apps (copy/cut/paste/etc) or *UGLY* graphics and fonts. And I do mean ugly.

KDE and Gnome are both making strides in improving things, but each still have many improvements to make to be as usable as Windows is for everyday people doing everyday tasks. Some of it isn't their fault - building on X, for example, brings its own problems - but for goodness' sake, Windows is still, on the whole, more usable than pretty much every other effort out there.

acme/wily

[DrSkwid]

acme is the primary text editing / programmers tool on plan9 and inferno
It doesn't use overlapping windows but uses rows and columns for text areas. One can maximise to size of the column.

there are no dialog boxes, turns out you don't actually need them. File/directory interaction is just in place (click on a filename in the current directory and ti gets opened [very useful for opening include files etc.]).

this also works for running programs. middle click on the command anywhere in any window and it's stdout gets opened in a new window.

try it and you'll see how simple and innovative such an approach can be. These plan9 guys are really on to something.

Re:Here's why the mainstays for Linux development

[jchristopher]

Nobody is willing to think about doing anything different, more useful, or more ergonomic right now. The main driving force driving Linux UI development is "lets make it look like Windows!" which is a horrendously bad move. Instead of giving Linux its own face, its own appeal, and its own distinct look, we're playing Poor-Man's Explorer with X11. Instead of putting our own talents to work, making something useful for us, we're playing second fiddle to a third rate design by copying it.

It is shameful and speaks volumes about the moderation system that the parent post has been moderated "flamebait". Take a moment to read the parent post and think about it. This IS a major problem for Gnome/KDE - the goal should not be to emulate Windows, the goal should be to EXCEED Windows.

We aren't too far from these ideas already.

[zCyl]

As for ion, it appears to be a restriction on user ability, rather than an increase of user ability. I can already align my windows such that they don't overlap if I desire.

But I already have the flexibility of using my graphical interface almost entirely without my mouse. I'm running Gnome and Sawfish, and I can setup multiple desktops, indexable with alt-F#. Then if I keep the number of windows on my screen down to a reasonable number, no more than 3 or 4 (which is what ion would be limited to anyway for reasonable space consumption), then I can tab between them almost instantly with alt-tab. Then I can access them all immediately without the mouse, and without sacrificing the size of my windows, because they can all be close to full screen. As for organizing by graphical tabs, that's what the tasklist in the gnome panel is for, which is always an option when one feels the urge to reach for the mouse to find a window.

Every application I use regularly on my computer has an associated Sawfish shortcut. Mozilla, gnome-terminal, xmms, etc... Even shortcuts for common functions can be created in Sawfish, such as a shortcut locking the screen, shortcuts for raising and lowering volume, shortcuts for playing cd's (all using console-based tools, and the ability to bind a key combination in sawfish to the launch of arbitrary programs), shortcuts for closing a window, and shortcuts for bringing up frequently accessed files.

Excluding web browsing and copy/paste, I could go an entire day without having to reach for the mouse.

Glad this is happening

[FattMattP]

I'm really glad this is happening. I've always hated the concept of windows and having to constantly shuffle the windows around. I miss the days of my Amiga where we had "screens" that we could flip through and even drag down to peek at the one behind.

The closest I can get to that now is to use MS Windows and to maximize every window that I can. it's close enough and at least that way all of my pull down menus are in the same place even if they aren't right at the top where they should be because the title bar is in the way. The Mac puts the menus in the right place, but Mac apps are more obsessed with using lots of windows than MS Windows. I know I can maximize them, but at least with MS Windows, I can save that setting in the icon. Not all Mac apps remember the window settings.

If I can figure out how to make every app's window to maximize under KDE without having to explicitly push the maximize button, then I'd be more inclined to make the switch to Linux for all my work.

If it's good enough for Geordi...

[eclipse127]

Well, if you notice, in the Star Trek universe I don't see anybody woth a pointing device of any kind... "keyboard" console only... it would seem that at some point in the future somebody just makes the decision that were going with ion... we might as well give it a look!

-EclipsE

Re:If it's good enough for Geordi...

[spudnic]

I'm not a Star Trek junkie, so I may be wrong...

In the ST universe that I normally see on TV, most devices seem to be dedicated to a single use. There is no switching applications. On the more sophisticated devices the interface seems to be audible rather than visual. Why would you need a mouse when you could just tell the computer what to do?

Of course, the voice interface will (probably) never take over as a primary input or navigation system. First of all, it takes longer to describe to the computer what you want it to do than a simple key combination or mouse click. Secondly, could you imagine the noise created by 30 developers and 5 secretaries in their cubicles in one big room all talking to their computers?

No, the keyboard/pointer interface won't be replaced until we can tap the brain for input.

Re:If it's good enough for Geordi...

[scrytch]

In the Star Trek universe, the captain can throw out some long string of Treknobabble like "augment the phase relays with the shield harmonics using an inverse of the warp field and route it through the main dish", and the ensign at the console hits three buttons and it's done. I'm pretty sure those buttons read:

[WHAT] [HE] [SAID]

Evolution towards less windows

[Drone-X]

For some time now I've seen this trend towards more heavyweight applications rather than small, lean applications that are used in conjunction. Now, this isn't a bad thing per sé since shared libraries or components can be used to share code.

It also has an advantage for desktop users because these heavyweight applications have the unique possibility of using paradigms different than windows for managing documents/tools reducing the window clutter on the desktop. E.g. in a PIM several related applications are presented in one window (where if needed the different components can often be opened in a seperate window anyway); in an IDE it is common to have a form editor, code editor, class browser, debugger all in one window.

But there are other approaches that can be taken. I've read dialog windows in MacOS X stick to their owner which is nice because it reduces the amount of windows you have to manage. X window managers could probably implement this feauture pretty easy.

But more can be done, e.g. it would be nice if there was a Nautilus-like panel on the right side of the screen in which things like music players, instant messengers, calendars, RDF-boxes, etc. could be embeded (these would be Bonobo components or KParts). An idea would be to model the panel after Nautilus' sidebar, only when hiding a tab the panel should disappear completely except for the tabs at the bottom of the screen.

In conclusion, it would be nice if the desktop environments started to work more towards reducing the number of open windows rather than taking the GLADE appraoch where there's a window for the menu and tool bars, a toolbox window, a property window and a window per form. (Yes, I know of workspaces but that ruins the advantage of windows even more.)

You'll take away my xsnow...

[uid8472]

...when you pry it from my cold, dead hands.

PicoGUI!

[RevAaron]

Surprised no one else mentioned this, but if you're interested in windowing systems with no overlapping windows, have a look at PicoGUI. A really cool (IMO) little windowing system that is network transparent, and runs well on little resources. E.g., there's PicoLinux, a linux OS for a PDA called the Helio.

Re:PicoGUI!

[RevAaron]

Indeed. I've played around with it under SDL on Mac OS X and on my Helio, and it works quite nicely. Surprised how fast it is on the Helio compared to the other options out there (W, PocketLinux (ugh), and VT-OS). Hoping to get some TinyScheme and Lua bindings out there so people can write apps in a tiny language that is also dynamic.

Tiling windows seems like a far more intuitive way to manage windows on a PDA. Overlapping windows is absurd on a PDA, IMO- there's simply not enough screen space, even on an iPAQ (which still has a lot less than on a Newton MP 2x00). Having a full-screen setup like Palm apps doesn't quite work either, as it restricts you to a single task at a time.

We already have options in many ways, like mo

[kalinh]

Rambling warning, I'm sicker than hell, and extremely tired from playing civ all night... mod down at will.

I've been thinking about this for a while, nothing frustrates me more than having windows obscured behind something else, and having to either drag the front window out of the way, or else alt-tab through everything. In a lot of ways this is what first got me hooked on linux as a desktop replacement for windows, the well developed multiple desktops system. So I can hit a key combination and cycle from one desktop to another. One has my mail and IM open on it, the other one browsers, the next nothing but terminals, and then filemanagers/xmms.

A lot of application shave taken a better look at how they're actually used. Sometimes the UI is bad bad bad (StarOffice 5.2). Other times it's really appropriate, like the tabs in galeon which are great for organizing all the browsing into different windows based on subject (for those of us that like to have 20 pages open at once. Right clicking to open in a new tab is great for s site like slashdot, K5 or Adequacy, where there might be 7 or 8 links on the main page that i want to get to, but not forget if I get sidetracked.

When I first grasped mozilla's power as a platform I had the epiphany that since 90% of the apps I ran were network based and mozilla provided an API for creating spiffy looking network applications, it wouldn't be a stretch to do everything in tabs within one maximized window, and that it could eventually function as an OS for lightwieght computers. If you type chrome://messenger/content/messenger.xul in mozilla you can get the entire mail application dropped into your browser window. Press ctrl-T on a recent build and you have a new tab to browse in, but you can switch back to your mail real fast. Add Jabberzilla to your sidebar. Throw in a few more apps from MozDev.org and you can do most of what you'd want within a single window. It's in no way complete or stable, but it's enough to shed some light on a usable way to avoid the worst of window overlap. Apparantly there is a company that's working on using mozilla as an operating environment for appliances called OEone. You can check out the screenshots of their calender application here.

We already have a modern successful non overlapping interface, and it's called PalmOS. Just as it took a limited use platform to accept "modeing", probably not a lot of desktop users will be willing to give up the poer that free windowing gives them, but for appliances, or special uses, such as subject-centered web browsing. Things like tabbing and fullscreen interfaces are a good idea, and have already been implemented.

Reminds me of Oberon...

[DaoudaW]

Anyone with Oberon experience out there?? It started out as a tiled windows system only, but now they've developed an overlapping windows desktop as well. Checkout the screenshots.

Their comment on tiled display is useful: The Gadgets desktop also has a tiled display mode with two vertical tracks. In this mode a newly opened viewer automatically covers half of the largest existing viewer in the track. This is ideal for text-based work, e.g., programming or text editing. Viewers can be resized vertically and moved, but they always use the full track width. Because there are fewer degrees of freedom, it is much quicker to arrange viewers optimally. newly opened viewer automatically covers half of the largest existing viewer in the track. BTW, windows are called viewers in Oberon.

tabbing, etc.

[Mike Hicks]

I've noticed that most people seem to do everything full-screen in Windows. I'm not sure if they find it easier to navigate. It might just be that their displays are too small (and here I am with a dual-head desktop of 1600x1200 and 1280x1024 ;-)

Re:a new paradigm would be welcome

[Znork]

Why? Because it just isnt an improvement. Come up with a useful improved desktop environment that increases productivity by introducing 3d. Yes, it would be cool, but as long as it isnt *better* it is also *useless*.

I dont believe it can be done. Not until we have real 3d displays with 3d input devices and probably not even then.

Why? Because most of those working with computers are working with information. Information is almost always most efficiently conveyed via text, sometimes with added images. Text and images are 2d. You spend most of your time working with a 2d environment, in either case. So where is the gain in 3d? As an alternative way of navigating workspaces it's merely 'cool', but not even a navigational improvement over the pagers of multiple desktop spaces in most window managers, not to mention the problem that 3d spatial awareness isnt exactly something that most people find easy. I'm sure you or I could easily say at what exact position our wordprocessor is if we rotate the polyhedron a few steps around, but a lot of people dont find it a trivial task.

a step backwards?

[8bit]

In a way this can be look on as a step backwards. It limits the user's freedom to arrange the windows. But I can also see how it's a step forward. It reverts to the KISS (keep it simple stupid) paradigm, and concevably, you can increase productivity w/ ion. You don't have to waste time moving your windows around.

I personally use pwm, ion's sister. It lets me stack all my terminals into one frame, and quickly cycle through them. I rarely have to switch virtual desktops anymore. But of course, with everything, it's just preference.

AfterStep and workspaces

[D_Gr8_BoB]

Seriously. The best feature of AfterStep, my WM of choice, is a damn lot of workspaces with definable key bindings to switch between them. I usually keep 4 groups of 8 desktops each open: one group for terminals, one for web browsers, one for TIK and XMMS, and one for miscellaneous stuff. Getting around is as easy as glancing at the pager, then CTRL-arrow key and/or CTRL-SHIFT-arrow key
.
If you are really mouse-phobic, you can also define keys to move your cursor around. Combine this with auto-focus and you'll be surprised how little you'll use your mouse.

AfterStep is just amazing.

Simplistic Desktops

[DzugZug]

While this seems to work well in theory, one should note how simple the desktops in the screenshots are. Three of them have an image, emacs, and a shell. The ION model works well for 3 windows but I have 11 windows (emacs, galeon, evolution, XMMS, abiword, gaim, 2 shells, realplayer, 2 xchat, nautilus) open right now on 4 VDesktops.

Tabs work great unless you want to see two things at once.

Good thread

[Anonymous Coward]

This gigantic thread examines the "overlapping windows vs. alt-tab-mania" battle in some detail.

some more info

[buzzini]

When I interned at Microsoft, one of the designers gave a talk about this. He said that part of why overlapping windows were originally used was that monitors had such low resolutions. With the advent of large, high-resolution monitors this has become less necessary. Hence OfficeXP containing a lot more "docked" palettes (e.g. Task Panes). This is definitely the direction of the future.

It was called "OpenDoc".

[jcr]

Hey, go the whole hog and find an easy way to send messages from one of the programs to another and bingo! the user suddenly can create his very own programs out of small components - the gui equivalent of the command line philosophy perhaps?

There were a few cool ideas in OpenDoc, but regrettably, they implemented it in C++.

-jcr

How to get a sort of tabbed interface with FVWM2

[oddityfds]

I use a window manager with virtual desktops (FVWM2). On every desktop I have either lots of maximized Mozilla windows, or a couple of xterms to the left (mximized vertically) and one Emacs window to the right (also maximized vertically). I switch between desktops using the mouse, and between windows by pressing F2 (which rasies or lowers the topmost window under the mouse). This works well for switching to the right xterm or browser window. Focus is always on the topmost window under the mouse, of course.

This way I get all the advantages of a tabbed interface while still being able to use the window manager like an ordinary one when that would be useful.

My windows are borderless, but they have a titlebar. I use the titlebar or F1 for moving them around and button-3 on titlebar or F3 to resize. F5 maximizes the window.

No window manager thing

[redhog]

Actually, I do the same thing using fvwm, maximized windows, and a program I wrote - Xmerge, which merges two windows into one with two frames.

Hooray

[Lars T.]

At last Windows 1.0 has been redeemed! If only we can get those great colors back.

Re:Here's why the mainstays for Linux development

[reverius]

Amen to that!

That's ridiculous.

[Nindalf]

As Tog says, in one of the linked articles: "We programmers are not normal people. We tend to have superior memories, we actually grasp boolean logic, we have formed priesthoods around the most egregious interfaces, and we have a firm belief that the average citizen is in search of an editor for his daily C and Pascal coding tasks." He says this because he wants to make it clear that he's not talking about people like us.

This research applies to the casual computer user of the late 1980's. Completely non-standard (and really hideous) keyboard interfaces were compared to consistent mouse interfaces for people who had probably only recently touched a computer for the first time in their lives. By a company that was betting the farm on the mouse interface.

The one example I see (replace all '|'s with 'e's) is unrealistic and obviously biased toward the mouse, though he presents it as intentionally biased toward the keyboard. That was all I needed to see. This was an incompetent, biased researcher with a tendency to dramatically overgeneralize.

Overlapping windows are here to stay...

[ColGraff]

...for the same reason that Microsoft Windows is here to stay, and Intel, and MS Word, and any other number of products that aren't really the best at what they do but all share one key feature: a huge user base familiar and comfortable with them. Is an Ion-type interface better than conventional overlapping windows? Honestly, I have to agree with several other posters who've said it all boils down to personal preference - some people's work habits are more compatible with overlapping windows, and others with ion.

The thing is, the mainstream computer users - you know, the ones who their ISP is Internet Explorer? - are used to overlapping windows, just as they're used to working in Windows, and MS Word, and Internet Explorer. Most people either don't care about the advantage they'd gain with a new paradigm for windows management, don't understand them, are completely unwilling to learn a new system, or all three bundled as even more neuroses and whatnot than I can think of. I've lost track of the times I've left the family dual-boot BeOS/Win98 system running BeOS, and heard my mother complaining that she just could not figure out how to use it. Nor is she willing to learn - despite what we all know about the BeOS GUI, Windows is better because my mom is familiar with at, at least according to her.

Might we see ion-type window managers become more popular in GPLed OSes like Linux, BlueOS, etc? Eh, maybe, although there's still the personal preference angle even among the computer literate who could understand and learn to use the new system. Likewise, I could see a real change in the MDI schemes for specific applications. But I think the average desktop home user is going to be using some sort of conventional overlapping windows environment for a long time to come.

Re:Show us your .sawfish key-bindings!

[zCyl]

Ok.

First of all, in order to enable the special keys on my laptop, I went into gnomecc, Session Properties and Startup Programs, and added a Startup program to execute: /bin/sh /home/user/.xinitrc

Then I made an .xinitrc that reads:
xmodmap -e "keycode 66 = Caps_Lock"
xmodmap .xmodmaprc

Then I made an .xmodmaprc that reads:
keycode 66 = Caps_Lock
remove control = Caps_Lock
add lock = Caps_Lock

keycode 115 = XF86Start
add mod4 = XF86Start

keycode 129 = XF86AudioPlay
keycode 130 = XF86AudioStop
keycode 131 = XF86AudioPrev
keycode 132 = XF86AudioNext

Play with those, it's not hard to get most special keys working. (Find the keycodes by launching xev and pressing the keys.)

Then I added the following sawfish shortcuts (which is easiest with the gui, but here's the lisp code from .sawfish/custom):

(custom-set-keymap (quote global-keymap) (quote (keymap
((set-viewport-linear 0) . "M-F1")
((run-shell-command "gvim -rv ~/todolist") . "S-XF86Start")
((run-shell-command "aumix -v+1") . "M-Prior")
((run-shell-command "aumix -v-1") . "M-Next")
((run-shell-command "mycdplay") . "XF86AudioPlay")
((run-shell-command "cdplay stop;rm ~/.cdplaying") . "XF86AudioStop")
((run-shell-command "cdplay -") . "XF86AudioPrev")
((run-shell-command "cdplay +") . "XF86AudioNext")
((run-shell-command "xmms") . "M-C-j")
((run-shell-command "mozilla") . "M-C-w")
(unshade-window . "C-SPC")
(shade-window . "S-C-SPC")
(delete-window . "M-C-ESC")
(iconify-window . "M-SPC")
((run-shell-command "gnome-terminal --login") . "M-C-t")
((run-shell-command "gnome-terminal --login -e mutt") . "M-C-m")
((run-shell-command "xscreensaver-command -lock") . "M-C-l")
(move-viewport-left . "M-C-Left")
(move-viewport-right . "M-C-Right")
(move-viewport-down . "M-C-Down")
(move-viewport-up . "M-C-Up")
((set-viewport-linear 2) . "M-F3")
((set-viewport-linear 3) . "M-F4")
((set-viewport-linear 1) . "M-F2")
(cycle-windows . "M-TAB")
)))

And if anyone is curious, mycdplay is a simple little shell script as follows (All it does is make my play button function as a pause button whenever the cd is being played, and a play button otherwise):
#!/bin/sh

if [ -e ~/.cdplaying ]
then
cdpause
rm -f ~/.cdplaying
else
cdplay
touch ~/.cdplaying
fi

Until I read you're question...

[mikosullivan]

... I hadn't give it much thought, but I almost never use the floating window paradigm anymore. As I type I have three applications runnning, each in full-screen mode. I alt-tab between them with as little conscious effort as steering the car. I can't stand working in a floating windows except when they are small utilities like a calculator.

The interesting development may not just be that floating windows go away but also that hardly anybody even notices.

You can have your cake and eat it too

[Salamander]

The ideal interface, in my opinion, would be to support nesting of window managers within other window managers and/or within applications. The biggest problem with MDI is that every MDI application basically acts as its own window manager. Usually this "embedded window manager" is a really crappy one, which turn people off to MDI in general, but there are exceptions; my preferred browser and text editor both use tabbed document windows to very good effect. It would be cool if we could tell applications what window manager instance (WMI) to use, so that the app can delegate window management to the WMI of the user's choice. Want SDI? Tell the app to plop its subwindows into the same WMI as the parent window. Want MDI? Tell the app to plop its subwindows into a WMI ("using *this* window manager, please") embedded within the parent window. You could use the same interface to switch between a Mac-style single menu bar and Windows-style per-window menu bars. All of this could go into a fairly simple config file, allowing users to choose whatever combinations of overlapping/tabbed, MDI/SDI, Mac/Windows styles - including hybrids and mixed modes - that they want.

Re:You can have your cake and eat it too

[Salamander]

The fatal flaw with MDI is the nesting of window management. This is often not desirable.

Often. Often, not always, and because it's often not desirable, or because you personally don't find it desirable, you don't want anyone to have the option? The whole point of what I was suggesting was to give choices back to the user. If you personally don't like MDI, don't use it; just set up your preference so SDI is used throughout your environment. Problem solved.

If you find yourself wanting MDI it's probably because your main window manager is not very usable (but may look pretty, eh ;)

Au contraire. I use icewm on Linux because it's pretty much the most minimal (but still functional) window manager I could find. What eye-candy-laden window manager do you use?

The fact that MSDEV forces you to have all your windows in a single huge (99% of the time maximized) window just sucks IMO.

Yes, it sucks, but not because it's MDI; it sucks because it takes a choice away from the user. As you might have noticed if you had read the rest of the comments on this thread, some people actually like MDI. Do their preferences not count, should they be ignored because you're more "elite" than they are? I don't think so. They should have that choice, and the way to let them have that choice is to improve the way that applications and window managers interact.

Re:Oberon

[dave-fu]

So I'm not the only one who remembers Oberon.
Oh, Niklas Wirth, where are you when we need you?

Re:a new paradigm would be welcome

[Pope]

I'm not so sure I agree with you 100% there.
One of the thing that bugs me about OS X is that it uses Windows' / X's idea of each window being its own "layer" rather than each application being its own layer like it is in regular MacOS. Some people love one way, some love it the other.

Right now, for instance, I have 2 images loaded in Graphic Converter that I can see behind the current ImageReady document for reference. I could never do that in Windows because of the MDI.

I doubt a 3D interface would be any improvement because then you'd be wasting time rotating and selecting things on a polyheadron instead of a flat space. Unless 3D monitors and 3D input devices come along with it, but then you're left with the silly "Johnny Mnemonic" hands in gloves waving in the middle of the air with goggles on input that sounds soo cool when reading it but looks downright goofy when you see someone actually do it in a movie.

MS-Windows 1.0 tiled?

[peter303]

I recall this was the case. This was supposed to
avoid Apple patents by reverting to a Xerox look.

No one really bought Windows until version 3.1
and MS Office requiring it.

Re:No accounting for taste...

[spudnic]

I'm not trying to be argumentative, I'd really like to know... How does using nonoverlapping windows decrease the amount of time you use your mouse?

I switch windows all the time using the alt-tab combination. What am I missing here?

Cognitive limits, etc.

[ecloud]

The real limits might be cognitive ones; how many windows can you open before you begin to forget what is what? Already on 6 virtual desktops sometimes I leave windows open for a couple weeks at a time, and then wonder what I was using them for. And when I tried using Opera, I found that because I could leave a lot of browser windows open, inside its MDI space, that's what I did; and soon the list of open windows started looking more like a bookmarks list.

So I thought that windows should expire after some amount of disuse. They should _become_ something like bookmarks (searchable by metadata (title, keywords, URL, full text, etc.), and also organized in a timeline, and also organized in a graph of branching - which link did you follow to get there?) automatically.

On either a tiled or overlapping desktop, the constant is that being able to minimize or collapse windows to remove them from the screen is important. But on a tiled desktop it would be even more important than usual. And I think the GUI mechanism for selecting from all open windows (including minimized ones), which one to view, is very important. I've recently fallen in love with the KDE "external taskbar". I put it in the upper right, enable auto-hide, and now it's very Mac-like, and compliant with Fitts's Law - I can slam the mouse up into that corner and I get a nice list of open windows, organized by which desktop they're on, without regard to whether they are minimized or not. There is enough space to show more of the title bar than you get on a typical minimized icon in WindowMaker, or a on one of those taskbar buttons on Windows or Gnome, yet, it still doesn't take up a lot of real estate, and still has mini-icons too. I can manage many more windows effectively this way. And it's rather like a stack of books (an approach to organizing information which has been advocated elsewhere).

Anyway for many purposes I like the idea of a tiled desktop; especially for "reference materials" which I need to glance at, but not interact with quite as much. But I think the user needs a very straightforward choice when spawning a new window, whether to take up space in the tile matrix for it. Maybe something like click with middle-mouse button on a link, to open it in a new tile-space; and click with left-mouse to open it in the same space, in a new window lying on top of the old one. So each tile-space becomes a stack of windows. (And I'm imagining a GUI in which most navigation is a lot like navigating hyperlinks.) Of course, every time you must make room for a new tile-space, it's liable to cause most other windows to be resized; and controlling that is tricky. Using virtual desktops effectively can help with that. It needs to be easy to move windows from one desktop to another, _and_ place them into the desired tile-space, in one fell swoop, without a lot of mousing around, or thinking too hard.

Maybe there should be a window manager which gives you a choice for each desktop - tile or overlap. I would bet quite a lot of money that will be done by somebody in the next few years.

Re:a new paradigm would be welcome

[lkaos]

Come up with a useful improved desktop environment that increases productivity by introducing 3d.

Why do you assume 3d increases productivity? Our site is 2d with the third dimension (depth) being a calculation our brain has to make. Many studies have proven that the human mind responds quicker to plain, 2d geometric shapes (boxes, and triangles), than it does to complete 2d pictures or 3d images.

A 3d desktop is just simply a buzz-word. While something other than the current paradigm is bound to be more productive, the answer is probably in the presentation of maximum amount of info in the limited 2d space.

Re:Docking behavior never the right thing

[Seor Jojoba]

I agree. These days it seems like the first thing I do after running any productivity app for the first time, is hide 90% of the toolbars and docking widgets. Then I can have something larger than a postage stamp in which to view my main document.

I think the real trick is designing UIs to put choices on the screen only when they are useful in a given context. And that just takes consideration of the application tasks involved in a given context--no real innovation required. Having fifty million available dockables is like throwing the whole UI design to the user and making them handle it.

If monitors get really cheap and huge, I still don't want to see that braindead clutter surrounding every document.

Re:Here's why the mainstays for Linux development

[mgkimsal2]

Holy cow - let's be disingenous, shall we?

First off Windows lets you select various "appearances" - comparing a stock Win 9x screen with a customized Linux desktop is not apples to apples.

RegEdit really isn't meant for most end users.

Windows still has consistancy over any Linux desktop - Alt-F does pretty much the same in every app. That's not the case in KDE, or Gnome, or anything else. Nearly every program I run under Linux has a different file browsing mechanism for opening files in an app. GIMP is different than KWord, for example.

Compare Windows95 with standard X - http://www.tapinternet.com/X.png. Now what looks better?

BTW, that non-repeating background looks just as stupid as the non-repeating "clouds" background in Win95 at resolutions higher than 640x480.

But I suppose once you're used to Linux, you take such basic functionality for granted.

I'll tell you what other basic functionality I take for granted - being able to copy something to a clipboard and paste it into other apps. ANY other app. OR - being able to highlight text and replace it with the clipboard contents. That seems to be an unheard of concept for many Linux users I talk to (one of them works here).

Why keyboard beats mouse for text editing

[ElrondHubbard]

Two words: keyboard navigation. In the Windows world at least (yeah yeah, bite me), anyone who bothers to learn the relevant keystrokes and combos can whoop the pants off a mouser in basic, nuts-and-bolts text editing tasks like selecting ranges, cutting and pasting, applying attributes, etc. Why? It's not the amount of time it takes to reach for the mouse; that is as nothing against the amount of time it takes to orient hand/mouse to screen/pointer, navigate the pointer to the appropriate button by eye, and click. I type 100 wpm on a good day, and my fingers know exactly where to go at all times. The visual interface is fine, but (for me at least) it lacks the benefit of proprioception. When I use the mouse, I am forced to stare at the screen in order to be sure of the result of my mouse movements, whereas I always know exactly what my keystrokes are doing without having to look.

For example, in most Windows text editors, pressing Control-left-arrow moves back one word. Further, holding Shift while using any navigation key combo changes the navigation action to a select action. Therefore if, for example, I want to select the paragraph I am currently editing, all I have to do is press Control-Down (end of paragraph), Shift-Control-Up (Select to top of current paragraph), and it's done. Elapsed time, about a tenth of a second. A couple more keystrokes and I can cut or delete the paragraph, add formatting (B/U/I, justification, etc.), and so on. Compare that to the time it takes to lay your hand on the mouse, move the pointer to one end of the paragraph, click and drag to sweep out the paragraph by eye. No contest.

Heck, my typing speed wouldn't even be what it is if it weren't for keyboard shortcuts. As an instinctive touch-typist, I seldom miss a typo as I go along, and by now it's a perfect reflex when I notice I've just mistyped to press Control-Shift-Left and retype the word - elapsed time, maybe half a second; expended effort, negligible.

Re:Why keyboard beats mouse for text editing

[vanguard]

I like keyboard shortcuts too but you example isn't perfect.

For one, I pasted your paragraph into notepad and your shortcuts didn't work. (The paragraph selection) I tried it in winword and it worked fine. So if it's not standard in yhe OS you lose a lot.

Finally, paragraph selection isn't quite as easy if you're not talking about the current paragraph. If you needed to pick a paragraph that was six pages away the mouse would be better. In short, you need both. (I bet you'll agree with this)

Re:Why keyboard beats mouse for text editing

[Bud]

Therefore if, for example, I want to select the paragraph I am currently editing, all I have to do is press Control-Down (end of paragraph), Shift-Control-Up (Select to top of current paragraph), and it's done. Elapsed time, about a tenth of a second. A couple more keystrokes and I can cut or delete the paragraph, add formatting (B/U/I, justification, etc.), and so on. Compare that to the time it takes to lay your hand on the mouse, move the pointer to one end of the paragraph, click and drag to sweep out the paragraph by eye. No contest.

Reading through the lines of your post, it's apparent that:

• the OS you're using doesn't invite you to use the mouse, so you refrain from using that input method and have started disdaining it
• you have memorized several dozens of shortcuts for a certain editor widget and need to justify it to yourself and others
• using higher-level parts of your brain on doing low-abstraction-level things makes you think you're working harder and faster

Maybe you should start using another platform, or another editor widget? Mousing skills are always mousing skills, but adapting to one editor widget will CRIPPLE your productivity in other editors.

Besides, no-one is REALLY going to believe that you can do a control-down + shift-control-up in one tenth of a second. But to be fair, no-one can triple-click a credit-card sized target in that time either.

--Bud

tabbed windows save time

[rixdaffy]

Once upon a time I noticed that I always have too many windows open and spend too much time finding one of the many xterm's and netscape windows I open at the same time... The first solution for me when was when Powershell arrived, which was I think one of the first xterm apps to allow tabbed shells into a single window... Later kde's xterm started to support this as well (though I don't use KDE so I don't fancy getting the extra bloat that comes with it)...
Later I found ion's sister windowmanager called 'pwm' which does the same thing of all windows and can automatically stick windows from the same app into one single window... ie if you open a new Netscape window, you can have it automatically stick to all the other netscape windows you have opened... it only sucks with popup windows on sites as they will be opened at full size but then you never ask for them anyway...

tabbed windows are a great solution IMHO as I never found any quicker way to navigate the many windows I open at the same time...

Use Multiple Workspaces Instead

[KidSock]

Since XFree86 supports multiple workspaces I find the fixation on overlapping windows quite silly at this point. Rather than flipping between windows, why not flip between workspaces and maximize or tile two windows per workspace. I mapped F4 to next-workspace and F3 previous-workspace and tile two xterms per workspace. In this way I can simultaniously edit 3-4 source files and build/run windows open all at once. I usually have one maxed xterm for watching debuggin output or exploring huge directories and another workspace for just Netscape. To switch between them is a matter of hitting F4 to shift to the right and F3 to shift back (at least this is trivial in WindowMaker; it has runtime game-style key mapping). Try it, you'll utilize much more surface area and as a result be more productive.

Mainly xterm's

[ftobin]

Is it just me, or does it seem like the majority of the windows the screenshots for ion are terminal emulators? ion may be suitable for users who use terminal programs which don't need a lot of display for each of them or aren't 'updating', but for me, along with my 3 xterms I usually have 2 X irc clients, 2 Mozilla windows (2/5 of the display each), xemacs, xbuffy, and xconsole all running on one desktop (I use my other desktops for background tasks).

5 of those windows (2 IRC clients, an xterm, xbuffy, and xconsole) are what I consider to call 'background but updating' windows; I generally don't tab over to them untill I see them notify me of a change; currently I see change by overlapping them just enough to the point I can see updates.

And that's not even considering the three 'primary but static' windows I'd be working in (Mozilla, xemacs, and an xterm) which I want to be occupying the majority of the screen so that I can be reminded of the current context in each of them. What overlapping windows does is allow me to fine-grain how much of the Windows I want to see, and place them on the desktop in the arrangement I choose fit. I don't see cell-based ion doing that for me.

not just Xerox

[mj6798]

Bell Labs holds a key patent on the implementation of overlapping windows (I think they never tried to enforce it). Work at MIT also involved overlapping windows.

"Intuitive" Interface

[Curt]

The overlapping windows is just one of those things that *just plain works* in a "desktop" paradigm. If a familiar enough environment is created, the the user can come up with uses that the programmers probably never would have thought of. Someone earlier was mentioning overlapping logs to compare very specific bits of data. This can come more and more into play when dealing with multiple applications. Too lazy to pick out a color in some html code that you liked? Want to use it in Photoshop? Put the PS window over the Web Broswer and eyeball it. This, as I understand, is seen more in the Mac environment than in Windows (I dont use the Win too often, dont flame me if I get this wrong here...) But doesnt Windows (or the programmers for that matter ;-) put like a huge grey background behind all the Photoshop windows? And also I'm pretty sure all such windows have several pixel borders on them... But of course some of this is invalid since there isnt a released version of PS for OSX, but still. Also, the ability to organize windows independently of what application they belong too (unlike OS9)...

A lot of people may not like the OSX interface for some of its fancier bits (transparencies and such, which are becoming just as prevalent with XP and such) or some of its new strange functions (the dock) but the whole point of this is: create a really, really familiar metaphor and make sure to take it all the way - include all the little details. If you're going to pretend to have a "desk-top" things typically shouldn't have big borders or controls around them (not to mention coloring, thank God Apple included graphite in OSX...), or be limited in the order of the stacking. The more inconsistencies from the supposed metaphor that can be eliminated, the better. When something is consistent, if not with the entire metaphor, at least with itself... maybe just maybe the user will come up with uses unknown to you (especially between applications.)

Ok, youre all now cleared to pick away at any holes, inconsistencies or inaccuracies in my comment. ;-)

Tog is wrong

[mj6798]

Yes, in Tog's experiments, mousing is faster than keyboarding--in the specific population and with the specific applications Apple chose to test. Just read the description of the experiments to see how biased the experiments are.

User interface research is pseudo-scientific: it gives the appearance of being scientific, but it tells you almost nothing in most cases. When it does tell you something, it usually tells you something about the performance of "naive" user populations, because that's the kind of people a company like Apple is most interested in (once users are experienced, they are already stuck with a platform). It is very unfortunate that this kind of stuff gets published and that people then use it to make decisions.

maybe it's me???

[Pedrito]

I think this is really a matter of personal preference.

I don't want to say Microsoft is the "good guy", but at the same time, let's face it, they spent MILLIONS on usability testing. They continually do usability testing. For this reason, above any other, they dominate the desktop market.

I like KDE. It rocks, as Unix windowing environments go. Still, Microsoft is winning for one reason and one alone: Usability testing and usability satisfaction.

Sorry, but this post seems like a personal gripe against a usability feature that others have no problem with.

tiling has never disappeared

[mj6798]

GNU Emacs and XEmacs are using tiling for their windows, and they are one of the most widely-used user interfaces.

It's unfortunate that that paradigm hasn't caught on that much for independent graphical applications. I think the reason for that is that the Smalltalk paradigm of overlapping independent windows is very easy to implement, it's general, and it looks neat. Doing a good job at tiling window management is much harder. So, Macintosh, Windows, and X11 just followed the easy and flashy path.

Re:tiling has never disappeared

[scrytch]

GNU Emacs and XEmacs are using tiling for their windows, and they are one of the most widely-used user interfaces.

Widely used among programmers, sure. Waaaaaay different than users. Not to say that programmers don't deserve their own interface conventions, but they don't always map onto the needs of unskilled users.

And try using the menu items in Xemacs. You get popup dialogs. I have apropos windows and a few other informational windows pop up in their own frame as well.

Don't like Overlapping Windows

[Trepidity]

Maybe it's just that I have a 17" rather than 21" or whatever you crazy people have, but overlapping windows always seem to me to be a pain in the ass. You can never see enough information in each window if it's not maximized. So I keep everything maximized, and switch between windows with tabs or hotkeys (either in X or on Windows). Occasionally I have a need to have two windows on the screen at once, but this is very rare. Usually it's faster to keep them both maximized and switch between them (for example, just hit alt-tab in windows repeatedly to switch back and forth).

Re:Here's why the mainstays for Linux development

[johnjones]

yes X is sparse

thats because X was like that before MS even had a product called windows let alone 95

HP had what became motif when windows 1 came out so comapre motif to what windows 1 can do and then you can talk to me about this

learn some history

regards

john jones

Re:Here's why the mainstays for Linux development

[mgkimsal2]

I know the history - the person I was replying to was comparing his current desktop against an apparently stock Windows 95, not MS' latest (currently XP). love it or hate it, XP has more intricate graphics than earlier versions.

For someone who wants to get into theming their desktop, yeah, there are options in linux. however, a stock redhat install with KDE is pretty bland - you have to do some work to theme it as you want it. Someone who's going to take the time to do that can do that with litestep as well under windows.

Re:a new paradigm would be welcome

[hawkfan]

The overlapping window paradigm makes the user's desktop a mess.

Thats perfectly fine with me, my real desktop is a mess too and I wouldn't have it any other way.
When I'm done or want to pause work on something I leave it open and just put another window on top of it slightly offset. This only wastes virtual screen space when I pan over to the center of the new window.
Too much stuff? New workspace! Wouldn't you love to have that on your real desktop?
Having 5x21" displays with a slightly larger virtual resolution than physical helps too but I started this using 1 15" display a while back.
Now days big monitors aren't as expensive as you think if you're willing to muck around enough with old fixed frequency workstation monitors.

Sounds like Bars And Pipes on the Amiga

[uradu]

That program was very innovative for the time. It might have looked a bit toyish and more like a game because of all the pretty graphics, but it was quite powerful, especially considering the platform.

get yourself a copy of Smalltalk-80 (free)

[mj6798]

If you want to see what was available essentially in 1980, you can get yourself a copy of Squeak. Squeak contains a complete Smalltalk-80 environment with the original Smalltalk-80 user interface (I think there is also a Smalltalk-76 emulator inside it).

Apple's user interface improved on Smalltalk-80 by making it easier to learn (more user interface functions are represented by explicit graphical elements) and with its graphical design. But I have a hard time coming up with any area in which Apple improved on Smalltalk-80 in terms of functionality or usability for experienced users. Even today, I find the Smalltalk-80 interface better than what you get on the Macintosh. Furthermore, Smalltalk-80 came with a development and debugging environment that puts even the best C++ and Java environments available today to shame.

Like many other people who have been in the computer industry for more than two decades, we can't help but shake the feeling that innovation in software has basically stopped since the 1980's; most of the change that we have experienced has been to make things "bigger" and "faster", but very little seems to have gotten "better".

To all the people who are working on software like Gnome, Java, KDE, etc., my message is: do your homework first. Find and use some of the old user interfaces. There is way too much reinventing the wheel, mostly very poorly.

MDI apps are not compliant with KDE UI guidelines

[Nailer]

More significantly, it has shown up as an application workspace paradigm that improved previously crappy MDI implementations in programs like Visual Studio and KDevelop.

KDE, like Windows and MacOS, has user interface guidelines which strongly discourage MDI apps.

I'd post a snippet, but the Slashdot lameness filter is being...well, lame. Go to the URL above.

You're using silly arguments

[uradu]

No-one is arguing that using the mouse is ALWAYS faster, period, and let's do away with the kb. This is the Real World, and specialization is at work. For some things, some paradigms are more appropriate, for others, others (ugh). Keyboards will probably not be replaced for bulk text entry for many, many decades (regardless of what voice recognition freaks will tell you).

OTOH, control input is far less clear-cut. For example, moving files around directories will almost always be much faster using a GUI than a keyboard. Initial context setup takes some overhead (bringing up the source and destination folders), but after that, dragging files around with the mouse will beat the fastest touch typist every time, especially for longer file names.

Then again, this paradigm is poor for pattern selection. Moving random files around this way is faster, but moving all files containing the letters SSL will invariably be faster on the CLI.

The ideal is an intelligent blend of both, taking advantage of the strengths of each paradigm. People that always argue entirely in favor of one or the other in my view have a chip on the shoulder.

Incidentally, a good example of mixed paradigms are the custom input devices used in some high-end CAD shops. They include analog manipulators for adjusting on-screen objects, custom macro keys for performing frequent operations with ONE keystroke, as well as keypads and on-screen CLIs or pop-up text entry boxes for input that is most efficient using that paradigm. Sure, those workstations definitely take a while to learn, but pay back with huge gains in productivity. We are starting to see meek attempts at custom input devices with all the various Internet/Office etc keyboards around, but I'd say we haven't even reached the foot of this particular mountain.

Re:You're using silly arguments

[gorilla]

OTOH, control input is far less clear-cut. For example, moving files around directories will almost always be much faster using a GUI than a keyboard. Initial context setup takes some overhead (bringing up the source and destination folders), but after that, dragging files around with the mouse will beat the fastest touch typist every time, especially for longer file names.

Ignoring the biggest & hardest part doesn't exactly give a fair comparision. Using a modern shell with filename completion eliminates the 'longest filenames' worry, so basically you're comparing typing speed with the ability to select files from a GUI window, and IMO, generally typists will be able to select faster than GUI users, because they only need to type, while the GUI user has to read the filenames too. If you're going to select by criteria other than the filename, eg last modified time, then the command line user is ALWAYS going to win, because find . -mtime +1 -print is much easier to type than the GUI equivilants.

Re:You're using silly arguments

[uradu]

Well, there's no doubt which camp you're in then.

Re:a new paradigm would be welcome

[Rentar]

So where is the gain in 3d? As an alternative way of navigating workspaces it's merely 'cool'

I agree with you, but: Who of you wouldn use it (at least sometimes), just because of this beeing 'cool'? Well, maybe not every day, but a little eye-candy and some nice, useless 'cool'-ness is fine, every now and then.

Erm, do you mean ^R?

[Cardinal]

I may be misunderstanding what you're asking for, but bash has been completing my commands for me for years. ^R, start typing, it autocompletes from ~/.bash_history

I use it for the vast majority of the commands I type.

Re:a new paradigm would be welcome

[mypalmike]

> I dont believe it can be done. Not until we have real 3d displays with 3d input devices and probably not even then.

I work at an R&D center which has been developing exactly this technology, and it can be done because it has been done, using standard PC's and off the shelf graphics accelerators. The work I do is for military applications, and has not been publically released. However, you can imagine it as a game of Quake in which there is one room and a number of applications running in picture frames on the walls.

[We found that other groups are doing similar things, and our project is a bit like one at Microsoft. See Task Gallery for some interesting visuals]

In our project, we can run both Windows applications and remote applications via VNC (virtual network computing) as active applications on the walls. We have additional applications which are 3D in nature, like a globe of the Earth and a terrain viewer which sit on tables within the virtual space. Navigation is done much like in Quake, with keyboard and/or mouse movement moving the user within the virtual space. We have figured out effective methods of dealing with application focus and other UI issues typically encountered in the design of windowing systems.

My personal opinion is that such a 3D windowing user interface has benefits and drawbacks (no kidding, eh?). It has proven useful in military applications in virtualizing locations like command centers, which are 3-dimensional in nature. Military people who are not heavily into computers tend to be particularly receptive to a UI which resembles the physical operating environments they are accustomed to. I'm not sure that you'd want to (or need to) use a text editor in a 3D environment for long. In recognition of this fact, we provide a way of switching between visualization modes, bringing applications to the front as 2-dimensional displays and returning them to the wall surface they were on.

The spatial awareness issue you mention is actually one where I think 3D can be beneficial. For instance, given a virtual space which has distinct walls on which applications are running, it might be the case that you could locate a particular text document more efficiently than by trying to remember which of the emacs icons in the task bar represents which document. We are still researching such issues, and it is not yet clear how effective 3D space is at aiding visual memory for task completion.

-=-=-

My experience..

[Junta]

I like the conventional paradigm for seperate applications, but within applications I like support for both windowed and tabbed interfaces, but not managed from within the same app window unless it is tabbed. That way similar content is grouped together, and information can be layed out next to each other as needed. I would advocated either tiling windows or simply using maximized windows for tabbing, but then web pages and terminals and other application windows are all mixed up with no logical grouping whatsoever. Gnome panel and XPs taskbar at least, after a time, turns them into menus, but that isn't too much better. Tabbed web browsers (i.e. galeon) and multi-tabbed terminals are fantastic way to go :)

Genuine, scientific flaws in that argument

[Anonymous Brave Guy]

Your friends are laughing at you because, although using the keyboard "feels" faster, nonetheless you are wrong.

I've read a number of summaries by members of the Nielsen Norman Group, and am a regular reader of Jakob Nielsen's Usable IT web site. They often turn up valid points, and results that people initially find counter-intuitive. On the other hand, you have to be careful with usability studies. As with everything else in the scientific method, the results are only valid within the context they were obtained. Extrapolation to other circumstances is not valid.

In this case, for example, the articles date from around ten years ago. At that point, applications didn't have the same consistency of default user interface that they have today, nor the ability to for users to customise keyboard shortcuts, menus, toolbars and so on that is routine on Windows, MacOS, and so forth today. There have also been some improvements in mouse usability, such as a "shadow cursor" in editors that shows where the insertion point would go if the mouse were clicked, and wheel mice. It is unreasonable to assume that the same conclusions would apply today as ten years ago.

Moreover, look at the example situation presented. In a real editor, if I want to replace all of the '|'s in a paragraph with 'e's, I don't do it one-by-one. I select the paragraph, choose the search-and-replace command, put in '|' and 'e' and tell it to go. For the record, to do it by keyboard, I did the following.

1. Ctrl-Up
2. Shift-Ctrl-Down (paragraph now selected)
3. Ctrl-H (replace)
4. Type '|'
5. Press Tab
6. Type 'e'
7. Alt-A (replace all)

With the mouse, I did the following.

1. Reach for mouse, position hand
2. Move to middle of paragraph and triple-click (selects paragraph)
3. Move to Edit menu and click
4. Move to Replace option and click
5. Move to input field and click
6. Type '|'
7. Move to output field and click
8. Type 'e'
9. Move to Replace All button and click

I just ran each procedure ten times (one right after the other), against a clock. The keyboard version took me an average of 2 seconds, the mouse just under 5.

Note also that the above test used the most efficient interface for each case, as provided by default by my word processor without any UI customisation. In my experience, many rodent-loving users don't know about the triple-click to select a paragraph, though almost all keyboard-proficient users are aware of the Ctrl-H shortcut.

Now, I'm not arguing that the keyboard is always faster. For replacing one or two characters in a paragraph, I certainly do highlight with a mouse and overtype. For finding unfamiliar options on the menus or for scrolling text quickly, I use the mouse, too. But to claim that mousing is faster than keyboarding for general, everyday use is absurd, and contrived examples such as those presented don't strengthen the argument.

If you want more evidence, I suggest you go to Google and search for "mouse keyboard usability". Go past the articles on speech vs. mouse/keyboard interfaces and read the next twenty or so. The picture's pretty clear.

Ion is not a keyboardmouse innovation.

[Snafoo]

Okay, I just downloaded and installed Ion. While I appreciate its many keyboard shortcuts, I think the real power it possesses is the ability to all but eliminate unneccessary window-resizings.

Think about it. There are only two reasons people resize windows: (1) To focus on one particular task (window), or (2) to focus on more than one task/window, without eliminating the first focus. (The case where the user wants to switch between focuses or close the current focus in most windowing systems are handled by mechanisms like taskbars and close buttons. ). Most of the time users spend in 'focus adjustment' is simply futzing with the window borders in an attempt to maximize screen coverage while preventing overlap. Even 'timesaving' options like 'tile windows vertically' are usually wasteful, because, while they speed up the initial operation, the minute you attempt to make a small alteration to your focus (say, by making one window a little larger) you actually have to perform two or more tasks: Resizing the window under consideration and resizing its neighbours to concur with the new arrangement.

Since a framed-window system allows adjustment in a single motion, it saves time. (Although there are other window-management paradigms that acheive the same trick).

Personally, I really really like Ion -- I'm running it right now, and I have no intention of switching back to Oroborus any time soon (another very good window manager, IMO....)

use "screen" instead of a WM

[alan_d_post]

If you mostly use terminal apps, try using "screen" as your primary switch-between-programs environment.

I always have the same app running at a particular screen number, so switching never takes more than a second. Editor? ^]0 and I'm there. Email? Mutt is running at ^]1. News? See slrn at ^]5.

I've been using this type of setup for a year now, and it's great! I almost never interact with my WM at all, and have disabled all window decoration.

How do I make 2 large windows at the same time?

[DunbarTheInept]

(Sorry about that previous empty post - I'm using a new browser, one in which RETURN submits the form, when I'm used to one in which RETURN just moves down the the next widget.)

Anyway, How do you make two windows appear at theie full size at the same time when they both need more than 50% of the screen? Answer: Either you overlap them, or you can't do it period.

I see the value of a window manager that LETS me easily arrange windows in a tiled fashion. I do not see the value in one that FORCES me to do it for every single window.

Re:How do I make 2 large windows at the same time?

[DunbarTheInept]

Tabs don't do it right. They make it so I can't see *any* of the window at all unless I have it in front. That's no different than running with all windows maximized, and is annoying for all the same reasons.

The ideal window manager would have tiles, tabs, AND overlaps, and stop trying to cover up missing functionality by saying it is "out of date".

Why one or the other anyway?

[Anonymous Brave Guy]

This is definitely the direction of the future.

I can see where you're coming from here, but why do we need to have either overlapping or docked rectangular zones anyway?

I personally much prefer docked things on my screen from amongst the current options. My first action when loading most apps/documents is to hit "maximise". Then again, I hate debugging in Visual Studio when I've got five or six of these darned things open. Even on a 1280x1024 monitor, I still only get about 1" square of source code visible by the time I've displayed everything else I need. That is obviously the exception rather than the rule, though.

On the other hand, I think we can do much better than this today. Why are windows still forced to be rectangular? Why do we need all the absurd window dressing? Just look at the amount of wasted screen real estate you've got displayed right now. Chances are you have some sort of docked toolbars at the top of your browser, and some wasted space associated with them, for example. Consequently, several UI research labs are currently toying with non-rectangular windows as a way forward. Look at the borders, scroll bars, menu bars, title bars, and other assorted rubbish littering your screen. That's really got to go.

I think these are the next steps. The major problems with overlapping windows will largely disappear along the way. When I can just have a nice, white area for typing my letter, and have other UI pop up in a context-sensitive way when I need it, without all the clutter, then we'll be making progress. (Yes, yes, I know there are alredy nice UIs in research labs that do this sort of stuff, and funky gesture-based UI to boot. I'm talking mainstream...)

Vannevar Bush described window managers in 1945

[SimHacker]

Way back in 1945, Vannevar Bush wrote a prescient description of hypermedia browsers and window managers, that will inspire anyone designing user interfaces, especially web browsers and window managers.

His description of the "MEMEX" foretold of today's personal computers, and accurately predicted many specific features of modern window managers, web browsers and multimedia authoring tools. In 1945, Vannevar Bush clearly and accurately envisioned many useful and practical techniques to "support the massive task of making more accessible our bewildering store of knowledge". Many of his visions have been implemented in modern applications, but what he wrote points the way to other useful information management techniques that remain to be implemented.

-Don

http://www.theatlantic.com/unbound/flashbks/comput er/bushf.htm

As We May Think
By Vannevar Bush

As Director of the Office of Scientific Research and Development, Dr. Vannevar Bush has coordinated the activities of some six thousand leading American scientists in the application of science to warfare. In this significant article he holds up an incentive for scientists when the fighting has ceased. He urges that men of science should then turn to the massive task of making more accessible our bewildering store of knowledge. For years inventions have extended man's physical powers rather than the powers of his mind. Trip hammers that multiply the fists, microscopes that sharpen the eye, and engines of destruction and detection are new results, but not the end results, of modern science. Now, says Dr. Bush, instruments are at hand which, if properly developed, will give man access to and command over the inherited knowledge of the ages. The perfection of these pacific instruments should be the first objective of our scientists as they emerge from their war work. Like Emerson's famous address of 1837 on "The American Scholar," this paper by Dr. Bush calls for a new relationship between thinking man and the sum of our knowledge. --THE EDITOR

[...]

Science has provided the swiftest communication between individuals; it has provided a record of ideas and has enabled man to manipulate and to make extracts from that record so that knowledge evolves and endures throughout the life of a race rather than that of an individual.

There is a growing mountain of research. But there is increased evidence that we are being bogged down today as specialization extends. The investigator is staggered by the findings and conclusions of thousands of other workers -- conclusions which he cannot find time to grasp, much less to remember, as they appear. Yet specialization becomes increasingly necessary for progress, and the effort to bridge between disciplines is correspondingly superficial.

Professionally our methods of transmitting and reviewing the results of research are generations old and by now are totally inadequate for their purpose. If the aggregate time spent in writing scholarly works and in reading them could be evaluated, the ratio between these amounts of time might well be startling. Those who conscientiously attempt to keep abreast of current thought, even in restricted fields, by close and continuous reading might well shy away from an examination calculated to show how much of the previous month's efforts could be produced on call. Mendel's concept of the laws of genetics was lost to the world for a generation because his publication did not reach the few who were capable of grasping and extending it; and this sort of catastrophe is undoubtedly being repeated all about us, as truly significant attainments become lost in the mass of the inconsequential.

The difficulty seems to be, not so much that we publish unduly in view of the extent and variety of present day interests, but rather that publication has been extended far beyond our present ability to make real use of the record. The summation of human experience is being expanded at a prodigious rate, and the means we use for threading through the consequent maze to the momentarily important item is the same as was used in the days of square-rigged ships.

[...]

A new symbolism, probably positional, must apparently precede the reduction of mathematical transformations to machine processes. Then, on beyond the strict logic of the mathematician, lies the application of logic in everyday affairs. We may some day click off arguments on a machine with the same assurance that we now enter sales on a cash register. But the machine of logic will not look like a cash register, even of the streamlined model.

So much for the manipulation of ideas and their insertion into the record. Thus far we seem to be worse off than before -- for we can enormously extend the record; yet even in its present bulk we can hardly consult it. This is a much larger matter than merely the extraction of data for the purposes of scientific research; it involves the entire process by which man profits by his inheritance of acquired knowledge. The prime action of use is selection, and here we are halting indeed. There may be millions of fine thoughts, and the account of the experience on which they are based, all encased within stone walls of acceptable architectural form; but if the scholar can get at only one a week by diligent search, his syntheses are not likely to keep up with the current scene.

Selection, in this broad sense, is a stone adze in the hands of a cabinetmaker. Yet, in a narrow sense and in other areas, something has already been done mechanically on selection. The personnel officer of a factory drops a stack of a few thousand employee cards into a selecting machine, sets a code in accordance with an established convention, and produces in a short time a list of all employees who live in Trenton and know Spanish. Even such devices are much too slow when it comes, for example, to matching a set of fingerprints with one of five million on file. Selection devices of this sort will soon be speeded up from their present rate of reviewing data at a few hundred a minute. By the use of photocells and microfilm they will survey items at the rate of a thousand a second, and will print out duplicates of those selected.

This process, however, is simple selection: it proceeds by examining in turn every one of a large set of items, and by picking out those which have certain specified characteristics. There is another form of selection best illustrated by the automatic telephone exchange. You dial a number and the machine selects and connects just one of a million possible stations. It does not run over them all. It pays attention only to a class given by a first digit, then only to a subclass of this given by the second digit, and so on; and thus proceeds rapidly and almost unerringly to the selected station. It requires a few seconds to make the selection, although the process could be speeded up if increased speed were economically warranted. If necessary, it could be made extremely fast by substituting thermionic-tube switching for mechanical switching, so that the full selection could be made in one one-hundredth of a second. No one would wish to spend the money necessary to make this change in the telephone system, but the general idea is applicable elsewhere.

[...]

The real heart of the matter of selection, however, goes deeper than a lag in the adoption of mechanisms by libraries, or a lack of development of devices for their use. Our ineptitude in getting at the record is largely caused by the artificiality of systems of indexing. When data of any sort are placed in storage, they are filed alphabetically or numerically, and information is found (when it is) by tracing it down from subclass to subclass. It can be in only one place, unless duplicates are used; one has to have rules as to which path will locate it, and the rules are cumbersome. Having found one item, moreover, one has to emerge from the system and re-enter on a new path.

The human mind does not work that way. It operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain. It has other characteristics, of course; trails that are not frequently followed are prone to fade, items are not fully permanent, memory is transitory. Yet the speed of action, the intricacy of trails, the detail of mental pictures, is awe-inspiring beyond all else in nature.

Man cannot hope fully to duplicate this mental process artificially, but he certainly ought to be able to learn from it. In minor ways he may even improve, for his records have relative permanency. The first idea, however, to be drawn from the analogy concerns selection. Selection by association, rather than indexing, may yet be mechanized. One cannot hope thus to equal the speed and flexibility with which the mind follows an associative trail, but it should be possible to beat the mind decisively in regard to the permanence and clarity of the items resurrected from storage.

Consider a future device for individual use, which is a sort of mechanized private file and library. It needs a name, and, to coin one at random, "memex" will do. A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.

It consists of a desk, and while it can presumably be operated from a distance, it is primarily the piece of furniture at which he works. On the top are slanting translucent screens, on which material can be projected for convenient reading. There is a keyboard, and sets of buttons and levers. Otherwise it looks like an ordinary desk.

In one end is the stored material. The matter of bulk is well taken care of by improved microfilm. Only a small part of the interior of the memex is devoted to storage, the rest to mechanism. Yet if the user inserted 5000 pages of material a day it would take him hundreds of years to fill the repository, so he can be profligate and enter material freely.

Most of the memex contents are purchased on microfilm ready for insertion. Books of all sorts, pictures, current periodicals, newspapers, are thus obtained and dropped into place. Business correspondence takes the same path. And there is provision for direct entry. On the top of the memex is a transparent platen. On this are placed longhand notes, photographs, memoranda, all sorts of things. When one is in place, the depression of a lever causes it to be photographed onto the next blank space in a section of the memex film, dry photography being employed.

There is, of course, provision for consultation of the record by the usual scheme of indexing. If the user wishes to consult a certain book, he taps its code on the keyboard, and the title page of the book promptly appears before him, projected onto one of his viewing positions. Frequently-used codes are mnemonic, so that he seldom consults his code book; but when he does, a single tap of a key projects it for his use. Moreover, he has supplemental levers. On deflecting one of these levers to the right he runs through the book before him, each page in turn being projected at a speed which just allows a recognizing glance at each. If he deflects it further to the right, he steps through the book 10 pages at a time; still further at 100 pages at a time. Deflection to the left gives him the same control backwards.

A special button transfers him immediately to the first page of the index. Any given book of his library can thus be called up and consulted with far greater facility than if it were taken from a shelf. As he has several projection positions, he can leave one item in position while he calls up another. He can add marginal notes and comments, taking advantage of one possible type of dry photography, and it could even be arranged so that he can do this by a stylus scheme, such as is now employed in the telautograph seen in railroad waiting rooms, just as though he had the physical page before him.

All this is conventional, except for the projection forward of present-day mechanisms and gadgetry. It affords an immediate step, however, to associative indexing, the basic idea of which is a provision whereby any item may be caused at will to select immediately and automatically another. This is the essential feature of the memex. The process of tying two items together is the important thing.

When the user is building a trail, he names it, inserts the name in his code book, and taps it out on his keyboard. Before him are the two items to be joined, projected onto adjacent viewing positions. At the bottom of each there are a number of blank code spaces, and a pointer is set to indicate one of these on each item. The user taps a single key, and the items are permanently joined. In each code space appears the code word. Out of view, but also in the code space, is inserted a set of dots for photocell viewing; and on each item these dots by their positions designate the index number of the other item.

Thereafter, at any time, when one of these items is in view, the other can be instantly recalled merely by tapping a button below the corresponding code space. Moreover, when numerous items have been thus joined together to form a trail, they can be reviewed in turn, rapidly or slowly, by deflecting a lever like that used for turning the pages of a book. It is exactly as though the physical items had been gathered together from widely separated sources and bound together to form a new book. It is more than this, for any item can be joined into numerous trails.

The owner of the memex, let us say, is interested in the origin and properties of the bow and arrow. Specifically he is studying why the short Turkish bow was apparently superior to the English long bow in the skirmishes of the Crusades. He has dozens of possibly pertinent books and articles in his memex. First he runs through an encyclopedia, finds an interesting but sketchy article, leaves it projected. Next, in a history, he finds another pertinent item, and ties the two together. Thus he goes, building a trail of many items. Occasionally he inserts a comment of his own, either linking it into the main trail or joining it by a side trail to a particular item. When it becomes evident that the elastic properties of available materials had a great deal to do with the bow, he branches off on a side trail which takes him through textbooks on elasticity and tables of physical constants. He inserts a page of longhand analysis of his own. Thus he builds a trail of his interest through the maze of materials available to him.

And his trails do not fade. Several years later, his talk with a friend turns to the queer ways in which a people resist innovations, even of vital interest. He has an example, in the fact that the outraged Europeans still failed to adopt the Turkish bow. In fact he has a trail on it. A touch brings up the code book. Tapping a few keys projects the head of the trail. A lever runs through it at will, stopping at interesting items, going off on side excursions. It is an interesting trail, pertinent to the discussion. So he sets a reproducer in action, photographs the whole trail out, and passes it to his friend for insertion in his own memex, there to be linked into the more general trail.

Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified. The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities. The patent attorney has on call the millions of issued patents, with familiar trails to every point of his client's interest. The physician, puzzled by a patient's reactions, strikes the trail established in studying an earlier similar case, and runs rapidly through analogous case histories, with side references to the classics for the pertinent anatomy and histology. The chemist, struggling with the synthesis of an organic compound, has all the chemical literature before him in his laboratory, with trails following the analogies of compounds, and side trails to their physical and chemical behavior.

The historian, with a vast chronological account of a people, parallels it with a skip trail which stops only on the salient items, and can follow at any time contemporary trails which lead him all over civilization at a particular epoch. There is a new profession of trail blazers, those who find delight in the task of establishing useful trails through the enormous mass of the common record. The inheritance from the master becomes, not only his additions to the world's record, but for his disciples the entire scaffolding by which they were erected.

Thus science may implement the ways in which man produces, stores, and consults the record of the race. It might be striking to outline the instrumentalities of the future more spectacularly, rather than to stick closely to methods and elements now known and undergoing rapid development, as has been done here. Technical difficulties of all sorts have been ignored, certainly, but also ignored are means as yet unknown which may come any day to accelerate technical progress as violently as did the advent of the thermionic tube. In order that the picture may not be too commonplace, by reason of sticking to present-day patterns, it may be well to mention one such possibility, not to prophesy but merely to suggest, for prophecy based on extension of the known has substance, while prophecy founded on the unknown is only a doubly involved guess.

[...]

In the outside world, all forms of intelligence whether of sound or sight, have been reduced to the form of varying currents in an electric circuit in order that they may be transmitted. Inside the human frame exactly the same sort of process occurs. Must we always transform to mechanical movements in order to proceed from one electrical phenomenon to another? It is a suggestive thought, but it hardly warrants prediction without losing touch with reality and immediateness.

Presumably man's spirit should be elevated if he can better review his shady past and analyze more completely and objectively his present problems. He has built a civilization so complex that he needs to mechanize his records more fully if he is to push his experiment to its logical conclusion and not merely become bogged down part way there by overtaxing his limited memory. His excursions may be more enjoyable if he can reacquire the privilege of forgetting the manifold things he does not need to have immediately at hand, with some assurance that he can find them again if they prove important.

The applications of science have built man a well-supplied house, and are teaching him to live healthily therein. They have enabled him to throw masses of people against one another with cruel weapons. They may yet allow him truly to encompass the great record and to grow in the wisdom of race experience. He may perish in conflict before he learns to wield that record for his true good. Yet, in the application of science to the needs and desires of man, it would seem to be a singularly unfortunate stage at which to terminate the process, or to lose hope as to the outcome.

Copyright © 1945 by Vannevar Bush. All rights reserved.
The Atlantic Monthly; July, 1945; As We May Think; Volume 176, No. 1; pages 101-108.
http://www.theatlantic.com/unbound/flashbks/comput er/bushf.htm

Tastes Great, Less Filling!

[clheiny]

An alternate subject for this might be "Another Xerox GUI idea rises from the dustbin". Dunno how old Cliff is, but around 1982 the original Xerox Star/8000 desktop forced users to tile their documents (B&W on a 1024x768 display, if I recall correctly). General user community reaction was "Bleah!". Some folks liked it a lot, many didn't. The next software release included the option of choosing betweeen tiled and overlapped windows. [OK, the idea might not have been Xerox's originally, but it's the oldest one I'm acquainted with] Personally, I like to choose between the two models, and frequently find myself using a hybrid, with some windows tiled (whether in an MDI or within the wm) and some overlapping. Additionally, as I grow older, I find that even with a 21" 1600x1200 display, I require larger fonts. There are times when the amount of information required simply will not fit on a forced tiled screen, unless I make the font smaller and put my face right up next to the display. But basically, it's the old light beer question. Some people want one, some people want the other. Some people want both. As a side note, I must say that window managers that force the active window to the top of the stack of overlapped must die! Or at least be rewritten. I like my windows to stay where I put them, thank you.

Give vtwm a try..

[defile]

I never used to realize how constrained working with the desktop metaphor felt until I played with vtwm.

The big distinguishing feature of vtwm is how it implements virtual desktops. Unlike most virtual desktops in other UNIX window managers, this one can be of arbitrary size and you can scroll through it freely, instead of one chunk at a time.

I have vtwm set up so that the top 90% of the screen or so can be the "focused" area of the desktop, and the bottom 10% represents the entire virtual desktop, with boxes that represent where your windows are.

A blue box on the virtual desktop bar represents what the screen is currently focused on. You can either slide the blue box over to other windows, or pick windows up and move them into view.

You never feel cramped, and things like iconification are obviated. Simply move to a different part of the desktop if you need space. Also comes in very handy if you're at work and looking at porn and the boss comes by. Just click on the portion of the desktop that contains all of your busywork.

Here's a screenshot [if you see nothing but pitch black, scroll to the bottom right] to better illustrate my setup. The screen is right-center, and the gimp's toolbar is off further to the right off screen which is how I took the screenshot.

It's amazing how restricted I feel sitting at a windows box now, or with a window manager that doesn't support this. It's also great if you want to show how much of a badass you are, since with no windows open, the screen is entirely black, except for a thin white horizontal line at the bottom and a blue box beneath it.

Re:Give vtwm a try..

[scrytch]

Sun actually experimented with this setup a while back, using a giant virtual desktop, but with a twist: it would be shared among multiple users. You could use your "radar" or drag your view over to someone else's workspace and interact with their applications (this was explicitly for collaboration). They called it Kansas, and it was written in Self (god I wish they pushed Self instead of Java).

Re:Give vtwm a try..

[defile]

That's actually really interesting. I wonder why it never caught on.

I find overlapping just fine.

[mindstrm]

I mean, if the real estate is there, don't overlap, tile.

If the realestate isn't there, overlap, but offset. That's what virtual desktops are for.

I find one thing.. and I'm not picking on OS's here... but in windows, I find window management a pain in the ass. I find myself using the taskbar to flip between windows more often than not.
On unix desktops, I tend to have several things side-by-side or neatly arranged so I can see the data I need, the way I need it.
I've never analyzed why.. but it always seems less intuitive, or downright harder to do in windows.
It's probably due to a combination of different focus mechanisms and the types of applications run.. and I realize windows can be tweaked to have similar, if not the same, focus mechanisms.. but still.
As a general observation.. I find the typical KDE desktop a lot easier and more intuitive to work with than a windows desktop.

Secondly... a few things about windows that piss me off (that generally, though not always, only happen in Windows).
one is the popup dialog box that steals focus from whatever you are doing. That's a nono.
Stealing focus from the app it's related to.. that's one thing... but from unrelated apps.. it's a nono. Second is when one dialog box pops up and I cannot move the underlying windows. THAT is a nono.. I should be able to move any window on the screen at any time, period. I should be able to hide it, peg it, minimise it, shade it, whatever the WM wants.
That's probably another reason I find X a bit easier to work with.

can't you?

[Ender Ryan]

I can think of plenty. Say you absolutely need to be looking at 2 or more windows simultaneously, but they are all slightly too big to fit on the screen. So, you overlap them slightly, and now you can see what you need to see.

Top of screen is a bad idea

[Weezul]

First, the top of the screen will seriously mess up focus follows mouse. Second, pull-down menus will always be crap for efficency and top of the screen is generally going to be a pull-down.

Also, what level of experence was the article talking about. This critical piece of information seems suspiciously absent from the article. I think we know that an inexperenced user of a piece of software will find menus much more efficent, but very experenced use will find short-cuts more efficent (assuming the program is text oriented).

It is essentually inconcievable that a person who has used a keyboard short-cut 1000 times (long enough to learn it) could accomplish something quicker by removing their hand from the keyboard, place their hand on the mouse, selecting two distinct menu items (ala pull-down), and finally replacing their hand on the keyboard.. it's obsurd. Clearly, this situation could be reverse if the person was using a drawing program wich had all importent fuction out in the open (not it pull-downs), ala the Gimp.

Personally, I think you should just axe the pull-downs and click on the background to have a menu appear near your mouse. Placing menus on the top of the screen only solves the vertical position problem, but dose little for the horizontal, plus you have all the difficulty of "hitting the target" when you return your mouse to the application window afterwards.

Also, when the commands excede a serton level of complexity (i.e. use dialogs) then you should probably be interacting with them on a text based level, i.e. have a little mini-shellish programable subwindow, ala Autocad, Norton Commander, or Konqueror (execpt Konqueror's shell window is just bash, so you can not use it to browse the web). I mean lets face it when you have a dialog you probably have enough complexity that some users will want to script things.

Actually, one of the coolest ideas I have seen was to restrict the mouse to *only* cutting and pasting and then make the cutting and pasting efficent enough to simulate menus. The idea was the cutting and pasting is most of mouse use, so make it good at doing that one thing.

Baseless Macintosh Evangelism

[crucini]

I read the first two of your three links and gave up in disgust. Tog leans heavily on some "study", but for some reason does not provide a link. He claims that it takes two seconds to press a "command key" which is presumably any key that does not enter text.

I won't cite the fact that I don't take two seconds to press a "command key". Tog has already claimed that we are afflicted by micro-amnesia that suppresses this memory. Rather, I'll point to my observations of other people editing documents. When I watch an experienced user using vi, commands do not perceptibly interrupt the flow of keystrokes, except for the escape key which is inconveniently far from home row. As for "command keys" in GUI applications, I have no opinion. When the keyboard interface is viewed as a poor relative of the GUI (which is clearly how Tog views it) it may indeed be suboptimal.

Tog's advocacy is not convincing.

Corrections

[Animats]

Actually, Bill Atkinson had developed a way to handle "regions", arbitrary bounded areas. Mostly, regions were used to express the clip region for drawing partially obscured windows, but in theory there was support in QuickDraw for nonrectangular windows. This turned out not to be very useful.

The early history of the Mac has been rewritten somewhat to make Steve Jobs look good. The Lisa was the innovative machine, with a real multitasking OS, multiple windows, and a hard drive. It just cost too much to build in 1982. The Mac was supposed to be the cheap model, but original versions were too slow to be used seriously. (One floppy, no hard drive, 128K, remember.) The original Mac was actually a flop. It was the LaserWriter, the first reasonably cheap laser printer, that saved the Mac, by giving it something worth doing. Not until the Mac got a hard drive and more RAM, bringing it up almost to the Lisa hardware level, did it make money.

Obscure, but real, history. The original Motorola M68000 couldn't support virtual memory. Not only was there no MMU, backout from page faults wasn't handled properly. The M68010, which fixed this, came along late, and the MMU (a separate chip back then) for the 68K was years late. Horrible hardware hacks were used by UNIX workstation vendors of the era to support page faults. Even if you're not paging, UNIX needs backout from memory protection faults to support dynamic stack growth. Apollo used two CPUs, one for the OS and one for the applications; on a page fault, the application CPU froze and the OS CPU started, paged in the needed page, and restarted the application CPU. The Lisa used a special compiler which avoided using instructions that didn't back out properly on a 68000, such as ones involving memory references and register incrementation. This hurt performance. The Lisa also had an Apple-built MMU which was a whole board of parts. That made the machine too expensive.

If Motorola had had the MMU situation fixed by 1984, six years after first silicon for the 68000, history might have been different.

Mod the parent down

[AndroidCat]

More significantly, it has shown up as an application workspace paradigm that improved previously crappy MDI implementations in programs like Visual Studio and KDevelop.

The author has obviously not used Visual Studio in the last few years. Tiles, stacks, whatever you want. Microsoft changed direction on MDI back in 1996 or so.

Ahead of the curve?

[crucini]

So Apple is "ahead of the curve" by being the first to abandon the technique that they developed the Mac specifically for? I'm I the only one who thinks this sounds like crazy talk?

Well if they claimed to be travelling in a straight line it might seem odd that they are revisiting the past. But since we are talking about curves, we should not be surprised to arc back towards the origin. When you've turned a knob from 0 to 10 in the name of "innovation", I guess the next move is to turn it back towards 0, again in the name of "innovation." Maybe Apple and Microsoft are grimacing plastic clown faces bolted to a merry-go-round. They are perpetually rushing into the future, but don't be surprised to see them in the same place later.

Re:acme/wily and Pike's 8.5 window system and Blit

[billstewart]

I first saw an early version of Acme when Rob Pike was giving a Plan 9 talk at Usenix (maybe Nashville? Maybe ~1990?)(Since Plan 9 uses Unicode, that's really 8 1/2 with a genuine 1/2 character...) I wasn't impressed so much with Acme, but Pike was mainly talking about it in the context that he'd tried to develop something that was much different from his previous Blit terminal window system, which was a pleasantly fast overlapping-windows system on a 68000 box. What really impressed me was the speed of the window system startup - he typed 81/2, hit return, and the window system was up and running in about the time it would take for a $ prompt to show up. His description of the environment was "Ken and I have spent 10 years studying things that window systems shouldn't do and we wrote one that doesn't do them." A bit ugly, but blazingly fast and lightweight. The window system was written in about 64KB of code; he compiled it during the talk (took a few seconds on the 680x0 Next hardware, and he commented that it was much faster on the Murray Hill Plan 9 CPU server cluster.)

The wheel doesn't get any more round...

[Jace of Fuse!]

Lately, I have been pleased to see an increase in 'framing,' 'docking,' 'stacking,' and 'tabbing' being used, starting most conspicuously with frames in the web.

I might be the only one who thinks so, but framing, docking, and stacking annoy me. Tabbing isn't so bad- -certainly no worse than simply having multiple screens (as the Amiga did, and as XWindows does... and apparently, now XP.) Frames are simply straight out.

The fact is -- cascading windows, slamming a window into the corner of the screen, and basically DECIDING FOR ME where a Window should go is the LAST THING I want a desktop doing for me. It's also the biggest reason I absolutely fscking HATE most Unix desktops.

The Mac, Windows, and even ancient old Amiga Workbench were really good about putting Windows where you wanted them (though on the Amiga you had to snapshot them) and not trying to dictate where they belonged for you.

Stacking Windows, Docking them, and dynamically resizing them without the users permission isn't elegant, it isn't convinient, and it's nothing but plain annoying. I don't believe these are features that any GUI even needs to begin with, but if they're going to exist they should be purely optional, with windows "Remembering" their positions and honoring the user's placement.

After all -- if I want 4 of my most recently opened windows in the four opposite corners of my screen, wouldn't I put them there myself?

Under Windows, my ICQ is always in the same spot (the left), my AIM is always in the same spot (the right), and my IE is not full screen and is positioned neatly near the middle of my 1280x960 display (on a 19" monitor). These windows and many others almost never get repositioned. They stay where I put them.

When I'm using my BSD box, and working in KDE -- I easily get rather annoyed that Windows just kind of pop up where they want to with no regards to what I want as a user.

So on the whole -- I can honestly say I don't agree with this as "progress" as the poster seems to see things -- to me I see it as some wise-ass people trying to push the envelope well beyond what is actually needed and changing things just for the sake of change. It is possible to ruin a good thing by trying to fix it when it isn't broken.

I wish people hell bent on GUI design would realize that maybe, just maybe, there really IS nothing wrong with some of the most basic concepts.

The wheel doesn't get any more round, after all.

Re:The wheel doesn't get any more round...

[greenfly]

That's one of the main things that has turned me off about KDE's window manager -- no well-defined window memory. That's also one of the main things that keeps me coming back to enlightenment. There are just certain windows I always want to open a certain size, on a certain desktop, in a certain place. Some of these windows I want to be always sticky, some it doesn't matter. With enlightenment I can always define exactly where I want a window to go.

Some window managers get it half right, they let you remember *all* of the settings. But sometimes I want a window to open in a certain desktop, but not always at the same size, or vice versa.

And of course, being able to group certain windows together, and have them all iconify or shade together is nice too. Seems to me if you really wanted to, you could get all this functionality ion has to offer in E, just by doing some window memory.

Combine them?

[SCHecklerX]

I just took a look at the ION desktop quoted in the article. That does look really cool. But having the desktop space hardwired seems kind of dumb.

Why not combine multi-function windows with the current free-floating "paradigm?" Best of both worlds. I could make this window contain this program, that program, and the other one, and this other window be this thing, and this other window be thing 3 and thing 4.

Is this not obvious to anybody else who looked at the ion screen shots?

Xerox' windows didn't overlap ...

[gig]

That Xerox link is a lousy example of the origins and history of overlapping windows, considering that the Alto didn't have overlapping windows. The Alto just divided the screen into side-by-side regions, same as Windows 2.0 did about 10 years later.

Well said

[SCHecklerX]

The cad example is beautiful. I remember using autocad, and the ability to combine commands with the pointer was very powerful and flexible indeed.

For a desktop that merges commands with gui for file operations very nicely, take a look at Rox Filer

3d

[SCHecklerX]

Can be useful.

But only with multiple screens, or a good projector (which doesn't yet exist).

It would be great if instead of having to flip between virtual desktops in windowmaker if I could have, say, 3...one on the monitor in front of me, and one on each side. The side monitors would be touchscreens, and upon touching one of the open things, it would move over to my 'front' desktop. That would be very cool and useful, as I could monitor EVERYTHING without having to have it all on my front screen.

Re:a new paradigm would be welcome

[Znork]

Well, of course there are several applications where you have an advantage if you use 3d. CAD and modelling are traditional examples, military visualization would be another I suppose.

The Microsoft example has an interesting look, altho the idea has been floated before. However, I fail to see the advantage of 3d in it as opposed to an ordinary UNIX desktop pager with the usual miniature actively updated windows and the possibility of labeling the workspaces. Both seem to serve the exact same purpose apart from one being 3d and one being 2d. Switching and monitoring tasks and arranging virtual workspaces that are, together, larger than the available screen space. Am I missing something?

Modeless vs Modal Interface

[Jeremy Erwin]

A Modal interface is an interface in which the program has to enter a specific state for certain commands to be usable. e.g. vi has a editing mode, and a paging mode, and a deletion mode.

The original philosophy behind modeless interfaces is that the questions "how do I get out of this" and "how do I get back to the original screen" were to be avoided.

The current control panel application (in OSX) is actually very similar to the pre 7.0 control panel-- one selected a control panel to work on, and the relevant controls appeared on screen. (Post OS 7.0, the control panel was simply a folder, and opening a control panel opened up a new window)

It's my impression though, that single window design does present problems. I never much liked the panes in "Project Builder."

1 window is enough for many users

[n-baxley]

Mnay of the users I support still feel the need to close one program before starting another. The concept of multiple programs running at the same time in different windows just blows their minds.

Re:Sounds like Your Don't Know How to Use It

[uradu]

>> That program was very innovative for the time.
> Was? AudioMulch [audiomulch.com] has yet to reach version 1.0

I was talking about "Bars and Pipes" on the Amiga.

Re:Closure principle will keep windows around

[vidarh]

That argument doesn't hold. Tiled windows work just as well with "how our brains work". As do full screen presentation. As do three dimensional user interfaces.

The issue isn't which method is easily understood, but whether there are other easily understood mechanisms for presenting data on screen that are more convenient to operate.

Flaws in Tog's reasoning

[BinxBolling]

I see a few flaws in Tog's reasoning:

First, Tog doesn't consider RSI at all - personally, I and a lot of others find that the mouse is a far bigger culprit than the keyboard when it comes to wrist pains.

Second, Tog suggests that because using the mouse is a relatively low-level, "physical" task, and that therefore, using the mouse permits people to avoid pausing the high-level cognitive functions related to whatever they're actually trying to accomplish. I don't buy this -- high-level cognitition and low-level motor control can't always coexist nicely, unless the low-level task is one you've trained very thorougly to serve a particular high-level process (e.g. touch-typing). Read up on why mobile phones cause car accidents, even in hands-free mode.

Finally, he suggests that mousing "feels" slower and that people are mouse-averse because mousing is boring. But I see no reason to accept his underlying assumption that "slow" is worse than "boring". If I'm a data entry clerk or word processor whose productivity is dependant primarily on speed of input, that might be true. But input speed isn't the bottleneck for all computer use -- and maybe not even most. It used to take me around 8-12 hours to write an essay for a literature class. Maybe a quarter of that time is spent actually interacting with the computer, rather than sitting back in my chair, looking over my notes, and thinking about what I wanted to say.

(Side note on "slow" vs. "boring": When I'm driving, I'll happily take a somewhat longer route that allows me to keep moving steadily over one that requires me to sit in traffic, even if the latter would get me to a destination sooner.)

(Side note 2: I'm not necessarily accepting the "slow" vs. "boring" trade-off that Tog poses. Considering the lack of citations, I see no reason to accept his assertions about what the research shows. Combine the lack of cites with Tog's tone of condescension and bluster, and I think that while the emperor may not be naked, he's certainly showing a lot of skin.)