Monolithic apps. versus many-windows apps

21 Jan 2004 - 8:16pm
10 years ago
13 replies
763 reads
sandeepblues
2003

I'd like to understand the advantages/disadvantages of
designing a large app. inside one big main window,
versus having a "main window" with many smaller,
non-modal windows around it. Let's assume the context
is an application where the user will spend many hours
working in.

Case in point: Visual Studio vs. Borland C++Builder
IDEs.

In C++Builder, there is a "main subwindow" where
programmers design the software. Around it are
"Object Inspector" subwindow and a App subwindow with
menus and toolbar buttons for dragging widgets and
managing the project.

Visual Studio has the same view, except that all the
subwindows are child windows of a big window.

The convention seems to be to do it the Microsoft
(Visual Studio) way, i.e. one monolithic window with
subwindows inside.

I find the Borland design better, because it lets me
access icons in my desktop or other app windows from
the "cracks" between each subwindow, without requiring
to minimizing the Borland IDE.

I applied a similar design to a RapidApplication
Generator that produced many grid-style reports for
viewing information.

Your views?

Sandeep

Comments

21 Jan 2004 - 8:40pm
Andrei Herasimchuk
2004

On Jan 21, 2004, at 5:16 PM, Sandeep Jain wrote:

> I'd like to understand the advantages/disadvantages of
> designing a large app. inside one big main window,
> versus having a "main window" with many smaller,
> non-modal windows around it.

What you are referring to generally known as SDI (single document
interface) and MDI (multiple document interface).

They both have very strong pros and cons, but in the end, SDI tends to
be easier to manage for most people. (I say *tends* to be.) However, if
your users are advanced and very computer literate, there's a chance
they'll like an MDI approach as it provides more flexibility, at the
expense of more complex windowing systems.

I think DevStudio does a great job addressing this. You'll not you can
use the software in SDI mode, which is my preferred model, but can also
switch the app into an MDI model in the preferences. The default is the
mode that tends to work for the most people, SDI, while others who
really want multiple windows all over the place to manage on their own
can switch into MDI mode.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

22 Jan 2004 - 3:42pm
sandeepblues
2003

I thought that in a SDI there is only 1 window
displayed, and it can only be used for simple
applications. I think what I was referring to was an
MDI where the subwindows are not inside a big main app
window, but there are numerous of them to manage.

There are many views to the document, but they appear
as regular windows (or maybe toolwindows) on the
desktop. Each subwindow can be minimized
independently, except if the window with the menus is
minimized, then the whole app is minimized.

Can an SDI have a couple of non-modal subwindows?

Sandeep

--- Andrei Herasimchuk <andrei at adobe.com> wrote:
> On Jan 21, 2004, at 5:16 PM, Sandeep Jain wrote:
>
> > I'd like to understand the
> advantages/disadvantages of
> > designing a large app. inside one big main window,
> > versus having a "main window" with many smaller,
> > non-modal windows around it.
>
> What you are referring to generally known as SDI
> (single document
> interface) and MDI (multiple document interface).
>
> They both have very strong pros and cons, but in the
> end, SDI tends to
> be easier to manage for most people. (I say *tends*
> to be.) However, if
> your users are advanced and very computer literate,
> there's a chance
> they'll like an MDI approach as it provides more
> flexibility, at the
> expense of more complex windowing systems.
>
> I think DevStudio does a great job addressing this.
> You'll not you can
> use the software in SDI mode, which is my preferred
> model, but can also
> switch the app into an MDI model in the preferences.
> The default is the
> mode that tends to work for the most people, SDI,
> while others who
> really want multiple windows all over the place to
> manage on their own
> can switch into MDI mode.
>
> Andrei Herasimchuk
> andrei at adobe.com
>
> work: http://www.adobe.com
> personal: http://www.designbyfire.com
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

22 Jan 2004 - 4:17pm
Andrei Herasimchuk
2004

On Jan 22, 2004, at 12:42 PM, Sandeep Jain wrote:

> I thought that in a SDI there is only 1 window
> displayed, and it can only be used for simple
> applications. I think what I was referring to was an
> MDI where the subwindows are not inside a big main app
> window, but there are numerous of them to manage.

