Arranging multiple windows on a screen isn’t that great on Windows due to is lack of docking support, like Winamp provides.
I hate Thunderbird for displaying the filename whenever I drag a file from Eclipse into an email (instead of adding an attachment).
I always use maximized windows.
I use ratpoison for 5+ years and the only case when I use tiled windows, is if I need to type into editor something from a non-OCR-ed PDF (that happened once or twice). I switch between applications with keyboard.
Almost the same environment can be created on windows: maximize windows, assign a short-cut to each application you use and switch between them using the keyboard.
There is no problem with too many characters on a single line – I simply enlarge the font until I have 70 characters or so.
I’ve had a lot of debates about this, and every one of them seems to come down to which style of usage the user learned first.
I learned on a mac, so I like being able to easily and reasonable stick windows next to each other with a slight overlap. I feel… enclosed whenever I work in VS.net (which I do every day at work) if it isn’t in full screen mode, so using windows really becomes one big tabbed interface of a bunch of maximized pages that you switch through linearly. It works fine when you’re only working on one thing… but it gets really annoying when I’m trying to read something off of a website and code at the same time.
The mac approach worked ok before (mostly because people were used to it - there are all sorts of little things you did in the old Mac OS that you didn’t realize, like automatically closing windows after you so you didn’t get too much clutter). But the current approach with expose is incredibly superior. You just don’t worry about where things are. You toss it where you want, at the size you need to actually see the content, and when you want something else, flip grab, it’s there, and you can still see your last window’s content to keep reading the tutorial while you code.
It is painful to try to work between more than two windows at once in windows. And it is incredibly painful to code in even two windows.
Having things maximized removes the sense of what else you have open, what other information you’re working with. If you work with a single app all day (or even really an editor and a web browser that is mostly for goofing off during compiles) there’s no problem. If you try to get any of those apps to interact… it’s a disorienting mess.
And drag and drop is a nasty interface… in windows, because it doesn’t really support it.
Tell me, which is an easier way to force a jpeg to open in photoshop instead of your quick viewer/editor - right click, open with (if it recognizes the type) search through a long list, find photoshop, uncheck “always use this app”, click ok. OR grab the file and drop it onto either your open instance of photoshop, or the shortcut to it that you keep on your dock.
Similarly, any sort of cut and paste method of moving files around is a completely bastardized, horrible interface (imo) 
Complex drags are a pain. A simple drag to a known and currently visible location is a fairly easy operation.
For what it’s worth, I’ve found using “multiple desktops” to be quite useful (since I don’t have enough money to get a second monitor). Linux (KDE specifically) has had this feature for as long as I can remember, but I only recently found a program (that doesn’t suck) to do the same thing in Windows.
Check out Dexpot:
http://www.dexpot.de/
I mapped my 4 “virtual desktops” to the Windows-{Z,W,C,V} keys.
I usually keep my email browser windows open on desktop 1.
I usually put always-open stuff (like Winamp and AIM etc) on desktop 4.
Then I can be working on 2 things at once on desktops 2 and 3, and it’s much easier to just reach down and hit Windows-{W,C} to switch instead of spending time futzing with the window layout.
Normally when I work I have a boatload of Explorer windows open, and this lets me keep them separated (only programs that are running on the current virtual desktop are shown in the taskbar).
Anyway, that’s my $0.02. Hope it helps someone!
-Matt
“But I also think windows with a fixed layout shouldn’t be resizable in the first place.”
Then you’ve never used XP with large print for any length of time.
Not being able to resize a window because the large print won’t fit inside is idiocy. Whose (Microsoft’s or the designer of said window), I don’t know. It has happened to me on far too many occasions. A classic
case is when the buttons are off the bottom of the screen. And you can only move an XP window around with its top border…
Good. There are Visual Studio users out there. We have a reference point.
So, picture this: I open all my header files, and then drag their corners until they are pseudo-minimized. That means that I manually size them as small as I can, but I can still read the whole filename in the titlebar. That would be about 20 pixels tall or so, and let’s say 250px wide.
Let’s imagine I have ten of them, in the upper left hand corner, arranged like:
Header 1.h
Header 2.h
Header 3.h
etc.
Now, next to each one, I arrange the corresponding .cpp file, like so:
Header 1.h Source 1.cpp
Header 2.h Source 2.cpp
Over on the far right, I have a similar stack of, ohh, how about utility files, like Util1.h Util2.h, and the corresponding cpp files.
Elsewhere on my Visual Studio workspace, I have various test files, output files that I have opened, code snippets that I have waiting to insert in my code. Maybe a bunch of C# files that I am porting over to CPP (don’t ask me why)
The entire workspace is now “arranged”. There may be 50 files opened. They are all perfectly aligned with other corresponding files. In an instant, I can see the scope of my entire project. I get the BIG picture of how everything fits together. I see the relationships. Other benefits: I can search across all open windows, I can compare code side by side, I can do fast cut and paste, I can find stuff, I can jump back and forth from one window to another at lightspeed, etc.
There are those that like the tabbed dialog interface. That works for ten or twelve files, and breaks down in uselessness past about 20 files, because you can’t read the title on the tab anymore.
Visual Studio thus becomes more then an editor/compiler. It becomes a project/file manager, a beast of infinitly greater power and usefulness.
Now, suppose the actual operating system itself (be it Mac, or Windows, or Linux, or whatever) only supported tabs. You could NEVER have more then one window open at a time.
Well, that would only be a marginal improvement over DOS.
You see, the whole point of a multitasking, multi-UI OS is precisely the fact that you can have overlapping windows. The user is given the CHOICE as to how they want to arrange their “desktop”.
The Windows platform-desktop look and feel allows the end user the greatest freedom of expression in how they wish to customize their work/play/create environment. Tabs alone are very limiting. You can’t get enough tabs up to do much.
An average dev session for me involves having several file managers open, two or three Visual Studios open, a dozen web browser windows (researching things), email, Word For Windows, a calculator… in short, a whole bunch of UI surfaces. I park them where I want, where I know they are, where I can get to them quickly. It’s a beautiful thing - a customizable, high speed, graphically rich environment, where I am the total boss.
There is no substitute for this powerful environment. And it is coming to the web, for all of the same reasons.
You have to realize, the tabbed thing… is just a stopgap measure. Of course, it will continue to be supported, because people want choice. The mere fact that tab technology came out after MDI technology does, in no way shape or form, mean that tabs are better, or preferred, or that MDI is becoming obselete. Quite the contrary - they are two complementary mechanisms.
@hachu: just as tabs allow one to group like with like, the MDI paradigm goes a step farther, allowing one to create little “zones” of windows, that are physically seperated from other “zones”. Once again, more choice.
The MDI interface is the most sophisticated and powerful interface ever developed, and it will not be dethroned by a bunch of rigid tabs.
Imagine: you walk into the library to research “USB Technology”. You get an armfull of books and magazines, and walk to a desk. As you sit down, the librarian comes up and says, “Uh, excuse me, but you can only have one reference material at your desk at a time.” You say, “Huh?” The librarian says, “It’s the rules - here, I’ll just take those other books from you, and put them over here on MY desk.” Reluctantly, you hand her the books, thinking, "This is really weird…"
So, you sit down, and dig through the one book you have, and you find a reference to a magazine article. You think, "Hey, that article is in one of the magazines I picked up. So, you walk over to the librarian’s desk, and reach for the magazine. “I’m sorry”, she exclaims, as she raps your knuckles with a ruler. “I thought I explained to you about the rules. Now, you bring me the book on your desk, and I’ll give you this magazine.”
I could go on with the example, but you get the point. That would be a rediculous excuse for a library, and you would never go back. However, you want that for your web browser interface. Hmmmm. Really? You mean you are willing to settle for only seeing one page at a time? You mean you see no utility in being able to arrange partially opened pages side by side, scrolled and positioned so that the relevant contents of both pages can be simultaneously compared? Hmmmm.
When I go to the library, I want AAAAALLLLLLLLL the books on my desk. When I hit a website, I want to be able to open multiple content streams within the same website. I do NOT want to be forced to open multiple browsers, and then position the browsers on the DESKTOP, where they compete with all the other desktop windows. No. I want to be able to position the windows offered by a website, WITHIN THAT WEBSITE.
Anything less is just DOS on the web.
Y’all get ready. The wave is coming.
Norzilla
Telos:
If your 20x20 square is at the top-left of your screen and you “flick” your mouse up and to the left, you will hit it. When the mouse hits the “top” of the screen it continues to move left.
See the Wikipedia article. Generally, that’s not suitable “proof”, but it does summarize the essentialy UI design community’s view of the issue:
“Edges (e.g. the menubar in Mac OS) and corners of the computer display (e.g. “Start” button in Windows XP) are particularly easy to acquire because the pointer remains at the screen edge regardless of how much further the mouse is moved, thus can be considered as having infinite width.”
If you’d ever used an old-style roller-ball mouse (which tended to get filled with gunk and jerky) you’d definitely appreciate the difference between trying to hit something in the middle of the screen and hitting something off to the edge or in a corner.
MDI applications? Isn’t the tabbed browser approach of Firefox and IE7 akin to that?
@Tom Dibble: So if it’s in the corner you win, if not there’s no reasonable difference in targetting but it’s further away.
As for the old-style roller ball mice… well, I’d just learn the keyboard commands. 
Norzilla:
In your “library” example as embodied in a tabbed browser:
In the rare occasion where you want to see both items at the same time (ie, side by side), you drag the “tab” out, let it become it’s own window, and continue working. If you later change your mind, drag the tab back in to the first window and all is as it was.
I think a lot of what you are talking about is actually better accomplished using multiple desktops (or OS X “Spaces”). You put the reference books in one space, along with the reference magazines (books and magazines are different, and so embody different “applications” in the metaphor), on one desktop, while the other desktop holds your pleasure reading and yet another holds that email you don’t want to think about yet.
When you start working on “projects” which employ multiple windows, often those windows are handled by different applications. So, here, while MDI will “block out” the rest of the apps on the system, it won’t give you a “desktop” per project.
To any who want Windows-style Maximize on your Mac, here’s an Applescript to do it (on a developer website I won’t go through how to put this into your Scripts folder and bind it to a Quicksilver trigger…).
Note that it’s a bit clunky, as it sets the size of the window to a specific value instead of looking up the “display size” and using that. I’ll leave that particular bit of wizardry as an exercise for the reader. Also, note that "(0,0) is the top/left of the primary monitor; monitors to the left will have negative positions and monitors to the right will have positions larger than the primary display’s screen size.
tell application "System Events"
if UI elements enabled then
set FrontApplication to (get name of every process whose frontmost is true) as string
tell process FrontApplication
tell front window
set position to {0, 0}
set size to {1023, 767}
end tell
end tell
else
display dialog "You must turn on UI Scripting in System Preferences!"
end if
end tell
I’m sorry, but I just don’t buy the ‘multiple books open on a table in a library’ metaphor a couple of posters have used.
If you’re focusing on one book the rest on the table are just as useful to you wither or not they’re opened or closed. I guess it’s really a matter of preference, but I’m less distracted when I only have the book I’m reading open.
The Windows UI allows you to keep the other applications (books, if you will) ‘closed’ but also at_your_reach in the toolbar at the bottom of the UI. You’re not prevented from being able to quickly switch from one application to another - no one is only letting you read one book at a time while they hold the rest at their desk. That would be like Windows forcing you to quit one application before you can open another - which it doesn’t do.
Moreover, you can minimize all of your application windows to create the same multi-window effect that OSX employs in Windows. Snapping them back to fill the screen with a single click is much easier than resizing via dragging the window.
Telos:
“So if it’s in the corner you win, if not there’s no reasonable difference in targetting but it’s further away.”
No, on the edge you still (generally) win. Although, the further away from the edge you are the larger the target needs to be for the same accuracy. Still, a 20x20 on the edge compared to a 20x20 in the middle of the screen (but not already under the mouse cursor) will still generally be easier to hit, as you have to target only one direction (horizontally in the case of a menu bar).
Again, Fitt’s Law is very well defined and understood here. You might wish to disagree with it, but claiming that it doesn’t state that edge/corners are relatively easy to hit is incorrect.
Users don’t want to deal with the mental overhead of juggling multiple windows, and I can’t blame them: neither do I.
Neither do I. I want my window manager to juggle multiple windows for me.
I don’t like to juggle multiple windows. Thats why my window manager does it for me.
http://www.suckless.org/wiki/wmii
I believe the OLPC project is based on something similar.
Fitt’s Law says acquiring the target is a function of distance and size. Putting it on the edge is putting it further away, and doesn’t change the size.
Fitt’s Law does not say it is easier to hit that target. You are only showing that you cannot overshoot the target, but you can still undershoot, go wide right or pull a Norwood (Buffalonian’s will understand.)
So you have a slight advantage in “virtual size” but you still need to show that it makes up for being further away.
Hi Jeff. A while back, as I recall, the Dreamweaver and Fireworks studios from Macromedia used multi-window interfaces. However, I’m uncertain as to whether they have carried forward this practice into the newer versions of their software.
“This is a textbook example of how Microsoft’s programmers got the original Mac GUI wrong when they copied it for Win 3.1, and never bothered to fix it: there’s no zoom button on Mac OS windows because it’s unnecessary. What you’re mistaking for a “maximize” button is actually a “snap window to size of contents” button. Far more useful and elegant. Once again, Microsoft has no taste and no clue when it comes to the GUI. All that money and Gates has never been able to hire a decent human factors person.” - Alex Chamberlain
Here’s Mac in a nutshell, forcing users into their paradigm instead of giving them choices. I can think of instances where maximizing to the content is useless (drawing applications, anyone?) and ones where it would be useful. You know what would be innovative? Giving BOTH buttons. People like to do things in different ways, they should not be forced into some conceptually flawed design just because a few elite users think it’s better. All that money and apple has never been able to hire a decent human factors person.
“Can you name one application with a multiple window interface that’s even popular?” - Jeff Atwood
Visual Studio?
Thanks for your thoughts on this issue. I never understood why Macs do this either. But then again, I don’t understand the logic behind the vast majority of Macs oddities. Like not being able to set an MP3 as your ringtone on the iPhone. WTF are they thinking?!
And (“Can you name one application with a multiple window interface that’s even popular?”) yes I can - Visual Studio. And as far as annoyances in dealing with numerous other windows - Alt+Tab as well as Window+M are my best friends. Macs simply can not compete with this…
I would love to see a resize button replace the maximize button in the windows gui. It should let you go to a specific pixel size for the windows – i.e. left-click it and a small context-style list appears (much like taskbar icons) that would let you resize to Application Default, 640x480, 800x600, …, Desktop Maximum. Another possibility is to add this feature as a right-click context menu on the existing maximize button.
I am also a fan of visual studio’s docking. A button that turned on/off docking for each window would be beautiful. Of course, the resizing and window movement must take the docked window edges into consideration.