Organizing and Arranging the Windows


If your program has a main window (that is, a user interface!), then you’ve probably already got problems. Why? Because most programming tools these days make it so easy to create windows and organize controls that the tendency of most people is to simply throw together the user interface without giving it a lot of thought.

Here’s a pretty good rule of thumb, however:

RULE

The amount of time you put into planning and designing the user interface for its usability is inversely proportional to the amount of time you (or the support staff) will spend on the phone fielding complaint calls and fixing all those problems the users complained about.

How does that sound? Personally, I like the idea of creating nice, solid, clean, useable software. In the sections that follow I show you how to do this.

The Usability Differences between Dialogs and Windows

You’re a programmer, so of course you know what the difference between a dialog box and a window is. However, what I want to show you in this section is when to use a dialog box and when to use a window from a usability standpoint.

Note

If you’ve worked with the Microsoft Foundation Classes (MFC), you’re well aware that you can use a dialog box as your main window. The Windows API even has a support function for doing this. When you use a dialog box for the main window, you end up with either a small utility that looks just like a dialog box (such as a Control Panel applet) or a window that has no resemblance to a dialog box. In the case of the latter, I would consider your GUI a window and not a dialog box; you simply used the dialog box features of Visual C++ to lay out the controls in your main window.

For my definition, I will consider a dialog box to be a modal dialog box. (Modal, of course, means that when the dialog box is open, the main window behind it is not functioning as it awaits a response from the user through the modal dialog box.)

What about modeless dialog boxes? They’re a very, very, very bad idea. If you have a reason to open a second window while the user can still access the main window, then what you have is an auxiliary window, not a dialog box.

The purpose of a dialog box is to immediately receive input from a user. For example, when you connect to a website that uses HTTP authentication, a dialog box will open letting you type in a user name and password, as shown in Figure 3.1. The browser needs this information quickly, right here, right now, and thus used a dialog box.

click to expand
Figure 3.1: This dialog box wouldn’t make sense if it were modeless.

Now imagine if the user name and password dialog box were modeless, allowing you to switch back to the browser window. Would that make sense? No, because once you were back at the browser you could surf to another page, and then what purpose would the user name and password dialog box serve? See, the problem is that when the user clicks the OK button, the user expects an action to occur and the dialog box to close. If the user clicks the Cancel button, the user expects her changes to the dialog box (what she typed and so on) to be forgotten and the box to close.

Now think about a modeless dialog box. Suppose you have a Font dialog box that is modeless. When the user changes the font size, will the change happen automatically or only after pressing the OK button? Either way, once the changes are made, what happens if the user clicks the Cancel button? Will the changes be undone? It isn’t perfectly clear.

Therefore, here’s a rule to follow:

RULE

A dialog box is a modal window that allows the user to quickly enter information. Further, a dialog box has an OK button that the user uses to approve the input and a Cancel button that the user clicks to give up the changes she made inside the box. Finally, the dialog box might have a Help button.

If you think you have a need to allow for a dialog box to be non-modal, then rethink the interface. Do you want a secondary, auxiliary window? Maybe. Or do you want a pane? That sounds like a good idea, too. Or maybe a floating toolbar? Excellent. But please, not a non-modal dialog box.

So all this is great for the usability of a dialog box, but what about the main window? The main window does not have an OK or Cancel button. The main window has a menu that includes a File menu with an Exit item. The main window also has a close button in the upper-right corner. The main window doesn’t stay on top of any other windows like a dialog box does.

Tip

Some usability experts say not to use a dialog box for the main window. I agree, with one exception. I’m fine if a simple little utility program uses a dialog box, provided an OK and Cancel button make sense for the utility program: The OK button should make the changes, and the Cancel button should actually prevent any changes from being made. A good example is the Display Properties program in Windows.

The Great Debate: MDI, Tabs, Separate Windows, and Panes

This section applies primarily to Microsoft Windows. One of the great innovations of the late twentieth century wasthe Multiple Document Interface! (Or you can just call it MDI for short, but you pronounce it em-dee-eye, since MIDI (Musical Instrument Device Interface) gets the honors of being pronounced middy.)

To be honest, however, the MDI approach actually wasn’t such a great invention, and it never quite took hold. The idea was that you would have one main window, and inside that main window you would have all your document windows. Each document window would hold a separate (you guessed it) document. What’s a document? A document is a single file or distinct set of information that the user works on. An Excel spreadsheet is a document, a word processing file is a document, and so on.