There's a lot of debate over where the line actually is drawn with SDI
in regard to interface. But in my opinion, an app like Outlook Express
or Outlook fits the SDI model. It has a main window, but you can spawn
any number of floating windows on top of it to do things like view a
calendar, read an email or view your addresses, and you can spawn them
without necessarily needing the main parent window open. (Such as when
you click a mailto link inside a web browser, all you get is the mail
window.) Yet you can also do all those things inside a single main
window.

I consider SDI model in terms of UI, outside of the engineering
architecture to manage memory, code and objects a certain way, to be a
model that focuses a large collection of interface elements into a
single object that can be viewed in one self contained window. Any
menus, actions, comands, objects, palettes, etc. They are all inside
one window such that when closing that window, all relevant UI goes
away with it. That's why Outlook fits the definition for me.

> There are many views to the document, but they appear
> as regular windows (or maybe toolwindows) on the
> desktop. Each subwindow can be minimized
> independently, except if the window with the menus is
> minimized, then the whole app is minimized.

See above.

> Can an SDI have a couple of non-modal subwindows?

I would say yes.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

22 Jan 2004 - 5:05pm
Robert Reimann
2003

The main benefit of a "monolithic" or "sovereign posture"
application design is that it eliminates the cognitive
and physical overhead of managing the state and position of
many separate windows. A noted drawback is impeded access to
the desktop, though that can be ameliorated to some
degree by allowing a file browser or similar construct
to be opened from a control within the monolithic window.
Sovereign posture applications also work best when the
work area remains fairly static, i.e., when there is a
fairly set palette of controls and manageable number of
content or data views that are being manipulated.
This type of design is very pixel-efficient, allowing more
room for content than multiple windows, which usually have
borders and/or manipulation controls that "waste" precious
space.

Similarly, single window, multi-pane apps with non-overlapping
control surfaces remove the overhead of moving floating palettes
out of the way of content that can be obscured by them. One
possible drawback is that some tool sets can be more
effectively used when they are positioned near to the
object being manipulated. Dockable palettes are one possible
solution to this problem.

Programmers (as Andrei mentioned) tend to love multi-window
applications, mostly because the complexity of what they're
doing demands great flexibility in what can be displayed and
what tools can be accessed. But for applications for which
extreme flexibility is not required, sovereign posture
is probably superior.

Robert.

---

Robert Reimann
Manager, User Interface Design
Bose Design Center

-----Original Message-----
From: Sandeep Jain [mailto:sandeepblues at yahoo.com]
Sent: Wednesday, January 21, 2004 8:17 PM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: [ID Discuss] Monolithic apps. versus many-windows apps

I'd like to understand the advantages/disadvantages of designing a large
app. inside one big main window, versus having a "main window" with many
smaller, non-modal windows around it. Let's assume the context is an
application where the user will spend many hours working in.

Case in point: Visual Studio vs. Borland C++Builder
IDEs.

In C++Builder, there is a "main subwindow" where
programmers design the software. Around it are
"Object Inspector" subwindow and a App subwindow with
menus and toolbar buttons for dragging widgets and
managing the project.

Visual Studio has the same view, except that all the
subwindows are child windows of a big window.

The convention seems to be to do it the Microsoft
(Visual Studio) way, i.e. one monolithic window with
subwindows inside.

I find the Borland design better, because it lets me
access icons in my desktop or other app windows from
the "cracks" between each subwindow, without requiring
to minimizing the Borland IDE.

I applied a similar design to a RapidApplication
Generator that produced many grid-style reports for
viewing information.

Your views?

Sandeep
_______________________________________________
Interaction Design Discussion List discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

22 Jan 2004 - 5:28pm
Peter Bagnall
2003

(Robert just beat me to it, so excuse the redundancy!)

I interpret the original question a little differently from Andrei.
Rather than a question of SDI v MDI I interpreted it as floating tool
windows versus a panelled design. The SDI/MDI question is, I think,
orthogonal to this. There are strong overlaps in the two questions
though.

Anyhow, here's my take on the good and bad of each type... floating v
panels. It's in no way exhaustive.

Floating tool windows
Bad
Increases window management overhead, especially when you're resizing
the main window. This can be a real pain, when you change the size of
the main window and then have to rearrange the subwindows. It's less of
a problem when switching between apps, since it's common to have
subwindows hide in this case.

