The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

why is mdi bad?

according to these dudes, http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterWindowsForms.aspx#AvoidMDI

they say avoid mdi. i wrote an app for an accounting firm that was sdi and their first complaint was that they couldn't have more than 1 file open at the same time like excel.

so, what's wrong with mdi?
ElbowsHigh
Thursday, August 11, 2005
 
 
Excel (current version) does not use an MDI form. It allows multiple documents to be open at the same time, but they each have their own window.

The MDI form acts as a parent form  that _contains_ the child forms. MDI children typically do not show up in the task bar either.
Jeff Mastry Send private email
Thursday, August 11, 2005
 
 
The problem is that the MDI document windows are all constrained to be within the single main window. Having multiple documents with entirely separate windows is more flexible.
Briguy
Thursday, August 11, 2005
 
 
In Excel 2003 still looks MDI to me (though I don't know if they use the system provided MDI implementation). They do show each document as a separate button on the task bar. Also, you can launch multiple instances of Excel, but each contains its documents in the MDI style.

And to the OP, having an SDI app doesn't preclude using multiple windows for different functions (registers, reports etc). Though, if by "file" you mean multiple sets of books, I could see where having multiple sets of books, each with multiple windows open could get confusing.
Chris Altmann
Thursday, August 11, 2005
 
 
Cool, I always missed MDI in Words but that crappy design guide showed me it still exists, see here:
http://support.microsoft.com/Default.aspx?kbid=291313

I prefer MDI before SDI if an application have many windows. However, it important to have additional supporting functionality to allow users to easily navigate the MDI child windows, like a Windows menu or some other control displaying open windows. I just finished developing a toolbar which displays a button per open child window so its easy to navigate between windows. Its written in C# and its pretty easy stuff, look for it here in a few days:

http://spaces.msn.com/members/pjsson/
Patric Send private email
Thursday, August 11, 2005
 
 
This is a tough one.

I tend to like have a application like excel, and when I move focus to excel, then the 2, or 3 spreadsheets I laid out all next to each other retain their positions (so, I vote for MDI). 

It really depends on the task you are doing. If you got two completely un-related sheets open, the MIDI is not great. However, even in that case, I tend to group things together. When I have 2 or 3 spreadsheets open, my mind is thinking excel, and when I switch to excel, I want to see those 3 sheets, or at least work with ONE application that works with those sheets.

Do note that today, NEW users tend have more limited brains with respect to using windows. So, now the default for Excel, and word is to show EACH child window as a entry in the task bar. So, each application, or each window is now a task bar item, and for new users, they can grasp this concept easier. To switch to a window, you use the task bar...end of rule and learning!!!

And, note that the xp task bar default xp is to GROUP taskbar items together.

However, in word, or excel, you can go

tools->options->view tab, and uncheck the “windows in task bar”

Doing the above will return the behavior to how office has worked for about 14 years.

And, the groupings in the windows task bar can also be changed if you right click the task bar can select properties (“Group similar taskbar options”).

Note also that in office how the child windows do NOT have a menu bar, but follow the apple UI, and the menu bar stays at the top of the application.

As a general rule, I prefer MIDI for my applications as it groups windows that belong together in your application.


Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Thursday, August 11, 2005
 
 
"Do note that today, NEW users tend have more limited brains with respect to using windows."

I can tell you it's not just new users.  I"ve been using since the early days and I never got comfortable with MDI. 

Microsoft had good reasons for moving away from it: it confused users by adding two types of minimization.  Users would be looking for their minimized MDI document in the Windows taskbar and be unable to figure out that it's hidden away in the lower corner of an app that may or may not be open on their desktop.

If you're always aware of which apps are MDI and which aren't then MDI adds some minimal ease of use by grouping windows in master app.  But it really requires you to keep your guard up.
Herbert Sitz Send private email
Thursday, August 11, 2005
 
 
Come to think of it, I also very much disliked the way MDI messed with concept of Window maximization, too.  When I maximize a window I want it to take up the entire screen.  With MDI it only expands to take up same space as master window.  And then it creates confusion about what other child windows might be open in master app underneath the maximized child windows.  MDI is just plain bad ui if you ask me.
Herbert Sitz Send private email
Thursday, August 11, 2005
 
 
Herbert, I tend to agree with you comments.

As for my comments about “new” users, your comments about finding, and moving to another window is spot on. No doubt, usability studies also find this problem. You comments about how to move to another window in a application, and when you minimize it..…where does it go tells the story here.

I would bet that those two issues is what forced this change.

However, as mentioned, I tend to group windows by application. Further, I RARELY minimize the child windows. When I max the application, I get my child windows laid out the way I want. (and, ask your self how most IDE’s for software development work….they are midi).

And, for my commercial applications that I write, 90% of the time, you can’t minimize the child window anyway (it is model).

So, there is a issue of personal pref, and also of what kinds of applications you are writing. If you are writing productivity type application like Excel, then likely windows in taskbar is a BETTER approach, and one that is easier managed by new users.

However, in my business type applications, you are often 3, 4 or even more forms deep into the application, and having the menu bar clutter up with a whole bunch of child windows just don’t work. This is especially so when the forms are model (clicking on a previous form in the task bar don’t make sense as it can’t get the focus anyway -- that is very confusing to a user! (eg: in my appllicatons, often you need the current form to be compeleted, or certain information to be entered).

Also, it depends…many applications are a mix of mdi. Outlook for example has many child windows, .but when you make a new email..that becomes a separate window.


Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Thursday, August 11, 2005
 
 
I suppose MDI has its uses.  I'm not sure it's _all_ bad.  But I don't use any MDI apps and I like it that way.  And I purposely design my apps to not use MDI.

The main benefit from MDI, imo, was the grouping of minmized windows so that that a single app's minimized windows didn't clutter up and confuse the Windows task bar.  But recent version of Windows perform their own grouping operation when there are multiple open windows from same process so this benefit of MDI is no longer necessary.  In fact, the Windows grouping of app windows actually improves on MDI, because it not only groups all the windows, it groups them all in one place (on the regular Windows taskbar). 

Some people seem to think this Windows taskbar grouping means an app is MDI.  It doesn't.  In fact I think you get this behavior only if your app is _not_ MDI.  I don't use any, so I can't be sure, but I suspect MDI apps still have just one icon on taskbar (for main window) and then maintain their own collection of minimized windows within the main window of the app.
Herbert Sitz Send private email
Thursday, August 11, 2005
 
 
So what is it about your application that means you cannot open multiple copies of your SDI?

Why didn't you have more interaction with the users to find out how they work & how they think they will work with your new app before you built it?

if you have a single instance MDI interface, you can't display the 4 documents accross your 4 monitors easily.

Thursday, August 11, 2005
 
 
>But I don't use any MDI apps and I like it that way.

Ah, ok that explains it. When I fire up visual studio (6.0), you got LEAST 5 child windows, and even the forms designer is a child window.

As a rule, most IDE's are mdi...

You can toggle the environment to be SDI, but that is not the norm….

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Thursday, August 11, 2005
 
 
> The problem is that the MDI document windows are all
> constrained to be within the single main window.

This is exactly the reason MDI is such a good concept.

> Having multiple documents with entirely separate
> windows is more flexible.

In many cases the exact opposite is true.

If the work involves manipulating sets of related items there is nothing better than MDI exactly because it maintains the concept of the set, by constraining the items to a single entity.

Consider a set of N items and breaking the set into its N individual parts. Now consider a set level operation (i.e. save all, replace all, calculate all, close all) which should only require a single command, but now requires N identical steps.

How has increasing the workload by N actually made things more flexible?
Jussi Jumppanen
Thursday, August 11, 2005
 
 
"> Having multiple documents with entirely separate
> windows is more flexible.

In many cases the exact opposite is true."

You're confusing "more flexible" with "easier".  Being able to have windows anywhere on your screen is certainly "more flexible".  It might make some things more difficult, but that's a different issue than flexibility.

"If the work involves manipulating sets of related items there is nothing better than MDI exactly because it maintains the concept of the set, by constraining the items to a single entity."

Not true.  There's nothing that prevents an SDI application from having 'Close all', 'Save all', 'Recalculate all'.  MDI only means that the doc windows are subwindows of main app window.  SDI only means that doc windows are independent.  But whatever you choose your app can easily keep track of which windows are associated with the application and do operations that affect all open windows, or even all open windows of a certain type.  To do this with SDI you'd probably want to have one main window that owns all the other windows, even if the other windows are not contained within it.  That's exactly what I do in one of my SDI apps.
Herbert Sitz Send private email
Thursday, August 11, 2005
 
 
>But whatever you choose your app can easily keep track of which windows are associated with the application and do operations that affect all open windows, or even all open windows of a certain type.

Yes, your application can keep track, but how does a user keep track?

They say a picture is worth a 1000 words. Here is two screen shots. The are both of the SAME desktop.

The ONLY THING I changed was switching the visual studio from MDI to SDI.

As the picture shows, the problem is not your code or application keeping track of windows, but how does a user know what windows belong to what application?

Here is the before and after screen shots…..

http://www.kallal.ca/midi/index.htm

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Thursday, August 11, 2005
 
 
Jussi could not have put it better:

>If the work involves manipulating sets of related items there is nothing better than MDI exactly because it maintains the concept of the set,

If you look at the first screen shot in my link…you have absolute NO idea which of the windows belong to VS…..

The 2nd screen is the SAME set of applications and windows open. The MDI interface obviously groups the windows together as it should.

At the end of the day, MDI does group windows together. If anyone got a new idea for showing relationships between windows that are related in a better fashion then MDI, then I am all open to ideas, but I don't know of anything better right now.

Each type of interface has its merits, but you can’t just throw out MDI when it makes sense to use it.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Thursday, August 11, 2005
 
 
Question for enlightenment only.

I am of the impression that mdi was a design set out in the CUA guidelines by IBM.

I am also self convinced that MS has always been sniffy about it and has repeatedly tried to change to SDI in each iteration of Windows since the OS2/Windows split, (possibly excluding presentation manager for NT).

How right am I?
John Griffiths Send private email
Friday, August 12, 2005
 
 
>Why didn't you have more interaction with the users to find out how they work & how they think they will work with your new app before you built it?<

i guess i'm a shitty consultant.
ElbowsHigh
Friday, August 12, 2005
 
 
It's often difficult to get an understanding about what the customer or users expect. Much of the time they don't know what they want up front, but after they see something they know what they don't like about it. This is just par for the course. Just because it's easy to have 20-20 hindsight doesn't mean that it would have been easy to identify the problem areas beforehand.
Briguy
Friday, August 12, 2005
 
 
In Word, the windows are truly separate documents. In this case it feels more logical to separate them (presumably Microsoft got this feedback from users of Office 97).

Visual Studio is a different situation. You are working on one project, and you may want to see windows for your local variables, output, stack trace, source code, or whatever. These are different aspects of the same thing (a running program being debugged) and it is more logical to group them together. (Even so, I like being able to "undock" them and move them out of the main window if they get in the way, as in VS .NET 2003.)

So conceptually, separate documents aren't related as closely. Also, in Windows XP the documents are grouped on the taskbar which in a sense gives you the advantage of MDI (grouping) without the disadvantages.
Briguy
Friday, August 12, 2005
 
 
Albert -- Your screenshots may illustrate something good about MDI, but they also illustrate something very bad:  MDI applications are fine if you're working exclusively within that application.  If you want to use the application alongside others they're annoying. 

If you're using an MDI app heavily then you will almost certainly have the master window expanded to take up most of your screen space.  You will have various windows open within it that take up varying amounts of screen space.  Now, assume I want to have a browser page open alongside one of those child windows (which I very often do want).  No can do, because although when you have the browser app active you can position it alongside the MDI child window, as soon as you click within the child window the whole MDI app becomes active and hides the other apps on your screen.  Argh.  I can't tell you the number of times I've cursed at this behavior.  This is aggravated by fact that at least in MS Office programs the help files were _not_ part of the MDI structure.  So if you were trying to put a help file along side an MDI child window to have open while you were working in the child window, or to cut and paste, the MDI master window would obscure the help window as soon as you clicked within the MDI child window.  Yuck.

I also don't think there's much trouble keeping track of windows with SDI.  As a user I always have a browser open, usually a secondary text editor, mail client, help files.  If you do this for any length of time it's obvious which windows belong with which.  SDI lets any of the windows of a main app interact with any window of another app.  MDI puts each child window in its own little prison and makes it harder to work with related data in browser windows, help windows, separate text editor, etc.

Docking of windows in SDI apps is another thing allows grouping of windows in a way that overcomes the bad things about MDI.

There is also nothing preventing an SDI app from having a main window with a command 'Bring All To Top", which could force all the windows in the SDI app to be above windows on desktop that aren't part of the SDI App.

Access 2k was actually still an MDI app, although Excel 2k and Word 2k were SDI.  I still occasionally do work in Access 2k and almost always get annoyed at the problems MDI causes.  It has a few benefits.  It also has lots of annoyances.  And now that SDI apps have automatic grouping of open windows on Windows Task Bar, ability to have UI's where windows are docked or undocked, I think building any app as MDI is generally a bad idea.  IMO, it's a UI design that has been superseded by better ones.

And even if the SDI apps that have superseded MDI weren't flat out better, there is still the issue of uniformity and sticking with conventions.  Users are confused when apps break conventions and work differently from other apps.  MDI apps do this, because almost all apps a user runs are SDI and MDI is a completely different model.  It's confusing.  There are better solutions.
Herbert Sitz Send private email
Friday, August 12, 2005
 
 
Getting back to the OP's issues, he said:  "they say avoid mdi. i wrote an app for an accounting firm that was sdi and their first complaint was that they couldn't have more than 1 file open at the same time like excel."

The link you gave had a good short summary of most of what is bad with MDI.

In case you haven't figured this out, though, note that whether or not an app is MDI or SDI has nothing to do with whether an app can have more than 1 document window open at the same time.  It has to do only with whether the open doc windows are all grouped within a master window or whether open document windows can be sized and moved independent of each other (and any main app window) on the Windows desktop.
Herbert Sitz Send private email
Friday, August 12, 2005
 
 
"MDI applications are fine if you're working exclusively within that application.  If you want to use the application alongside others they're annoying."

99.9% of the time all my applications are maximized.  What's your percentage?  Being able to drag application windows around other application windows is pretty moot if every application takes up the full screen.  I also really don't like seeing irrelevent windows (or god forbid, the deskop) peeking inbetween the windows I'm actually working on.

You really can have both worlds though: Tabs that break off into independent windows.
Almost H. Anonymous Send private email
Friday, August 12, 2005
 
 
Almost Anon -- We work differently.  99.9% of the time _none_ of my apps are maximized. 

About having best of both worlds:  I agree.  But you can't do that with an MDI app.  Only with an SDI app that uses docking.
Herbert Sitz Send private email
Friday, August 12, 2005
 
 
Three words: Multiple Monitor Support!
anon
Friday, August 12, 2005
 
 
"Almost Anon -- We work differently.  99.9% of the time _none_ of my apps are maximized."

Wow.  What do you do with the extra space?  I find most of my applications aren't usable if they take up less than say 70% of the screen.  The remaining 30% isn't terribly useful.  I do have a few floating-on-top applications like Winamp.

"But you can't do that with an MDI app.  Only with an SDI app that uses docking."

I'm thinking of non-traditional MDI like, for example, tabbed browsing (and the equivalent in VisualStudio).  It's not Windows MDI but it's still a Multiple Document Interface.  But there is no reason you couldn't have an MDI application where you could break out the child windows onto the desktop (in fact, I developed an application like that in VB6).

I do use multiple monitors -- so it is handy to break out individual windows on occasion.  Mostly though I have one entire application (with all child windows) on one monitor and another application on the other.
Almost H. Anonymous Send private email
Friday, August 12, 2005
 
 
"Wow.  What do you do with the extra space?"

Part of reason I don't maximize is because my desktop is 1400x1050.  There's simply no need to have a single app take up that much space.  They actually become harder to use.

Sometimes the extra space goes unused, and I can see programs or files or folders on my desktop.  If windows are un-maximized then I can always clickly click-and-drag them aside to get at something underneath on desktop.  I also usually have other apps (often a browser) alongside or partially underneath, and they easy to activitate by clicking on them rather than having to go down to taskbar and restore them from minimized state.

I actually love multiple document interfaces.  I just hate the constraining one that's formally known as Windows "MDI".  Multiple document interfaces implemented in SDI apps can be great.  And as Albert says, depending on how you work the Windows MDI type interface might work well for you.  But as a general rule I think it's bad, and I really think it's something to avoid in any db-type-business-app I'm developing for the ordinary users.
Herbert Sitz Send private email
Friday, August 12, 2005
 
 
>MDI apps do this, because almost all apps a user runs are SDI and MDI is a completely different model.

Actually, until about 3-4 years ago, this was not the case. (office 97 was not SDI….office 2000 was the first version (and that came out in 1999).

And, we have to distinguish between productivity tools like spreadsheets, or a accounting package.

As for your arguments Herbert, well, they are amazing, well thought out, and hit HARD to the point. In fact, so much so, I am standing here without any response!! Going..hum, you know what, you make a great case here for SDI! Not much really can be said to counter your points! Your sharp sword on this one has sold me!

Perhaps the most surprising point:

> I really think it's something to avoid in any db-type-business-app I'm developing for the ordinary users.

You see, that is kind of where I was making the case for using mdi. Those business applications are OFTEN the exception I am talking about. A bit of a surprise here!!
(However, not a big deal here either!!).

And, if MDI as a rule allowed you to peal off the child forms, then I think that would be the best approach (and, you make a case for that also – and that would NOT be MDI as you mention anyway).

You mentioned ms-access, and it also has the “windows in task bar” option. So, even ms-access can behave as a SDI now.

I do think that some applications should manage things for the user. However, more elevated users, and more demanding users likely will prefer SDI after a certain point.

And, do note that often a solution here is to launch another copy of the application (and, using a browser is  a great example…as users really don’t think of having 5 or 10 browser windows open as 10 applications – but that is what is going on). Once again, in this case, MDI does have merits in how it groups the windows. (you have 5 copies of the application running..but each copy does manage its child windows).

At the very end of the road, it would seem that a GOOD SDI interface is better then a MDI, provided that the SDI UI manages the child window issue well…

So, to get the last word in, I will say that MDI has it merits, and it often depends on what the user is doing, AND what kind of user(s) you have!


Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Friday, August 12, 2005
 
 
If we're coming to agreement then we don't get to do point-counterpoint anymore.  A shame. 

But I'll add one more word.

Several suggested that treating child windows as a collection was a benefit of MDI apps.  Although there's nothing to prevent an SDI app from managing multiple document windows as a collection, I'm not aware of any that do.  But I'm now going to put this on the todo list of things to implement in my SDI app.    In my app I have one class of window that opens up a major tabbed edit form for a "contact".  This is generally a singleton form (i.e, if user opens another contact it loads new contact into same form.  But if user desires they can create as many instances of this form as they want if they want to have forms for different contacts open at the same time. 

To coordinate things when users do this, I'm going to my todo list the implementation of something like "Restore all" and/or "Cascade all" and/or "minimize all" that will work on the collection of these "contact windows" as a whole.  Seems like a neat way to port that MDI-type concept to an SDI app.
Herbert Sitz Send private email
Friday, August 12, 2005
 
 
Simple question: if MDI is so bad, why are Microsoft touting its introduction to Internet Explorer 7 as a great step forward?  IE has always been SDI, one window = one document, all documents visible in taskbar.  Now they're introducing MDI, because all the advanced users are clamouring for it and all the competing applications, INCLUDING APPLE'S SAFARI, introduced it long ago.

Either MDI is a good thing, or tabbed browsing is a huge step backwards.  But most of the people who bash MDI also seem to love tabbed browsing.  Funny how that works, isn't it?
Iago
Sunday, August 14, 2005
 
 
Could it be that tabs have many of the benefits of MDI with not as many downsides? You can group related things together, but you don't have the problem of having two kinds of windows, and subwindows that need to be micro-managed.

Perhaps the next-generation windowing systems will provide first-order support for tabs, allowing people to work with them a bit like how tabbed tool palettes work. Currently the tabs usually can't migrate between windows, and you can't easily spin a tab into a window. This isn't, however, something that can't be fixed, especially if the application is designed to be tabbed from the start, or if the windowing system does the tabbing.
Aapo Laitinen Send private email
Sunday, August 14, 2005
 
 
"Now they're introducing MDI . . "

Iago -- The MDI that most of us were talking about in this thread is a standard with a specific way of relating child windows to master window.  The sort of interface you have for tabbed browsing is not anything covered by the "MDI" that we talking about, and in fact tabbed browsing is implemented (as far as I know) only in SDI apps. (I don't know if there are any true "MDI" browsers.)  Sounds strange because we're talking about various ways for SDI apps to have multiple documents in a single window, but that's the way it is.
Herbert Sitz Send private email
Sunday, August 14, 2005
 
 
I am an SDI fan.  We target computer programs at humans.  Humans have one conscious focus (I am trying to avoid bringing the subconscious into this).  With one conscious focus humans can only really work on one thing at a time.  What we should be asking is how can we display information to the user in a way that it will be most useful to them.  I put forth that and SDI is easier to use than an  MDI because you don’t have to manipulate sub windows within your application. 

If our users need to display the same data for multiple entities within the application for some reason (maybe they need to see two customers at the same time to copy information from one to the other) then why don’t we as GUI developers know that?  Why aren’t we looking to produce easy ways to do what the user is doing?  Yes, an MDI window gets you this sort of functionality for free, but so does implementing your control and then using it twice on the same form.  You should know your customers well enough to be able to write an SDI interface. 

I should note that I am speaking about the general public here, not about programmers.  You can give programmers an interface that is literally the command line and they will learn your interface and work efficiently with it, providing you are giving them the tools to do things efficiently (shell scripts as an example).  Things like Visual Studio .NET are okay to have an MDI interface because you are dealing with people who are used to thinking that way.  You are dealing with people who even know what an MDI interface is vs. people who just use a computer.
Joshua Volz Send private email
Monday, August 15, 2005
 
 
As mentioned in a previous post in this thread I had some C# code to improve the MDI experience with a toolbar to quickly find any window, see link for code and pictures:
http://spaces.msn.com/members/pjsson/Blog/cns!1p76K4WF1ADMWttSKAc6E-Sg!267.entry
Patric Send private email
Tuesday, August 16, 2005
 
 
All MDI apps have tabs. You just have to click the Window menu to see them.
Wayne Send private email
Tuesday, August 16, 2005
 
 
> Even so, I like being able to "undock" them and move
> them out of the main window if they get in the way,
> as in VS .NET 2003.

But "undocking" a panel is nothing like creating a new SDI window.

Since Windows knows the panel is in fact a popup window it will handles it's behaviour in a standard fashion.

For example the undocked panel will get activated and hidden along with it parent, it will not get shown on the task bar as an application (since it is not), and if the parent dies it will also die.

Now there is nothing stopping a programmer from making an SDI application behave in the same way, but this "standard Windows behaviour" would need to be hand coded by the programmer.

The end result would be no two SDI application would look, behave or feel the same.
Jussi Jumppanen
Monday, August 22, 2005
 
 
> The sort of interface you have for tabbed browsing
> is not anything covered by the "MDI" that we talking
> about and in fact tabbed browsing is implemented (as
> far as I know) only in SDI apps.

Zeus is 100% MDI and like many MDI applications it has had this "tabbed interface" for years:

  http://www.zeusedit.com/images/lookmain.png

Iago is spot on.
Jussi Jumppanen
Monday, August 22, 2005
 
 
Interestingly I feel that MDI is more MS centric (Probably an inheritance from it's early days), while "SDI" (from what I understand from this forum) is much more typical of Unix, while the "Sheets" of Mac OS X is - well, typical of Mac OS X.

All-in-all, they all have their flaws, the Sheets of Mac OS X means that the app _has_ to allow you to open more than one app, because most of the time you can't run more than one app - period (Well, No way that *I* could see)

When that flaw I mentioned gets annoying, I vastly prefer the unix system above all others, although at times it can be too...  For lack of a better word "spatial". (Having said that, even Unix doesn't go as far as the "SDI" screenshots here, they were a bit excessive - a toolbar in their _own_ window?)

On MS, though, people almost always maximize their windows.

(Note I have done no research or whatever to justify these opinions, these are just my own impressions about the subject)

In conclusion, I feel that you have just got to be aware of the advantages and disadvantages of each design, and imho, we're seeing somewhat of a rebirth of MDI in the form of tabs. :)
Arafangion
Wednesday, August 31, 2005
 
 
How do I disable MDI and switch to SDI on XP (running Office 2003)? Is it doable at all?
Sam Young Send private email
Thursday, September 01, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz