The Waning of the Overlapping Window Paradigm? 535
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?"
space (Score:3, Insightful)
Re:space (Score:2)
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 (Score:2, Interesting)
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 (Score:2, Interesting)
Re: (Score:2)
Re:space (Score:3, Interesting)
Finally..... (Score:4, Funny)
Re:Finally..... (Score:2)
Interesting Keyboard/Mouse Combo [slashdot.org]
Re:Finally..... (Score:4, Insightful)
Your friends are laughing at you because, although using the keyboard "feels" faster, nonetheless you [asktog.com] are [asktog.com] wrong. [asktog.com]
Re:Finally..... (Score:2, Insightful)
Re:Finally..... (Score:2)
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..... (Score:5, Insightful)
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..... (Score:3, Insightful)
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..... (Score:3, Interesting)
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....
That's ridiculous. (Score:3, Insightful)
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.
Re:Finally..... (Score:2)
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.
Why keyboard beats mouse for text editing (Score:5, Interesting)
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:Finally..... (Score:2)
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..... (Score:2)
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..... (Score:3, Interesting)
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..... (Score:2, Interesting)
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..... (Score:3, Insightful)
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.
Maybe I'm just stubborn (Score:5, Insightful)
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 (Score:3, Informative)
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 (Score:5, Interesting)
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 (Score:5, Informative)
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 (Score:2)
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.
OS X (Score:2)
Re:OS X (Score:2)
I'm I the only one who thinks this sounds like crazy talk?
-Peter
alpha channel... (Score:2, Interesting)
Re:alpha channel... (Score:2)
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... (Score:2, Interesting)
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 [daishar.com] 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 [daishar.com] of the PuTTY [greenend.org.uk] 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 [microsoft.com]. Layered windows also go well with XP Visual Styles [microsoft.com], so if you write win32 code, make sure you leverage side-by-side Common [microsoft.com] Controls [microsoft.com] to keep everybody happy.
Re:alpha channel... (Score:2, Funny)
No shit brother. I like seeing what's behind my monitor without having to lean to one side or stand up...
Re:alpha channel... (Score:2)
If you want to do this, add the line
Option "XkbOptions" "ctrl:swapcaps"
to the keyboard inputdevice section of your XF86Config.
Ick! (Score:2, Informative)
Re:Ick! (Score:2)
Interesting (Score:2)
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 (Score:2)
Xerox did not have it (Score:5, Interesting)
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 (Score:5, Informative)
Then you believe wrong.
I personally used Xerox [spies.com] 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.
get yourself a copy of Smalltalk-80 (free) (Score:3, Informative)
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.
Windows Solutions (Score:2, Informative)
GNOME, KDE, CDE, etc... (Score:3, Insightful)
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 (Score:3, Insightful)
Steve
Re:No (Score:2)
Re:No (Score:2)
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 (Score:2)
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... (Score:4, Insightful)
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... (Score:2)
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... (Score:3, Informative)
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 (Score:3, Interesting)
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 (Score:2, Funny)
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
"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 (Score:3, Insightful)
Remember that the Xerox movable overlapping windows paradigm appeared at a time when tiled and framed paradigms were widespread (Symbolics [uni-hamburg.de], TI Explorer [uni-hamburg.de], 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
Yes.. if optional.. (Score:2)
It has to prove itself. (Score:2, Interesting)
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
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.
acme/wily (Score:2, Interesting)
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.
We aren't too far from these ideas already. (Score:3, Interesting)
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.
Re:Show us your .sawfish key-bindings! (Score:2)
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:
Then I made an
xmodmap -e "keycode 66 = Caps_Lock"
xmodmap
Then I made an
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
(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
Glad this is happening (Score:2)
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... (Score:2, Funny)
-EclipsE
Re:If it's good enough for Geordi... (Score:2)
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.
Evolution towards less windows (Score:3, Interesting)
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... (Score:2, Funny)
PicoGUI! (Score:2)
We already have options in many ways, like mo (Score:3, Interesting)
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 [sourceforge.net] 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 [slashdot.org] or Adequacy [adequacy.org], 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 [mozdev.org] to your sidebar. Throw in a few more apps from MozDev.org [slashdot.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 [hrome] for appliances called OEone [oeone.com]. You can check out the screenshots of their calender application here [oeone.com].
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... (Score:2, Interesting)
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. (Score:2)
a step backwards? (Score:2, Insightful)
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.
Simplistic Desktops (Score:2)
Tabs work great unless you want to see two things at once.
Good thread (Score:2, Informative)
some more info (Score:2, Informative)
How to get a sort of tabbed interface with FVWM2 (Score:2, Interesting)
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 (Score:3, Informative)
Hooray (Score:2, Funny)
Overlapping windows are here to stay... (Score:3, Insightful)
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.
Until I read you're question... (Score:2)
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 (Score:5, Interesting)
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.
MS-Windows 1.0 tiled? (Score:3, Interesting)
avoid Apple patents by reverting to a Xerox look.
No one really bought Windows until version 3.1
and MS Office requiring it.
Cognitive limits, etc. (Score:2, Interesting)
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). [asktog.com]
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.
tabbed windows save time (Score:2, Informative)
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 (Score:3, Insightful)
Ion is not a keyboardmouse innovation. (Score:3, Interesting)
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 (Score:3, Interesting)
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.
Tastes Great, Less Filling! (Score:3, Informative)
Give vtwm a try.. (Score:3, Informative)
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 [bacarella.com] [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.
I find overlapping just fine. (Score:5, Insightful)
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.
No - but maybe a mix of the two (Score:3, Insightful)
Re:No - but maybe a mix of the two (Score:2)
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 (Score:2)
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.
Re:Here's why the mainstays for Linux development (Score:3, Insightful)
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.
Re:Here's why the mainstays for Linux development (Score:2)
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 [tapinternet.com]. 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).
Re:Here's why the mainstays for Linux development (Score:2)
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.
Re:Here's why the mainstays for Linux development (Score:2)
Re:a new paradigm would be welcome (Score:4, Insightful)
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.
Re:a new paradigm would be welcome (Score:2)
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:a new paradigm would be welcome (Score:2)
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.
AfterStep and workspaces (Score:2)
.
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.
Re:Oberon (Score:2)
Oh, Niklas Wirth, where are you when we need you?
Re:No accounting for taste... (Score:2)
I switch windows all the time using the alt-tab combination. What am I missing here?
Re:Docking behavior never the right thing (Score:2, Insightful)
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.