Disconnects the various parts of the app. This makes it harder to see
instantly which windows in screen belong together. This might not be a
problem on a smaller display, but on a large display it can be a little
disconcerting.

Good
Makes layout more flexible for user. Generally this is a minor benefit.

Panel design
Bad
Designer fixes layout, which may not be the preferred layout for the
user. It's not as obvious how to move things about if you don't like
the way things are arranged as it is with floating windows.
Panels tend to be rectangles, so you may have wasted space which you
might not be able to do much about. The code to layout the various
panels has to be able to cope better with the main window resizing
since that will affect the panels too, but that's not really a good
reason to shun this design.

Good
the position of interface elements is more consistent over time, so
people learn where to find things faster.
there is very little overhead in window management.
Simpler.

Overall my preference is typically for panel designs. Of course you can
do both to some extent by having floating tool windows that can be
docked into the main window, giving you the best of both worlds. But
then of course you have controls for undocking which may take up pixels
you'd otherwise have for real work (although as Robert points out you
have this with floating windows too). Docking also makes the app more
complex which might be ok for power users, but probably not for more
novice users.

Moveable toolbars are similar in concept to this and allow apps to be
customised to a fairly high degree, which can be good for general
purpose software. Apps like MS Word spring to mind, where the set of
functions used by any one person is often fairly unique.

--Pete

On 22 Jan 2004, at 21:17, Andrei Herasimchuk wrote:

> On Jan 22, 2004, at 12:42 PM, Sandeep Jain wrote:
>
>> I thought that in a SDI there is only 1 window
>> displayed, and it can only be used for simple
>> applications. I think what I was referring to was an
>> MDI where the subwindows are not inside a big main app
>> window, but there are numerous of them to manage.
>
> There's a lot of debate over where the line actually is drawn with SDI
> in regard to interface. But in my opinion, an app like Outlook Express
> or Outlook fits the SDI model. It has a main window, but you can spawn
> any number of floating windows on top of it to do things like view a
> calendar, read an email or view your addresses, and you can spawn them
> without necessarily needing the main parent window open. (Such as when
> you click a mailto link inside a web browser, all you get is the mail
> window.) Yet you can also do all those things inside a single main
> window.
>
> I consider SDI model in terms of UI, outside of the engineering
> architecture to manage memory, code and objects a certain way, to be a
> model that focuses a large collection of interface elements into a
> single object that can be viewed in one self contained window. Any
> menus, actions, comands, objects, palettes, etc. They are all inside
> one window such that when closing that window, all relevant UI goes
> away with it. That's why Outlook fits the definition for me.
>
>> There are many views to the document, but they appear
>> as regular windows (or maybe toolwindows) on the
>> desktop. Each subwindow can be minimized
>> independently, except if the window with the menus is
>> minimized, then the whole app is minimized.
>
> See above.
>
>> Can an SDI have a couple of non-modal subwindows?
>
> I would say yes.
>
> Andrei Herasimchuk
> andrei at adobe.com

----------------------------------------------------------
As long as people believe in absurdities they will continue
to commit atrocities.
Francois Marie Arouet (Voltaire), 1694 - 1778

Peter Bagnall - http://people.surfaceeffect.com/pete/

22 Jan 2004 - 5:34pm
vutpakdi
2003

SDI (aka panelled designs) do have a significant disadvantage when the user
is working with two (or more) monitors. Having more than one monitor is
more common in certain vertical markets, but they can be critical in those
markets.

In an MDI (or floating tool window) design, a multi-display/monitor setup
can be more naturally handled and a single window doesn't have to span two
displays in order to take advantage of the setup.

With an SDI or panelled design, taking advantage of the increased real
estate usually means that the single window has to be split.

Seems that the best option would be to allow for both situations (or even a
mix). A single window, panelled design where panels can be torn off or
undocked by expert users, particularly those with more than one monitor.

Ron

=====
============================================================================
Ron Vutpakdi
vutpakdi at acm.org

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

22 Jan 2004 - 5:45pm
Andrei Herasimchuk
2004

