From the first appearance of tabbed page controls, many software development shops experimented with paged application formats. These original, forward-thinking efforts had simple goals:

  • To localize and consolidate resources which could process many work instances.
  • To enjoy more natural navigation than was inherent to MDI, without even having to write a navigation system.

These readily achieved objectives were driven by tangible ways to improve MDI, and by an unmistakable opportunity to expedite development.

The tabbed format succeeded at these objectives for relatively simple interface designs and for small workspace populations. But even relatively modest page populations exceeded the practical envelope of tab based navigation. Substantial page populations meant tab systems which persistently consumed substantial workarea for the secondary purpose of navigation. Greater workspace populations would even consume entire desktop areas, leaving no room for the primary work of the application at all.

The consequence of our first efforts however, was not that we learned to limit an interface to so many rows of tabs. The sorts of problems we faced forced us to look hard at interface design, and what we learned was how important it was to preserve all possible interface area for the primary purposes of a GUI. Every time a user must scroll at all to vital controls or data, the redundant operation substantially degrades productivity. Navigation that would persistently consume minimal interface area became an obligation.

A further product of that study was actual measurement of how inefficiently tab based navigation negotiated substantial page populations. Because tab controls are forever re-drawing focused tab rows against yet another focused page, users studied a sea of vacillating rows over and over again, not finding navigation destinations. When people needed to focus another page, they regularly stared for great whiles as if the tab they sought had disappeared from the system. Given a substantial page population, tab-based navigation was not simply "single-click": It was a process of tediously finding destinations from an ever-vacillating sea; then clicking a destination tab which would immediately reorganize the sea yet again. Familiar, consistent order emerged as a further obligation.

The immediate experiments we could try had to use existing controls. We nested page controls to minimize rows and workarea consumption, even if this resulted in greater footprints and further navigation steps. As long as no more than two or three additional steps were introduced, users found destinations faster than they did in a sea of vacillating rows. They were soon imprinted with the motions for every (consistent) destination, and their negotiation simply became automatic.

Nonetheless, to minimize real steps wherever it was practical to do so, we built single-click shortcuts directly into pages. In this trial, an obvious further thing to do was, that if we had an Owner field in one page and wanted to focus the master Owner record in another workspace, that our shortcuts focus the targeted record as well. So useful was this Navigate+Focus approach, that it immediately became a standard, specialized interface feature. However, because the extrinsic conditions processed by this behavior were beyond the practical realm of prebuilt navigation, we further understood both that combined page navigation and data focusing processes are often the ideal way to negotiate an application, and that this is not a reasonable responsibility of a primary, prebuilt navigation system. It is the practical responsibility of developers to implement this specialized behavior in their applications.

A typical Navigate+FocusData shortcut (right of dropdown control) focuses not only the Owner page of a DataMaster module, but the targeted owner record.

As these AuxTools™ (right, top) implement bi-directional navigation, direct navigation shortcuts (wherever truly useful) can be implemented with further AuxTools™, which consume far less potential workarea than tabs.

These were steps in positive directions. But they were not a whole solution. We needed to provide consistent order. We needed minimal persistent consumption of potential interface area. We could substantially benefit from intuitive conventions such as color-matched page groups, subtitles, page numbering, and a row and column format. What if we could further reveal the whole structure of an application in an automated navigation system which also eliminated substantial overhead from our projects?

If we wanted these controls, we would have to build them; and many further observations deserved to influence design. From our earliest experiments with existing controls for instance, we often wanted integral regions which we could dedicate to further purposes such as hosting related controls, custom toolbars, or prebuilt tools for negotiating DBMS applications. We needed ways to readily extend the functionality of a module with built in, managed tool populations. We saw how we could benefit by building dialogs into integral regions so that they would never obscure our very work, nor need to be moved all about the screen. Because we often needed multiple toolbars and many such dialog regions, we saw that by leveraging existing paging functionality to these regions, we eliminated obstructions and multiplied functionality without raising footprints. Because we often needed such regions above or below a principal workspace, we deployed the leveraged resources in both places. No one would necessarily have to build a toolbar, write a wrapping algorithm, or work out a "dialog" repositioning method again.

These were our ideals, and the things we built into Ultimate Page Control Suite™ so that we could take the Paged, Multiple Workspace model the places it could go.

The remainder of this page provides a few examples of basic interfacing or navigation advantages of PMW. The related topic, How to Build Superior Paged, Multiple Workspace (PMW) Applications, provides guidelines and source for multiplying your processing core against unlimited workspaces, minimizing development overhead and resource footprints, and delivering maximal end user productivity and ROI with the best PMW implementations you can build.


