UI_design_for_multiple_views

User-interface design for multiple views

This article discusses the drawbacks of the deprecated MDI model and then looks at the alternative models for modern UI design for multiple views, and in particular, the features in OWLNext to support such models.

• User-interface design for multiple views
  • MDI and its drawbacks
    • What does MDI provide?
    • Drawbacks of MDI
      • Inelastic sizing and positioning in an unconstrained virtual workspace
      • Overlapping windows
      • Wasted client background area (workspace)
      • Ill-suited for utilising multi-screen setups
    • Benefits of MDI
      • Full-screen virtual desktop
      • Unlimited layout possibilities
    • What not to do - MDI hacking
      • Override clipping
      • Override the child style and behaviour
      • Automatic tiling
  • Alternatives to MDI
    • Panes using TLayoutWindow and the TPaneSplitter descendant
    • Free-floating views using frame window and docking classes
    • Tabbed windows using TTabbedWindow

---

MDI and its drawbacks

The Multiple Document Interface (MDI) model is the solution often applied in legacy OWL applications to provide multiple views of application data, optionally based on the DocView model. See MDI Windows in the OWLNext documentation. In OWLNext, the MDI components are represented by TMDIClient and TMDIChild.

What does MDI provide?

For the full specification of the Windows Multiple Document Interface see the MSDN documentation. Alarmingly, the documentation starts off with this statement:

Many new and intermediate users find it difficult to learn to use MDI applications. Therefore, you should consider other models for your user interface.

With this warning in mind, let us consider a summary of the standard MDI features relevant to our discussion:

1. Multiple views of application data.
2. An unconstrained virtual workspace (possibly larger than the application window and the screen) in which child windows are freely sized and positioned by the user in a fixed client coordinate system (i.e. inelastically).
3. Simple functions for tiling and cascading the children within the available space of the application window, as well as arranging minimized windows (icons in the old days).
4. Command merging for the main menu and toolbars, so that only the commands applicable to the active child window is presented by the application.
5. UI merging, e.g. removing the frame when maximizing a child within the workspace.
6. Keyboard short-cuts for navigating between children and accessing system menus.
7. Menus for navigating between children (system menu and automatic list on the Window-menu).

Of these, we are here mainly interested in feature 1, support for multiple views. It is likely that few applications need or want feature 2; a virtual workspace replicating the desktop model. And without feature 2, feature 3 has little or no relevance. The rest of the features are useful and applicable to other models as well.

As we will discuss below, most of the MDI drawbacks stems from the virtual desktop model it imposes on applications.

Drawbacks of MDI

The MDI model has many drawbacks, in particular the inelastic sizing and positioning of the child windows in an unconstrained virtual workspace, overlapping windows, wasted screen space and non-support for multi-screen setups.

Inelastic sizing and positioning in an unconstrained virtual workspace

Fixed positioning and sizing of MDI children leads to cumbersome window arrangement and awkward workspace scrolling. Arguably, inelastic sizing and positioning mostly makes sense on a fixed-size screen, in which you have too much space. E.g. consider a calculator application on a 24 inch screen. You want to make that window small and freely movable around the screen (and between screens, if you have a multi-screen setup). On the other hand, inelastic position and size of a window within the MDI workspace is inconvenient when sizing the application window. As the application window is shrunk, the calculator may end up outside the visible area and be clipped, leading to the need for the dreaded scrolling of the workspace.

Constraining the children, using elastic sizing and positioning, is a more sensible approach for resizeable application windows. Most users probably prefer not to use the virtual workspace and to stay within the bounds of the application window.

Overlapping windows

Overlapping should arguably only be used for modal dialogs, pop-up notifications and tip texts. The cluttering caused by overlapping windows is confusing and increases the chances of user error; such as clicking on the close button for the wrong window and dragging the wrong window edge. Overlapping also hides information and controls in the obscured window, making user interaction awkward.

Modern UI philosophy is moving away from overlapping in general, e.g. see the Sugar interface for the XO computer, UI design guidelines for the new Modern UI in Windows 8, and other operating systems for small screens in the mobile space.

Wasted client background area (workspace)

The workspace background area serves no purpose, except when MDI is used as a virtual desktop in full-screen mode. And even in that scenario, the background is only there to serve as a placeholder (e.g. to be filled with an aesthetic backdrop image) when the children do not need all the available space. It is useless for application data presentation because it is (1) always obscured by the children, and (2) not scrollable independently of the children.

Elastic partitioning of the available space, using docking and panes, makes more sense for a resizeable application window.

Ill-suited for utilising multi-screen setups

MDI relies on full-screen mode to use all available screen space. Since the Windows UI does not have a maximize function to cover all the space across multiple screens, it requires the user to stretch the application window across all the screens manually. Heterogeneous screen sizes and resolutions makes this even more awkward. Often you do not even want to go full-screen. The user may simply want to move part of the application to a separate screen, while sharing that screen with other applications. In this case, full-screen mode is not a solution.