On Jan 22, 2004, at 2:34 PM, Ron Vutpakdi wrote:
> Seems that the best option would be to allow for both situations (or
> even a
> mix). A single window, panelled design where panels can be torn off or
> undocked by expert users, particularly those with more than one
> monitor.

Which is why I like the model used by MS DevStudio (or Visual Studio,
whatever the name is these days.) It defaults to a model that is
simpler on the window management side of the equation, but offers the
flexibility to switch for power users who need maximum control.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

22 Jan 2004 - 5:48pm
sandeepblues
2003

This is interesting. The advantages of a monolithic
design make good sense. I have a few issues with them,
which I state below.

I would also say that I find a common trend in soo
many seminars and discussions re. HCI where the
speakers will talk about ease-of-use for the beginner
user, and ignore the expert users or generalize expert
users to being programmers, and therefore, a small,
ignorable minority. This makes a lot of such
exchanges seem rather simplistic and basic. As we all
know, most users usually end up in the center of the
bell-curve (intermediate) and gravitate slowly to
expertise. Btw, this wasn't meant to diss any
responses to this topic, but to point out that a lot
of people work in as complex domains and may have
similar inclinations to programmers.

Now...a use scenario...

Let me see if I can come up with a non-programmer user
scenario. Let's say that there is a graphic designer
taking screen captures of a given app, using Photoshop
to manipulate those captures, and Netscape browser to
view the art in the context of a webpage.

