Skip to content

MDI Programs & Interface Design

Hello all, and welcome to my article on the art of writing good MDI programs and Interface Design.

Before I get started, there is something you should know; I am a blatant hypocrite. In many of my programs (most notably SLCI), I have completely ignored many of the rules that I will present in this document. However, there are reasons for this, and I will try to explain not only what rules I use for writing Multiple Document programs, but also when I break them.

I’ll start off first with a brief definition of what a MDI program is, before moving onto the different types, then the different forms of navigation, and only then will I get to interfaces (that section is more of a coda than the focus of this article).

#1What is a MDI program?

Quite simply put (and my definition of MDI is much more vague than the official one, but that allows me to cover more interesting things in this article), and MDI, or Multiple Document Interface program, is a program in which you can have more than one document open at once.

That’s it.

Does it seem so terribly complex? (“No! That’s easy! ” I hear the many little people inside my head reply : ) )

The only thing most people have to worry about is what type of interface to use, and how to implement it. However, even that is not usually difficult, as once you know what the program you will be making does, a certain type of interface will start singing out to you, begging you to make use of all the features which only it has :^)

#2:Why use MDI interfaces?

It’s true that recently SDI (Single Document Interfaces; they can only have one file opened at a time) programs have been seen as the better way to go as MDI programs can very easily distract the user from the program itself as they fiddle with the interface. Another thing is that some MDI interfaces can use up a large portion of your screen, which is bad.

#3:Types of MDI interfaces

Generally, when programmers think of MDI programs, they think of the standard type, (confusingly) called MDI (remember when I said that my definition was a bit vague; well this is the standard interpretation of it. I’ll call them Definitive MDI’s from now on to avoid confusion).

DMDI

DMDI programs are easy to find, but I’ve put a picture of one below (Paint Shop Pro 7 by JASC):

The main thing which makes a DMDI program a DMDI program is the fact that Documents are created in little sub windows (windows within windows :^) ), it has NOTHING to do with floating toolbars, no matter how pretty they are.

The main advantage to this is that when any document is maximised, there is no visible sign of the DMDI interface, other than the second set of Minimise/Maximise/Close buttons under the main set.

Another advantage is that you can work on two documents side-by-side and compare/contrast them. This feature really lends itself to graphics programs.

MDI programs are very difficult to create with standard win32 procedures, but are easy to make with Borland Delphi (and C++ builder, if you are feeling illogical : ) ), and almost identical (in terms of coding) to SDI programs in MFC.

WORKSPACE

This is really just an alternative take on the DMDI interface. With a Workspace program, you can only open one document at a time, but it can contain multiple parts, which are displayed in separate windows. Quite a few programs take this approach, such as Visual Basic, Microsoft Visual C++.

As a slightly less obvious example, Calagari Truespace 3 is pictured below (notice how there are two separate windows, each showing a different view of the sphere):

NOTEBOOK

Notebook interfaces are probably one of the more difficult interfaces to implement, if only because they are not directly supported by any programming tool that I know of (yet).

Notebook interfaces put every open document on it’s own tab in the tab sheet which usually can be found occupying the top or bottom portion of the window.

POV-RAY makes great use of this interface, and is pictured below:

PROJECT

Project interfaces are similar to DMDI ones, except there is no top-level frame. This means that you have loads of free-floating document windows usually managed by a single free-floating toolbar.

I generally avoid these interfaces, as they are so difficult to program properly. For an example of a terrible project interface just take a look at GIMP (www.gimp.org I think). It’s a great program, but has an appalling interface. Not only do you get loads of windows occupying your desktop, but each one also creates a new icon on the taskbar. Although I can see why this would be done in theory (to allow you to easily change between documents), in practice it doesn’t work (especially when you have other programs running at the same time).

Now, for an example I will the amazing freeware graphics program which goes by the name of “The GIMP”, let down only by this interface (hey! if I only ever showed you examples of good interfaces, you would never know how not to use them : ) )

SDI

There is another alternative to all of the interfaces mentioned above. Simply have a SDI (Single Document Interface) program create a new instance of itself every time the user creates or opens a new file. If Microsoft Word can do it (at least in the 200 edition which I’m using), then it must be good : )

Seriously though, it does have some good things going for it. It’s easier to code in the lower lever languages, and that’s as good a reason as any to use it.

