MDI vs SDI: The Real Scoop

Surprisingly this is something that is not clear for most designers, although the concepts have been around since late 80’s/early 90’s and often bandied about in professional tones of mastery–Only to be humbled by realizing the fallacies! Also this is not something exactly taught in design school (ahem). However, here’s the basic breakdown of what these concepts mean and why they are confusing…

MDI: Multiple Document Interface, meaning you have many document windows, with the menus, tool bars, palettes all separated out into their own windowed objects, all within the application container, or environment

SDI: Single Document Interface, meaning the document is consolidated into just one window that has the menu, tools, tabs, etc. all compacted into that windowed object (ie, the application container = the window object, with all functionality self-contained)

So what does all that mean, regarding Mac and WinXP?

1. Pseudo-MDI: On WinXP, each application’s document has a window but there is a general application level menu bar, tool bar, etc. On WinXP, closing the last window exits the app. However, on the Macintosh, because the application menu bar is shared with the Finder menu bar, there’s some confusion. You can have multiple document windows open but only one set of menu, toolbar, palettes that contextual update based upon which document is in focus.

2. True SDI: IE is pretty much the exemplar, with each IE window being self-contained, with its own menu, toolbar, history panel, etc.

3. True MDI: X Windows and NEXT, in which even the menu or document navigator is its own window floating with the document windows.

Design for the Other 90%

From IHT:

The numbers seem nutty. There are 6.5 billion people on this planet, 90 percent of whom can’t afford basic products and services. Half of them, nearly three billion people, don’t have regular access to food, shelter or clean water. Yet whenever we think, or talk, about design, it’s invariably about something that’s intended to be sold to one of the privileged minority – the richest 10 percent.

http://www.iht.com/articles/2007/04/27/arts/design30.php

Why So Many Design Flops?

From IHT:

The odd thing is that no one sets out to design something that’s mediocre. So why does design go wrong so often? Let’s set aside the rational reasons why projects can fail – like budgetary constraints, deadline pressure and lack of talent – to concentrate on the scenarios that should be easily avoidable, but crop up again and again, with predictably dire results.

http://www.iht.com/articles/2007/04/06/arts/design9.php?page=1

Gotta Know How it Works

This is what separates the pros from the amateurs–making design decisions by really understanding the construction aspects (ie, code issues), rather than purely aesthetic or other factors. That way, you’re helping to avoid unnecessary re-work, empathizing with the coder’s POV, mindful of the level of work involved, and just smarter all around. Doesn’t happen by itself or magically. Better know-how of the technical issues can also make for better arguments, so you don’t sound “wishy-washy” but firm when talking with Engineers.

Details Really Matter

Functional details can really matter and add up to either a horribly frustrating experience or one that is fluid, productive, sensible. For example, keyboard shortcuts for a date picker or in-field auto completion (similar to Google Suggest). Coding for CTRL + A, Arrow UP/DOWN, HOME/END buttons, etc. all add up big time for those power users who are data entry experts, 8 hrs a day, 40 hrs a week. They increase productivity and keep the data entry pro humming along swimmingly well, minimizing errors, and maximizing output.

Yes, it’s tedious, but working out the interaction details like tab, shift, control, spacebar, etc. can have huge dividends for your user cranking away at her job someplace…