You could maximize your document windows within the single main window, or you could minimize them, again all within the single main window. You could arrange the document windows however you wanted, and you could even use the Cascade and Tile menu items that would move the windows around.

Let’s talk briefly about these Cascade and Tile menu items and why they don’t really work all that well. The Cascade item arranges your windows in a nice and neat fashion, letting you see the title bars of all your documents, as shown in Figure 3.2.

click to expand
Figure 3.2: Cascade arranges the windows nice and neat (to a point).

Note

Remember, my goal here isn’t just to nitpick all the software out there while you sit back and say “Bummer,” since you’re unable to change what Microsoft or some other vendor does. Rather, the point here is to help you decide whether you want to use the MDI approach in your own software, after you recognize the drawbacks.

Many people would use the Cascade feature a few times because everything looks nice and neat. But it has a basic fundamental flaw: Take a look at Figure 3.2, which shows several MDI windows cascaded. Click on the upper-rightmost document window (which is also the one in back), and now you can’t see any of the other windows. Or, if you click on one in the middle, half the windows will be obscured, making an even bigger mess. Or if you have lots of windows for a simple cascade, the windows will start getting doubled up, as shown in Figure 3.3. In this figure, if you count the lower-left corners you realize you can see only seven windows. But there are, in fact, nine. Window number 8 is aligned exactly the same as window number 1, and window number 9 is aligned exactly the same as number 2. What a mess.

click to expand
Figure 3.3: Cascade starts to become too confusing when you have lots of windows.

The Tile menu item is nearly useless. Since it makes sense only with more than one window, if you tile two windows, your whole main window will get divided in half, and each of the windows will be either very narrow and tall or very short and wide, depending one which Tile method the program uses. For most applications, this isn’t very useful. Add a third or fourth window, and you’ll have no room to speak of for each document window. Nobody uses Tile (at least nobody I know), because it makes the windows too small to be useful. Figure 3.4 shows six windows tiled. Each one is really little and not particularly useful. (And imagine if each child window had several controls, or maybe a toolbar at the top.)

click to expand
Figure 3.4: Tile isn’t very useful with more than a couple of windows.

Nevertheless, you can still create MDI programs. Microsoft’s development tools let you specify MDI applications quite easily. For example, the MFC Application Wizard lets you specify Multiple Document Interface. Borland’s Delphi, as another example, has an MDI project type available when you create a new application.

Another problem with MDI is it’s too easy for users to lose track of the document windows, with windows hidden behind others. But worse, the document windows don’t appear in the main taskbar. The main taskbar shows the programs. Once you open the window, you see an icon. But what is an icon? In earlier versions of Windows, it was just that: an icon just like you would see on the screen. But in newer versions of Windows, these supposed icons aren’t icons at all. They’re little horizontal bars with the name of the window and a little icon imprinted on it. Nevertheless, the windows are minimized to an iconized version. This is an outdated model. Think about it: Where in Windows XP do you see windows that are minimized to icons? You don’t. They get minimized to their appropriate button on the taskbar. The notion of being minimized to an icon hasn’t been around since Windows 3.1!

But now that I’ve trashed the whole notion of MDI, when should you use MDI? While I don’t recommend using it at all, most of the experts agree that MDI is acceptable if you’re building an application with a single document window type. For example, if you’re creating a spreadsheet program, and each document window is a spreadsheet, then fine.

However, I would like to suggest some alternatives to MDI. First, take a look at the way Microsoft Word handles its windows. It’s one application, yet the separate document windows appear as separate buttons on the taskbar. Further, each document window has the feel of being an entire instance of Microsoft Word. In fact, you can’t really coerce Word into running multiple instances. Instead, you’ll just get another document window within the same instance of Word. (You can verify this by looking at the Task Manager; you’ll see only one instance of WINWORD.EXE. Yup, it’s still an 8.3 filename.)

If you plan to have multiple document windows, I recommend making your windows separate so that the individual windows appear in the taskbar, as Microsoft Word does.

SUGGESTION

Having multiple separate document windows has the advantage that the user can easily navigate to the individual windows strictly through the taskbar, without having to first navigate to the program and then through a bunch of document windows.

But what if you really do see a need to have everything in a single window? I still don’t recommend MDI. Instead, I recommend the following two options:

  • Tabs Use the tab control to show a series of tabs at the top of the window, with each tab representing a document.

  • Panes Divide your window into panes using sliders.