#4:Getting Around/Lost

How to let the user navigate your program can be very difficult to decide.

STANDARD DMDI

You could just use the normal DMDI interface, which is fine so long as you keep in mind the little protocols which Microsoft have established (I said keep in mind, not obey. Feel free to replace them with better alternatives, but they should be there in some form).

You should be able to switch between windows using the windows menu, or some other menu, as well as have all the window formatting options (cascade, tile) available.

This is automatically implemented in MFC, Delphi, Visual Basic, and most Visual programming utilities that have MDI wizards/templates.

TABULAR

I’ve covered this already up where I described notebook interfaces. I don’t like repeating myself.

LISTBOX/TREE VIEW

This is becoming a very popular option for all types of programs, particularly when you might have many Documents in the one project and you want to be able to switch thorough them quickly. Microsoft Visual C++ is a great example of this interface being used well, and you can find a capture of a bit of the interface below (because it is so easy to switch between files, I use it to edit this web-page).

Also, apart from navigation they are great for storing libraries of data, because they can be categorised in an explorer type interface and accessed easily. A shareware tracker (music program) called Modplug uses this very well, and the relevent part of it’s interface is depicted below.

#5:Alternative Interfaces

There are so many programs around which completely ignore the windows interface. Now I feel a very important question must be asked. Why? Why put so much time and effort into designing an interface from scratch when you could just use the standard Windows stuff?

· To keep interfaces the same amongst multiple operating systems (macromedia esp. has become very fond of this, and not only keeps the interface the same across operating systems, but across their products. I personally feel that it is better to (if you have the time) devote one interface to one program. This means that it will be (
usually) the most efficient (for both the programmer and the user) possible).

· To make sure that the look of your interface will not change when windows upgrades next (esp. important because so many compatibility problems can arise when you run programs designed for one version of windows on another version).

· To make your program look nice. (This is a bad reason. Do not put more effort into making a nice looking interface than you have to, especially if it offers no benefits over the standard one).

· To make your program easier to use and more user friendly to use (it has to be said that although the standard windows interface isn’t that daunting to use, many people feel that sometimes it is easier to design a new interface from scratch than simply alter the windows one to work with your program).

Examples:

Blender

: Not only does it look strangely un-“Windows-like”, but also the interface is completely customisable. You can add and remove splitter bars to your hearts content and change the function of every frame. This is a good example of optimised functionality, where the interface has been built completely around the program to ensure maximum efficiency.

Flash 5:

I dislike this interface because (as I have explained earlier) was not made for Flash (or windows), and therefore does not take advantage of all the features available to it (most annoyingly in my opinion is the fact that the toolbar’s can dock and just float around aminously, blocking your view).

Microsoft Word 2000:

I never really regarded myself as being “pro” Microsoft before I started writing this article, but I guess that I honestly feel that they have designed some amazing software. Anyway, I love the assistants (trying to make something like it for SLCI ), and the “intelligent” menu-bars are a very good feature too (the copy/paste system is also worth mentioning).

Fruity Loops 3:

I love this program’s interface. It is very easy to use, although I have a feeling that the programmers are finding it a bit restrictive now that they are adding more complex features into newer versions. However, one the nice things about coding your own interface is that it’s not that hard to change if you want to : )

SLCI:

I’m sorry, but I couldn’t resist putting my own program in here. It’s not amazing, but it has a nice status & tool bar and the interface also changes depending on what you’re doing to ensure the user gets the maximum workspace possible depending on what they’re doing. I have included 2 images, to show just how much the interface can be changed (and how the interface gets rid of unnecessary buttons and bars when you are working on different types of documents):

#6:Computer Games and Interfaces?

In my experience, some of the best examples of interface design can be found in computer games, where usually the interface is built from the scratch up (nobody wants to “play” a windows program, they want to play a game).

Computer game programmers have to implement ways of controlling what is happening on screen, and this is one of the most important aspects of any game. The example I will give for a successfully implemented and well thought out control system is “Homeworld”. This game made it possible to easily command things through a plane-less space (i.e. there is no “ground” that you can just click on).

Well, that’s about all I have time to say about that right now. I’ll add more when I get time.

[“ACTUALLY, THIS IS VERY MUCH A DEAD ARTICLE”: icecube]