A favorite text editor application globally processes the source of entire, extensive libraries.

An outstanding virtue of a favorite PMW application is that huge source libraries can be processed simultaneously. Global operations on hundreds of files are routinely performed in seconds.

This is a truly outstanding application. But as we can see, tabs are a substantial obstruction to working productively. Here we have less than 200 pages of a 400-page web site opened simultaneously, even as this editor readily performs global operations on the whole page population in one or two seconds. To operate on less than the whole page population at once necessitates re-opening sectors of the population and performing every global operation at least twice. Thus, to enjoy the greatest benefits of this editor, we need to open the entire site. But it should be obvious what will happen if we forget to reconfigure to single-row tab display before we do open our more than 400 source files at once. On the other hand, we can only very inefficiently navigate a single row of more than 400 tabs. Think about these design issues for just a moment, and imagine the consequences of negotiating this system.

How do we make this application better without writing a line of code?


How this application might appear in our TADVANCE_PM02_PagesToolsAndRelated UPC™ module.

Within our TADVANCE_PM02_PagesToolsAndRelated module, an even more functional toolbar is built simply by adding items to a managed collection. Comprehensive wrapping behavior is implemented without writing a line of code. Prebuilt navigation negotiates unlimited pages, preserving maximal workarea for primary functions.

Without writing a line of code, we have solved all of the aforesaid issues: Our navigation system persistently consumes minimal interface area; It provides a consistent order; Navigation is further expedited by page group subtitles, color matched captions, and even automated page numbering; and Our end users work more efficiently in the greater area we have preserved for the primary purposes of the application. Yet, without ever obscuring work, this interface deploys the equivalent of 3 independent bi-directional search and/or replace dialogs which process any one of 3 search strings, and which replace matches with any of 3 replacement strings — all by single clicks (versus selecting multiple options, then clicking a given tool). We have substantially extended the functionality of the original search/replace tools; and obviously, we could have replicated the original search/replace tool on a single row of our Paged Related Controls™ region. But the illustrated pattern shows how we can afford even more exotic tools; how to never hide work by paged dialogs; and how to retain maximal workarea for the primary purposes of the application simply by deploying a prebuilt UPC™ infrastructure.

We do all this from a smaller code base and more efficient footprint, and with substantially less development overhead. Even our paged dialogs are automatically accessible by prebuilt navigation, without having to write a line of code.

Here we host a network database implementation in our TADVANCE_PM04_DataMasterUPA UPC™ module, and make use of the bottom paged related controls region to serve the previous purposes. Because we may typically deploy upper regions of the main pages for data-aware controls, it may very well be more appropriate to deploy bottom regions for paged toolbars and related controls; and this is why top and bottom Paged Tools™ and Paged Related Controls™ regions are provided. UPC™ footprints are so light that we may simply hide unused regions or deploy paged regions statically (without navigation), with negligible effect on resources.


Typical MDI implementation.

Typical MDI implementation. The foreground window contains an image of an early nested PMW implementation.

In MDI, a primary system of selecting child windows often obstructs us even from knowing what workspace any child window may contain. How many destination captions can you read?

Selecting the back window, we immediately discover that primary access to workspaces is regularly hidden by the very process of MDI navigation itself. This fault alone would explain why supplemental navigation is a MDI standard. But alternate menu systems too are unsatisfactory for negotiating many workspaces, because menus were never designed to provide immediate access to hundreds of options.

Finally, alternative approaches deploying the system Task Bar can hardly provide sufficient space for but a handful of navigation destinations, and Task Bar buttons can hardly accommodate the captions we often require.

These things, plus the lack of a comprehensive prebuilt infrastructure, mean you must tread your whole way down a relatively tortuous and costly MDI development path, where truly satisfactory answers have never existed.


UPC™ NavigationWindow, providing access to more than 200 interfaces at once.

UPC™ NavigationWindow, providing access to more than 200 interfaces at once.

UPC™'s automated navigation system requires no coding, readily negotiates unlimited pages, provides secured navigation, and expedites negotiation by page group subtitles, individual glyphs (though uniform glyphs are shown in this image), color matched page group captions, and automated page numbering. Automated NavigationWindow behavior makes best use of available desktop workarea, and presents the most probable related content to your user base.


© Copyright 1995-2007, by ADVANCE Information Systems, Inc. ALL RIGHTS RESERVED.Copyright 1995-2007, by ADVANCE Information Systems, Inc. ALL RIGHTS RESERVED.

Firefox™.Best viewed in Mozilla Firefox™.