In the following two sections I discuss these two alternatives.

Designing Tabbed Windows

Figure 3.5 shows an example of tabs. This is a program called SciTE, which is a free editor that I personally use a great deal. (You can find it at http://www.scintilla.org if you’re interested.) This program can hold multiple source code files (which are documents in this case), and it includes an option for displaying each file as a separate tab.

click to expand
Figure 3.5: The SciTE editor has a nice tab bar across the top.

Typically when you create a tabbed window, you don’t create a separate window for each document. Instead, you have one window maximized inside the main window. The tab bar across the top is itself a single control showing multiple tabs.

You would, however, have each document loaded in memory. (Some people prefer to use memory-mapped files right on the document file. I wouldn’t attempt this on anything but your own proprietary file format, though, because Windows sometimes pads memory-mapped files with extra bytes at the end.)

Next, you would have code that responds to the user clicks of the tabs. Check which tab the user clicked, and then display that particular document in the main window. The easiest way to do this is to have a C++ class (or whatever language you choose) for the documents. Create a separate instance of this document class for each document, like so:

 class Document {  protected:      // member data about the document,      // such as filename, etc.  }; 

Then, have a singleton class containing global information about the program, including the active document, like so:

 class GlobalInfo {  protected:      Document *ActiveDocument;      void Update();  public:      void SetActiveDocument(Document *);  }; 

This active document would simply be a pointer to the document class. Then when the user switches to a different document, you simply change the value in the active document pointer. (Depending on your GUI library, either you would associate an instance of the Document class with each tab right in the tab class or you would maintain a separate association, perhaps through an instance of the standard map template class, mapping either the tab name or tab ID to the Document instance.) Next, have some kind of an Update function that re-renders everything, call it, and you’re rolling.

Designing Split-Paned Windows without the Pain

First I want to apologize for the pun in the title. I couldn’t resist. Anyway, the idea of a window divided up into panes is a relatively new idea compared to the bizarre MDI approach. One place you see panes is in both of the two big browsers, Internet Explorer and Netscape Navigator. Figure 3.6 shows an example of Internet Explorer divided into two panes.

click to expand
Figure 3.6: This is an example of two panes separated by a splitter. (Just don’t use some silly animated dog, like they did here, please.)

When you click the Search button, for example, in IE 6.0, you see the window divide into two parts, as shown in Figure 3.6. Notice that the left pane contains a search window, and the right pane contains the usual browser window. But the cool part is what’s in between the two panes: a moveable splitter control. If you hover your mouse over the line between the two panes, the mouse pointer turns into a horizontal line with an arrow on either end, like so:

When you hold down the mouse, you can adjust the sizes of the two panes by sliding the splitter left or right.

I call this approach to design the split-pane approach, because you are using splitters to divide your window into multiple panes. You then place different content or controls in the different panes.

But don’t be fooled. Although programming a splitter is easy (especially in both MFC and Borland C++Builder, for example), designing a well-thought-out split-pane layout is not easy.

Notice two things about Figure 3.6:

  • Each pane has a totally separate purpose. The left pane is an auxiliary pane to assist in working with the other pane, which I call the main pane (not to be confused with mane pain, which is when a horse has a bad hair day).

  • The user doesn’t have to stop using the main pane in order to do a search.

In other words, the left, smaller pane serves as a helper, while most of the primary work takes place in the larger pane. Imagine, however, if both panes were equally important. How would the less-savvy user react? Most likely he would look at it, wondering which pane he’s supposed to use. In other words, he would be confused.

RULE

When dividing your window into panes, have one main pane, with the other panes serving as auxiliary or helper panes.

Microsoft has explored the use of panes in some of its products, Outlook, for example. Figure 3.7 shows several panes at work in Microsoft Outlook.

click to expand
Figure 3.7: Outlook has several panes, and you can choose which panes you want to show.

One important feature in Outlook is the way the user can choose to close various panes. (This is also true of the search window in Internet Explorer.) For example, I don’t use the pane to the left (the one with the icons) very often, so I usually close that. This brings up another important rule:

RULE

If a user doesn’t want to use a certain pane, let the user close the pane. But don’t forget to include a way for the user to bring the pane back!

Windows Explorer (not Internet Explorer, but the file folder utility) also uses panes in an interesting way; the pane to the left shows property information about the currently selected item in the main pane. This is actually part of an important topic that I talk about later in this chapter, in “Avoiding Modal Dialog Boxes When You Can.”

Let Them Be Free! Custom Layout

If you are writing a program that has multiple child windows in it, and the user is free to move the windows around, please be a good neighbor and include within your program the capability of saving the layout. If the user moves a window, please have the program remember where that window was the next time it starts up.

Now some people even take this a step further and let you give a name to the layout. If you’ve used some of the Borland development tools, you’ve seen how this works. Borland Delphi, for example, lets you name the current arrangement and layout of windows. Then you can move them around and create another name. After that you can type either name into a little text box, and the windows will all move into place for that particular name.

My feeling, however, is that this is overkill. In the case of Borland products, it’s acceptable, because sophisticated users (programmers, actually) are using the products, and they can handle (and even require) somewhat more complex possibilities. But for the typical end user, providing a way to save different layouts is a bit much.

Keep it simple. If you’re not creating a development too, then just save the layout when the program ends and read it back in when the program starts back up.

Remember, however, to do this on a per-user basis. As I’ve mentioned before elsewhere in this book, if you’re using Windows, for example, you can save your information in the HKEY_ CURRENT_USER portion of the Registry.

Avoiding Modal Dialog Boxes When You Can

Earlier in this chapter, I spent a great deal of time talking about modal dialog boxes. Later in this chapter, I have more to say about them in terms of how to create the controls on them in a sensible manner.

But now I’d like to pause for a moment and suggest a different approach. Think about what happens when a modal dialog box opens: The entire application comes to a halt. If the dialog box is requesting information, and the only way the application can possibly continue is if it gets this information, then that’s fine. But what about an information-only dialog box?

Consider Internet Explorer, for example. Suppose the web page I’m looking at has an image on it, and I right-click the image and choose Properties. Here’s the dialog box that I will see:

click to expand

First off, why does this dialog box have three buttons, one of which is grayed out? Is there a difference between OK and Cancel? Considering that the dialog box is requesting no input from me, no, there is no difference that I can see. But besides that, does this information really have to be in a dialog box? What if I want to find out the URLs of two graphics and compare them? As it happens, you can actually highlight that little URL on the dialog box, right-click, and choose Copy. (I honestly didn’t know this until about a year ago somebody did it in front of me and I was quite shocked.) Look at this:

click to expand

I’m sorry, but this is just a little bit too bizarre for me. If I want to compare this URL, I can open Notepad, paste the URL into Notepad, then return to IE, close the dialog box, open the properties for another image, copy its URL, paste it into Notepad underneath the previous URL, and finally compare them. And worse, what if the image whose URL I want to compare the previous URL to is on a different web page that I need to surf over to?

Yuck. Wouldn’t it be easier if IE just gave you this information somewhere either in a floating auxiliary window, or maybe in another pane, or perhaps on a toolbar or status bar, and you could configure whether you wanted to see this information? Why should it be in a dialog box? (And oddly, the Windows Explorer application—the one for looking at folders—does show its properties in a pane off to the left.

RULE

If you create a dialog box that is strictly for information purposes, providing no place for user input, then stop! Don’t make it a dialog box. Instead find someplace else to put the information, such as in a pane or in an auxiliary window.

Keyboard Shortcuts and Windows Navigation

I’ve talked a great deal about keyboard shortcuts in this book so far, and I have more to say about them. The reason is I consider keyboard shortcuts highly important. And the keyboard shortcuts for navigating between windows are no exception.

If your program has multiple child windows, please accept the default window manipulation keystrokes. Here are those two keystrokes:

  • Ctrl+Tab moves to the next window.

  • Ctrl+Shift+Tab moves to the previous window.

Now unfortunately, Microsoft doesn’t use these rules anymore. They use Ctrl+F6 to switch to the next window and Ctrl+Shift+F6 to switch back. Unless you have hands the size of a gorilla’s, you need to use two hands to press these keystrokes. That’s not good, especially considering there will certainly be people who try to do the keystroke acrobatics with one hand. Then with their other hand they’ll get hold of a good lawyer, and you’ve got a problem on your hands. Again, not good.

SUGGESTION

If you have a command for window switching, allow the user to customize which keyboard shortcuts move from window to window.




Designing Highly Useable Software
Designing Highly Useable Software
ISBN: 0782143016
EAN: 2147483647
Year: 2003
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net