The context is a user switching between different
apps, while spending the majority of the effort in
Photoshop. Now, let's focus on Photoshop. With a
broken up, non-monolothic design, the user would be
able to *directly* access the different app. windows
with less mouse movement (Fitt's), than the
alternatives: taskbar or Alt+Tab or Window+D.

I would even say that after a little window shuffling,
users typically settle down with a given windows
layout. The shuffling sucks, but isn't it worth it for
the expert user.

Someone mentioned that having both "monolithic" as
well as dockable/explodable designs might be good.
How should one decide upon the default then, given an
application?

Sandeep

--- "Reimann, Robert" <Robert_Reimann at bose.com> wrote:
>
>
> The main benefit of a "monolithic" or "sovereign
> posture"
> application design is that it eliminates the

22 Jan 2004 - 6:50pm
Robert Reimann
2003

I think in this case, the issue really isn't about
beginner or intermediate vs. expert, but rather about
complexity of data display and manipulation (btw,
you're right that often too much focus is given to
beginners in general, but that doesn't mean that
experts should be the focus; as you say, the sweet
spot is intermediate behaviors, since most intermediates
*never* become experts).

Not to discount the points in your use example, but I
think the best solution for this case would be
a cinematic display allowing PS and Netscape to
both be open at "full" size, side by side, minimizing
the overhead of context-switching.

But more to your points, Fitt's Law is only part of the
issue; you also need to balance the extra cognitive
overhead. Also, by taking away real-estate from PS,
you're increasing the need to scroll, and the management
overhead for satellite windows. It's unclear to me how
big the win would really be once you factor in all the
issues.

But the only way to make these decisions is to research
what the common usage patterns of your users are, and
design your application to make those tasks simple to
access and perform. Less frequent or important tasks
can require a bit more "commensurate" effort on the part
of users as long as the frequent and important tasks
are highly streamlined. Also, in the case of defaults
for docked vs. exploded, unless the application is
specifically targeted at complex tasks that truly
require multiple windows to be effective, it's probably
safest to make a docked state the default.

Robert.

-----Original Message-----
From: Sandeep Jain [mailto:sandeepblues at yahoo.com]
Sent: Thursday, January 22, 2004 5:48 PM
To: Reimann, Robert;
discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: RE: [ID Discuss] Monolithic apps. versus many-windows apps

This is interesting. The advantages of a monolithic
design make good sense. I have a few issues with them,
which I state below.

I would also say that I find a common trend in soo
many seminars and discussions re. HCI where the
speakers will talk about ease-of-use for the beginner
user, and ignore the expert users or generalize expert
users to being programmers, and therefore, a small,
ignorable minority. This makes a lot of such
exchanges seem rather simplistic and basic. As we all
know, most users usually end up in the center of the
bell-curve (intermediate) and gravitate slowly to
expertise. Btw, this wasn't meant to diss any
responses to this topic, but to point out that a lot
of people work in as complex domains and may have
similar inclinations to programmers.

Now...a use scenario...

Let me see if I can come up with a non-programmer user scenario. Let's say
that there is a graphic designer
taking screen captures of a given app, using Photoshop
to manipulate those captures, and Netscape browser to
view the art in the context of a webpage.

The context is a user switching between different
apps, while spending the majority of the effort in
Photoshop. Now, let's focus on Photoshop. With a
broken up, non-monolothic design, the user would be
able to *directly* access the different app. windows
with less mouse movement (Fitt's), than the
alternatives: taskbar or Alt+Tab or Window+D.

I would even say that after a little window shuffling,
users typically settle down with a given windows
layout. The shuffling sucks, but isn't it worth it for
the expert user.

Someone mentioned that having both "monolithic" as
well as dockable/explodable designs might be good.
How should one decide upon the default then, given an application?

Sandeep

22 Jan 2004 - 8:10pm
sandeepblues
2003

Clearly, most apps are designed monolithically (as
default), so thanks for helping me figure it out.
Nevertheless, I am yet to be convinced. I am
interested in pursuing whether an exploded version is
ideal for my specific use case (PS+scanner+ browser).
I don't work for any related market, btw.

I agree that a side-by-side solution is great. But,
that's why I introduced the scanning app as well in
the use case, where that solution would not work.
Instead, in an exploded design, each app. would be
resized by the user to a size that is ideal for
viewing its content. The user merely clicks from one
app to the another, by having "cracks" between
subwindows, and by recognition and recall of past
window positions both of which are habitual abilities.
NO extra scrolling in each respective app. No extra
window management (the subwindows of one app are
managed maybe initially, and then, not at all).
Clicking on one window of another app, brings up all
other windows of that app, thereby keeping context.

So, I don't see as much cognitive overhead, as there
is in looking for right window in the taskbar, which
is typically overpopulated with minimized windows.

You know, this debate seems to be heading towards the
Apple one-app-at-a-time-one-menu-bar-at-a-time
paradigm, versus the Windows
multiple-window-each-with- their-own-menus paradigm.
The latter has been regarded as much more popular and
useful.

I understand the ideal case of researching user needs.
However, corporations and their sw. products are in
individual islands. If Photoshop has no control over
MS Windows, or over scanning or browser apps, then
what would make it a good citizen in this use case?

Sandeep

> Not to discount the points in your use example, but
> I
> think the best solution for this case would be
> a cinematic display allowing PS and Netscape to
> both be open at "full" size, side by side,
> minimizing
> the overhead of context-switching.
>
> But more to your points, Fitt's Law is only part of
> the
> issue; you also need to balance the extra cognitive
> overhead. Also, by taking away real-estate from PS,
> you're increasing the need to scroll, and the
> management
> overhead for satellite windows. It's unclear to me
> how
> big the win would really be once you factor in all
> the
> issues.
>
> But the only way to make these decisions is to
> research
> what the common usage patterns of your users are,
> and
> design your application to make those tasks simple
> to
> access and perform. Less frequent or important tasks
> can require a bit more "commensurate" effort on the
> part
> of users as long as the frequent and important tasks
> are highly streamlined. Also, in the case of
> defaults
> for docked vs. exploded, unless the application is
> specifically targeted at complex tasks that truly
> require multiple windows to be effective, it's
> probably
> safest to make a docked state the default.
>
> Robert.
>
>
> -----Original Message-----
> From: Sandeep Jain [mailto:sandeepblues at yahoo.com]
> Sent: Thursday, January 22, 2004 5:48 PM
> To: Reimann, Robert;
>
discuss-interactiondesigners.com at lists.interactiondesigners.com
> Subject: RE: [ID Discuss] Monolithic apps. versus
> many-windows apps
>
>
> This is interesting. The advantages of a monolithic
> design make good sense. I have a few issues with
> them,
> which I state below.
>
>
> I would also say that I find a common trend in soo
> many seminars and discussions re. HCI where the
> speakers will talk about ease-of-use for the
> beginner
> user, and ignore the expert users or generalize
> expert
> users to being programmers, and therefore, a small,
> ignorable minority. This makes a lot of such
> exchanges seem rather simplistic and basic. As we
> all
> know, most users usually end up in the center of the
> bell-curve (intermediate) and gravitate slowly to
> expertise. Btw, this wasn't meant to diss any
> responses to this topic, but to point out that a lot
> of people work in as complex domains and may have
> similar inclinations to programmers.
>
> Now...a use scenario...
>
> Let me see if I can come up with a non-programmer
> user scenario. Let's say
> that there is a graphic designer
> taking screen captures of a given app, using
> Photoshop
> to manipulate those captures, and Netscape browser
> to
> view the art in the context of a webpage.
>
> The context is a user switching between different
> apps, while spending the majority of the effort in
> Photoshop. Now, let's focus on Photoshop. With a
> broken up, non-monolothic design, the user would be
> able to *directly* access the different app. windows
> with less mouse movement (Fitt's), than the
> alternatives: taskbar or Alt+Tab or Window+D.
>
>
> I would even say that after a little window
> shuffling,
> users typically settle down with a given windows
> layout. The shuffling sucks, but isn't it worth it
> for
> the expert user.
>
> Someone mentioned that having both "monolithic" as
> well as dockable/explodable designs might be good.
> How should one decide upon the default then, given
> an application?
>
> Sandeep
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

22 Jan 2004 - 5:15pm
Erik Harrison
2004

MDI if you have the child windows inside a larger window (the old
Vantive ticket tracker, for example) is almost always a bad idea. I
can't see a real justification for it, if you have a reasonable window
management policy for the OS, with proper appliction clustering. Most
users I've dealt with (including myself) find that it reduces
flexibilty. To me it really feels like a UI workaround for older
windows OS's that couldn't collapse windows into application groups
like the Mac or BeOS could.

-Erik

--- Andrei Herasimchuk <andrei at adobe.com> wrote:
On Jan 21, 2004, at 5:16 PM, Sandeep Jain wrote:

> I'd like to understand the advantages/disadvantages of
> designing a large app. inside one big main window,
> versus having a "main window" with many smaller,
> non-modal windows around it.

What you are referring to generally known as SDI (single document
interface) and MDI (multiple document interface).

They both have very strong pros and cons, but in the end, SDI tends to
be easier to manage for most people. (I say *tends* to be.) However, if
your users are advanced and very computer literate, there's a chance
they'll like an MDI approach as it provides more flexibility, at the
expense of more complex windowing systems.

I think DevStudio does a great job addressing this. You'll not you can
use the software in SDI mode, which is my preferred model, but can also
switch the app into an MDI model in the preferences. The default is the
mode that tends to work for the most people, SDI, while others who
really want multiple windows all over the place to manage on their own
can switch into MDI mode.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest): http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

_____________________________________________________________
Sluggy.Net: The Sluggy Freelance Community!

23 Jan 2004 - 9:31am
Elizabeth Buie
2004

May I introduce another take on this?

So far, everyone seems to assume that SDI and MDI are the only
alternatives. But there is also the interface in which the concept of
"application window" does not exist -- it has, essentially, only document
windows and tool palettes (plus popups where appropriate).

I'm speaking of the Macintosh, of course.

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

23 Jan 2004 - 1:27pm
Seth Nickell
2004

On Thu, 2004-01-22 at 17:15, Erik Harrison wrote:
> MDI if you have the child windows inside a larger window (the old
> Vantive ticket tracker, for example) is almost always a bad idea. I
> can't see a real justification for it, if you have a reasonable window
> management policy for the OS, with proper appliction clustering. Most
> users I've dealt with (including myself) find that it reduces
> flexibilty. To me it really feels like a UI workaround for older
> windows OS's that couldn't collapse windows into application groups
> like the Mac or BeOS could.

There are more reasonable forms of MDI that use a constrained flavour of
"window management". A good example of this is the use of MDI using
tabs. Its not the right design choice for everything, but it does
provide a mechanism for users to choose how windows are grouped apart
from "application type". This could be relevant, for example, with web
browsers where different windows could have very different purposes.

I have observed developers using tabbed browsers will often have one
window open with a variety of tabs showing API docs, example code, etc,
and another window with various general browsing tab (and sometimes a
third pointing to a "web application" such as a calendar).

-Seth

Syndicate content Get the feed