For effective multi-screen display, applications need to support detachable views or tool windows that can be moved individually to the desired screen.

Benefits of MDI

The MDI has some benefits for full-screen applications with its unlimited child window layout flexibility.

Full-screen virtual desktop

As an exception to the list of drawbacks above, the MDI interface may be suited for applications that are meant to be used full-screen, e.g. CAD applications. With a maximized application window the MDI workspace functions as a virtual desktop.

However, creating a nice layout of the child windows is still a manual and time-consuming chore, in contrast to elastic models for window layout.

Unlimited layout possibilities

Free sizing and positioning can allow window arrangements that are not possible with the binary partitioning used by pane splitting and docking. If the application also provides a function to save the window arrangement, the user can adapt the layout to individual projects, tasks and work-flows.

Unfortunately, this flexibility may only be exploited by orderly experts, while ordinary users may continue to grapple with cluttered window layouts. Also, the ultimate layout flexibility is just a theoretical observation. In practice, simple partitioning schemes covers all use-cases while being easier on non-experts and experts alike.

What not to do - MDI hacking

Now that we have looked at all the drawbacks of MDI, and highlighted how few advantages this UI design has, let us consider some pitfalls in trying to extend MDI to improve on it and provide missing features.

Override clipping

Simply overriding the clipping behaviour of the MDI machinery, i.e. make the MDI child extend outside the bounds of the MDI client, would not in itself be appropriate. Unless you made further customisation, the child window would still be defined in the MDI client workspace (coordinate system), and as a result, the child window would follow the movements of the application window. This would be inconvenient in most scenarios. E.g. consider the child window on a separate screen.

Override the child style and behaviour

You could perhaps override the standard MDI behaviour by forcefully setting the window styles for the MDI child. In this way you may be able to make the child an overlapped window defined in the screen coordinate space, and hence operate as a stand-alone window.

But then, what is the point of being a child of the MDI client? Now that the child has left the virtual workspace provided by MDI, you do not want it to partake in tiling or cascading, and the menu merging that MDI does for its children is probably inappropriate for stand-alone windows in most applications. For example, you probably do not want the main application menu to serve a stand-alone window on a separate screen, and have the menu change in response to the activation of the window, as happens with children within the MDI client area.

This leaves no purpose in being a MDI child, other than being included in the window list on the Window menu. It is probably easier to add a second list of "detached windows" to that menu, than to extensively override the MDI behaviour just to get that functionality.

Since the stand-alone window no longer wants the majority of the MDI behaviour, creating it as a MDI child makes little sense, and you probably should make it a separate window class.

Automatic tiling

You could try to eliminate workspace clipping and scrolling by automatic layout of the child windows without user intervention. Whenever the user resizes the application window, you could layout the children accordingly, using a scaling algorithm. Further, you could provide extended tiling functions, even automatic tiling whenever the user moves an edge of a child window.

However, this approach is working hard against the central UI concept in MDI; the virtual desktop. You may end up implementing a partitioning model (similar to panes) on top of the MDI machinery. It is cleaner, and probably simpler, to toss out MDI altogether and use docking and panes in the first place.

---

Alternatives to MDI

UI models based on panes, docking, tabs or free-floating windows will most often be better suited than MDI for any application. A combination of these approaches, as exemplified by IDEs such as Visual Studio, can provide a very flexible user interface, which is simultaneously simple to use.

OWLNext provides several helpful features to support multiple (document) views in your application without resorting to MDI.

• Flexible layout system and docking classes
• Panes based on the layout system
• Tabbed windows
• Free-floating and top-level window classes

The following sections discusses these features.

Panes using TLayoutWindow and the TPaneSplitter descendant

You should prefer a UI model based on elastic partitioning for the layout of the application client area. Docking and panes can be used to implement such a model.

OWLNext contains the powerful base class TLayoutWindow for laying out the client area of the window based on flexible constraints. The derived class TPaneSplitter provides binary partitioning of its client area, with support for dynamic resizing (splitters). The derived class TPaneSplitterView can be used as a base class for views based on the DocView model.

Free-floating views using frame window and docking classes

To support flexible use of large screens and multi-screen configurations, views should be detachable, i.e. allowed to move into free-floating frame windows, that could themselves be based on partitioning to divide their client area among different data views and interface elements.

A TFrameWindow parented by the main application window can be used to replicate the UI in a separate window, e.g. similar to the New Window function in Internet Explorer.

TFloatingFrame can be used as a base class for free-floating palette-style windows. The descendant TFloatingSlip implements a dockable version, useful for e.g. a toolbox or a property window. See the section "About the docking classes" in the OWLNext documentation for details.

Tabbed windows using TTabbedWindow

Tabbed windows can be used to support working with many individual documents, when the simultaneous view of multiple documents is not necessary, such as in web browsers and programming editors.

TTabbedWindow and its descendant TTabbedView can be used to present multiple documents or various application views of the same document in your application.