Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Even though MDI is considered harmful, several applications (even MS Office, Adobe apps) still use it either in its pure form or some as a hybrid with a tabbed/IDE-like interface.
Is an MDI interface still appropriate for some applications?
I'm thinking of an application where one typically works with several documents at one time, and often wants to have multiple documents side to view or copy/paste between them.
An example would be Origin, where one has multiple worksheet and graph windows in a project; a tabbed or IDE-like interface would be much more inconvenient with a lot of switching back and forth.
On the mac, it's natural and convenient for an application to have multiple top-level windows to solve this, what is the preferred way in Windows if one doesn't use MDI?
The disadvantages of MDI are the following:
It generally requires the user to learn and understand a more complicate set of window relations.
Many simple actions can require a two-step process. For example, bringing a desired window to the foreground can require that the user first brings the container window forward then bring the right primary window in the container window forward. Resizing or maximizing a window can mean first adjusting the container window then the primary window within.
If multiple container windows are open, the user can forget which one has the desired primary window, requiring a tedious search.
Users are easily confused by the dual ways to maximize, iconify, layer, and close a window. For example they may close the entire app rather than a window within the container window. Or they may “lose” a window because they iconified it within the container window without realizing it.
The user is limited in the sizes and positions his or her windows can assume. Suppose I want to look simultaneously at 3 windows of one app and 1 from another app. With SDI, I can have each window take a quadrant of the screen, but I can’t do that with MDI. What if I want one window in the MDI to be large and the other small? I have to make the container window large to accommodate the large window (where it occludes the windows of other apps), but that wastes space when looking at the child.
Note that all of these disadvantages apply to tabbed document interfaces (TDI) too, with tabbed interfaces having the additional disadvantage that the user can’t look at two documents in the same container window side by side. Tabs also add clutter and consume real estate in your windows. However, overall TDI tend to be less problematic than MDI, so they might be preferred for special cases (read on)
In summary, it hard to think of any situation to use MDI. It’s no better than an SDI while adding more complexity and navigation overhead, and working poorly with the windows of other apps.
There’s no reason an app can’t have multiple top-level SDI windows. Even with an app like Origin, I don’t see a problem with a project being spread across multiple SDI windows as long as the project is well identified in each window. SDI also allows different kinds of windows (e.g., graph vs worksheet) to have different menus and toolbars, rather than hiding or disabling items depending on the active window (the former is confusing, and the latter wastes space).
SDI gives your users the more flexibility over either MDI or TDI. Users can overlap or maximize the windows, and use the taskbar/dock as a de facto tab interface. Users can alternatively resize and reposition the windows so they can look at multiple at once. Each window can be sized independently to optimize screen space. Whatever advantages an MDI or TDI may have, you may be able augment SDI to have those advantages too (e.g., provide a thumbnailed menu that makes switching among windows faster than using the taskbar and comparable to selecting tabs, or provide a control that iconifies all windows of an app with one click).
Unless you have compelling reasons to use a TDI, go SDI to allow this flexibility. Compelling reasons include some subset of the following:
Each tab is used for unrelated high-order tasks and user will not be switching among tabs frequently or comparing information across tabs.
You’re working with very low-end users who are ignorant of or confused by the taskbar/dock and multiple windows, and don’t know how to resize windows (it seems compelling tab imagery works better than the taskbar for such users).
You anticipate there’re typically be a large set of tabs (e.g., 4 or more) and you can control their display in a manner more effectively for the task than the OS can if they were SDI windows on the taskbar/dock (e.g., with regard to order and labeling).
With SDI, you’re having problems with users confusing the toolbars or palettes of inactive windows with active windows.
Tabs are fixed in number and permanently open (e.g., when each tab is a different component of the same data object). The user is not saddled with trying to distinguish between closing a tab and closing the entire window; figuring out the window to navigate to is not an issue because all windows have the same tabs.
There is really only one way to properly arrange the data for task, with no variation among users or what they actually use the app for. You might as well set it up for the user with a combination of tabs and master-detail panes and rather than relying on the user to arrange and size SDI windows right.
In summary, given your users’ abilities, app complexity, and task structure, if your app can manage the content display better than the user/OS, use TDI, otherwise use SDI.
Note that the examples you used (MS Office and Adobe applications) are big programs and have lots of features. Users will be dealing with that program, and only that program for much of the program's lifetime.
Newer versions of MS Office (2007) and Adobe Photoshop (CS4) use multiple windows and tabs, respectively.
Note that with Windows 7, MDI's will probably lose popularity even more because of the extra power of tabs given by Microsoft's API's (although you needn't strictly use tabs -- MDI windows could work, but would be more confusing for the user than usual).
The old-style MDI (where to switch between documents, you had to go through the Windows menu) was annoying. The newer MDI (like tabs in Opera and Mozilla) make switching between documents very easy and seem to have been accepted well. They also don't clutter your taskbar as happens if you had more than one document open in something without MDI.
The main advantage of MDI is when you want to keep track of two or more windows at the same time, and those windows need to be grouped together. For example, there's a running process in one window, but you need to work on another window, MDI would be the most ideal.
I agree with slavy13 (old-MDI = bad, new-MDI = much better). But don't use programs like Microsoft Excel as your model. Ick! You get one window on your desktop, regardless of how many spreadsheets you have open (which may or may not be your preference.) But you get one taskbar icon for each and every document you have open. And your Alt+Tab window similarly has one icon for each document you have open. Plus, there is an additional icon in there just for "Excel" which takes you to whichever document happens to be "current". So yeah, do your MDI like Mozilla. Or at least give your users the option of switching to the cleaner style.
To more succinctly answer your question, I feel the answer is yes, MDI is still appropriate in some instances. But, in all things, moderation is the key.
It appears that multiple top-level windows is the way to go. As for whether there should be one global app instance or one per document is up to you I think. It's not visible to the user.
Only one benefit for MDI:
Programs that use large amounts of resources, such as Adobe Photoshop, often have an MDI due to the prohibitive cost of running more than one instance at a time.
But you shouldn't develop programs that drain huge amounts of resources to start with.
One advantage I can see for MDI occurs if a lot of screen real estate is going to be used for stuff that's shared among many windows. It may be more logical to have such material at the top or side of the enclosing window than to have it repeated in each SDI window, or have it appear in a window entirely separate from the SDI windows. For example, a chat program might have a status pane and a control pane. Having those be somewhat tied visually tied to the chat windows might be better than having them as standalone windows.
Related
So my question is: Is it possible to open, for instance, Discord, Chrome, Spotify or any files in "one process/window"? What I mean by that is, if I wanted to be able to open 3 apps but I don't want it to take so many tabs and so much space, I would want to have those 3 apps in one window. So lets say I were working on 3 different projects and I don't want to always switch desktops or look for the apps everytime I switch projects, I would just want to alt+tab to that project. It would also be nice to be able to prioritise one app in task manager instead of 5. If that is not possible then my thought was to create a "screen sharing program" that captures the other apps and displays it into a UI that I could design. If it were possible, how would I go about starting that?
Simply said, no. You could however try creating different desktops on Windows.
See this page for more information:
https://support.microsoft.com/en-us/windows/multiple-desktops-in-windows-36f52e38-5b4a-557b-2ff9-e1a60c976434
Yes, it is possible to put a process's window inside another process's window. I did it in a very limited case once, but that involved placing a non-interactive (display-only) window inside of an application I wrote which was used by only a few people. I have no idea how well it would work with multiple interactive windows.
Use SetParent in your "screen sharing program" to place the desired applications inside your window. However, take note of Adrian McCarthy's answer to Good or evil - SetParent() win32 API between different processes, and note Raymond Chen's blog posts from the comments:
Is it legal to have a cross-process parent/child or owner/owned window relationship?
Sharing an input queue takes what used to be asynchronous and makes it synchronous, like focus changes.
The documentation for CGWindowListCopyWindowInfo says
Generating the dictionaries for system windows is a relatively expensive operation. As always, you should profile your code and adjust your usage of this function appropriately for your needs.
My question is how can I "adjust" my use of this function? For a code automation process I frequently need to check what window is frontmost among those of document or modal level. That is, I call CGWindowListCopyWindowInfo, ignore the windows that belong to other processes or have levels that I don't care about, and identify the first window that remains.
If there were a way to ask for information about just the windows owned by my process, say, that would be nice, but I see no way to do that. Or if there were a way to be notified when my windows change. I could watch for Carbon Events when windows are hidden or shown, but of course that is a deprecated technology.
You can use [NSWindow windowNumbersWithOptions:0] to get the window numbers of just the current application's windows (on the active space) in z-order.
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a WM_NCPAINT message and passes it on to DefWindowProc, which is part of User32.dll - the core window manager code.
Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.
That's just one of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!
It would be a far less difficult job to echo the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is very common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application.
What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.
In a fairly graphics intsensive application the requirements state that it should default to full screen mode even though the application is running under Windows. I know many games do this but I find it annoying. The default IMO should be to open in a window rather than full screen mode. I am proposing the first time the user runs the application they should select the default behavior. Am I wrong?
I think the annoyance-factor depends a lot on what the application tries to do.
If it is some utility that I might start while working in 5 different applications and it forces its fullscreen-ness on my, then I'd get highly annoyed.
If it is a specialized application that helps me with the entire workflow of a given task (so that I never or rarely need any other apps open at the same time), then fullscreen might actually be a valid default.
Whatever you do, just make sure that toggling the startup behaviour is very discoverable. Because no matter which way you'll go, some of your users will disagree with your decision. And for them it should be very easy to change to their prefered way.
I would follow the requirement the first time the application is launched. I would also provide a simple way to switch from full screen to windowed, for instance by pressing ESC (and another way to go back to full screen). Then I would store the mode when quitting the application and restore this mode at next launch.
Before doing the opposite of what your requirements say, I'd have the requirements changed.
However, what about giving the user the choice at install time?
The window at first-start-up should default to the optimal size for the largest proportion of users. For a graphics-intensive full-featured app, that may very well be full screen.
As for individual user preferences for window size, it seems to me most users won’t know if they want full screen or not until after they’ve started to use the app and see how much screen space they need and how much they use the window in conjunction with other windows. Asking them which size they want at install or first-start-up could thus be annoying and even confusing. It’s better to put such a setting under Options/Preferences.
Perhaps the best thing to do is save the window status on exit. Users who like it non-maximized thus only have to non-maximize it (and size it) once and then forget about it. The only consideration is to have some way to reset the window to the default (e.g., Window > Standard Size menu item) for novice users who accidentally resize or reposition the window to something bizarre and don’t know how to get it back. Alternatively, you could have a Window > Keep Sizes and Positions menu item for users to explicitly save the window status across sessions.
Go back to the requirements writers and ask them if they have considered non-traditional monitor setups, such as:
30" or larger monitor. Do you really want your app hogging up all the screen real-estate?
Multiple monitors. Which monitor will you run on? Can the user move your app from one monitor to another? Can your app span more than one monitor?
Virtual desktops. Can the user move your app from one desktop to another? Can they switch desktops while your app is running? Can your app span more than one desktop?
Such setups are increasingly common, especially large monitors. IMO, full-screen mode (the default for many older Windows apps) is becoming less and less useful.
The problem with presenting the user with the option of initially selecting fullscreen / vs windows is that they haven't used the software yet. How can they make a decision on which is better for them, without experience?
I would run the app in whichever mode provided the best user experience and then offer an option to change it both in the Preferences and though a hint while starting up the application for the 2nd time.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
When developing a desktop application that has several groups of equally important data and operations, how do you tackle the user interface design?
Most of the web-based apps I've developed have a simple home page with links to each service the app offers. Most of those pages contain lists of items in a database which you can drill down or perform operations on by following "edit" "update" or "delete" type links. Think of the vBulletin user control panel. Menu down the left side, data groups and operations on the right.
I'm now looking into desktop application development and am curious about the most common design idioms. For the above example, I imagine some kind of tabbed interface (like Eclipse with the Java perspective, Subversion perspective and so on), but if the functionality groups are used with roughly equal frequency, the user will be clicking around between the tabs very often. I also wonder whether I want to let the user launch n tabs of the same type, or preload each tab for each functionality group and only allow the user to switch between them.
I suppose it could also be implemented using separate windows for each group of functionality. That leaves the problem of having an out-of-place "home window" which is just a collection of buttons to fire off those windows.
After being a desktop application user for so many years, I'm stumped when it comes to actually building an interface that makes sense and doesn't stand out. I looked to microsoft office, but most of those apps deal with one piece of data (eg. a word document) with many operations, rather than many equally important pieces of data each with unique functionality.
What design principles / idioms do you follow for desktop application development in this situation?
Having three separate windows for each data group allows the users to see more than one data group side by side (assuming their monitors are big enough), a flexibility that tabs don’t provide. Separate windows also allow you to have different menu bars and toolbars for each data group, eliminating the clutter of a bunch of disabled operations when the user works on any one data group.
Unless your “home” window is more like a dashboard for summarizing and monitoring what’s in the other three windows, you are right to not have one in addition to three windows for the actual data. Instead, allow users to open any window through the pulldown menu of any of the three windows. In place of the ubiquitous Open menu item found in the File menu of most desktop apps, have three Open menu items, one for each data group (e.g., Open Customers, Open Inventory, Open Orders, or maybe just label them Customers, Inventory, Orders). Do not use a cascade menu unless adding a bunch of Open Xs makes your File menu very long; 15-20 menu items are acceptable. Redundant toolbar buttons for opening each window may also be a good idea.
There’s no reason you can’t open all three windows by default when the users execute the program if they indeed use all three equally in a given session. If they tend to use one window per session, you can provide a dialog at start-up (perhaps integrated with a splash window) with command buttons to select the starting window; or you can eliminate the extra step of a dialog by putting three shortcuts in the Start Menu at installation, one for each window. If there are nonrandom variations in what windows are used when, you can alternatively automatically open whatever windows were open in the last five seconds of the previous session. If there are individual differences in window usage, and you have some way of knowing which windows a particular user tends to use the most (e.g., from their job description), then set the default window(s) at installation. If all else fails, provide users with an option/preference to select what window(s) to open at start-up.
One other thing: as a desktop app, use edit-in-place. Don’t make users click an “Edit” link or button to change a database record, like so many web apps do. Let users make the record change right there in the table in which the data is shown. This makes interactions simpler and faster, and reduces the complexity (number of windows) of your app.
http://richnewman.wordpress.com/2007/10/26/user-interface-design-for-business-applications/
Turns out what I'm after is an "MDI" (multiple document interface) even though the documents aren't necessarily of the same type. This article covers some of the common MDI styles and wraps up with a good suggestion.