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

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

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.

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.