Window Management

Published 2015-06-08

This is part 3 of a series called "Windows 95 Style Guidelines You've Probably Never Heard Of".

As much as I'd like to pretend we live in a perfect world where the most complicated program on the planet is Notepad, we don't. We have to worry about complex applications. The thing about programs is that their job, at the end of the day, is to manipulate data. (Note that we're specifically talking about applications that handle data. One-shot tool applications like Calculator are typically singular windows anyways, so most of this wouldn't even apply.) There is nothing stating how much data to manipulate, or how that data is organized. The GUI needs to be stupidly flexible for stupidly esoteric file types. These are some of the ways the Windows 95 Team decided to tackle the representation of the most common types of files.

Singular Windows

Example: Notepad (Screenshot from GUIdebook)

The most simple way for an application to handle windows is for one application instance to have one window, which handles one file, and have that be it. It's a one-to-one relationship between object and the window. The idea with this sort of application is that when you open a file, the file opens. Not the application tied to the file, just the file. This is (or was supposed to be, anyways) how the majority of applications work. This is also the type of file most in line with the file-based system the Windows 95 guys were going for. However, needless to say, it's not perfect. Specifically, if a file contains more than just a single field of data, you're pretty much done for. Of course with enough window-splitting trickery you could make it do anything, but there are definitely more efficient ways to accomplish that kind of stuff.

Multiple Document Interface (MDI)

Example: Photoshop, HxD

The idea behind an MDI is that a "parent" window holds several "children". These children are stuck inside the parent and cannot leave it. With an MDI the children represent separate documents with the parent holding a common toolbar and/or menu interface.

This is rather close to how old pre-MultiFinder applications worked on the Macintosh. With the old Macintoshes (such as the Mac 512K), you could only have one program open at a time. This program, while it was open, took control of the top menu bar. Essentially it turned the desktop into a huge MDI parent window. From there you used the parent menu to preform all the actions needed in the program, such as opening up documents or saving them. When you were done, you closed the program from the menu so the System could restore control back to the Finder.

The thing about the Macintosh is that once the concept of multitasking came along with the MultiFinder, a lot of the context for applications went. You could switch from one application to another completely different one with only the top menu bar changing. It becomes disorienting quickly with a large number of files. And the idea of "multiple files in one application" became a bit weird once you closed all the files, as you had this program not represented by anything just sorta lingering there until you killed it.

This is a common problem on Macintoshes to this day as people just leave running applications on the Dock to eat up resources for no reason. MDI was Microsoft's take on making this type of interface function a bit smoother in a multitasking environment.

An oddity with Windows 95's (or at least this style guide, anyway) related to opening files from the file manager. If you open a file, the application's parent window opens with the document as the child window inside. If you open another document, a completely different parent opens with the document inside. They say that this is because the documents could be destructive things like macros, but really if you think about it having several parent windows with one child each is a bit silly.

A lot of MDI applications these days are not the typical "true" MDI applications with separate child windows. These days they tend to be represented as tabs. Think programs like a web browser or Notepad++. The children are still there, they just are represented using a workbook-like interface. (I will explain them in a moment.) Note that these are not true workbooks as workbook tabs are separate subfiles stored as one file, while tabs in MDI programs are separate files entirely.

Workspaces and Workbooks

Example: Excel

On the topic of MDI programs, there's workspaces. They're... well, I'll just show you.

Yeah. They're MDI except the parent window can store things. It seems to be described as some sort of encapsulated desktop-like thing that can hold multiple files. These "files" are parts of a larger file that is the sole priority of the application instance. I cannot think of a single application that uses these in this fashion. However, the style guide goes on to describe the work_book_, something you're probably a bit more familiar with.

Workbooks follow the same idea of file encapsulation, except instead of files being stored in a desktop-like thing, they are stored as tabs. The best example is a spreadsheet program, where the workbook file contains multiple worksheets. Going back to workspaces, it's pretty much the same concept, except the "worksheets" can be stored a bit more freely. Unique concept, to say the least.

Projects

Example: LabVIEW

In a vaguely similar vein to workspaces are projects. Projects are a lot like workspaces in that there is a parent object that contains all the files of the "project". The big difference here is that the children of the parent are independent from it. They're allowed to be opened, closed and focused without altering any other windows. (By the way, LabVIEW is probably not the best example here because you cannot work on one window without working on every window, which is rather annoying.) However, if you minimize or close the parent window, all the other windows go as well. When you reopen or restore the parent window, all the other windows that were open come back.

Another difference is that projects, generally speaking, tend to have a more hierarchial style to them. The things in the project are usually represented in a tree view or a list view that opens up other lists. This allows for some more definite structure than the madhouse of the typical workspace.

But which one is the best?

The answer depends entirely on what you're doing.

I know, copout answer, but it's the truth. I can't, for example say "always use a project" because a lot of things just are not projects.

For single documents that do not contain any other files, your choices are single-document interfaces and MDI. To choose between these, the question you have to ask is "Can the user use multiple documents at the same time?". For example, in an application like HxD (a hex editor), you are often comparing files to each other. You really can't do that with a single-document interface. As each window is a separate instance of the application (usually), there is no easy way to get windows to communicate with each other and even less way to visually signify that they are even doing so in the first place.

Something like Photoshop, on the other hand, is an MDI for a completely unrelated reason. It needs to conserve screen space. Photoshop has a lot of toolbars and palette windows and stuff that would take up a lot of screen real estate if they were duplicated for each document. This is probably less important today with 1080p screens compared to the 640x480 displays common when this style guide was written, but it still can be a concern. Personally speaking I'd say that if you were going with an MDI for this reason you should probably work on simplifying your interface first so the UI isn't such a huge monster, but that's just my personal preference. If you need an MDI, use one.

For the other 3 (Workspace, Workbook, and Project), it's a lot easier. Workspaces as described here don't really exist anymore; they're more like projects fused with an MDI these days. (Like MS Access, etc.) Use "workspaces" over projects in the same circumstances you'd use an MDI over a single-document interface. Workbooks are basically workspaces for a small amount of files or views of a file. You lose the separate window management and cohesive organization with the added bonus of speed. Use it when the subfiles are of the same type and aren't huge in quantity.

Of course, these are by no means set in stone. It's been 20 years. Obviously they've come up with new ways to manipulate the elements that make up a file. Take, for example, the modern tabbed web browser. It's sorta an MDI as it handles multiple webpages in one window, but it's sorta a workbook as the webpages are represented as tabs and do not have their own window borders. And then you get into stuff like web and mobile apps which have an entirely different take on user interfaces altogether. But at the end of the day it's worth thinking about how you present your application, even if it isn't 1995 anymore.