Cascading Dialog Boxes Anti Pattern

Here's an example of the ShowTheUserOurPrivateObjectModelAndNothingElseAntiPattern. Suppose our private object model looks like this:

    [Root Object] 1---->0,1 [Tier Object] 1--->* [Leaf Objects]

The right way might be to present that in a UI is to show the Root, fields representing the Tier, and a list box with the Leafs. The last two segments are ghosted if the Tier does not exist.

The [presumptively] wrong way to manipulate this UI is to force the users to add bogus details to the Tier before they add a Leaf. The ultimately wrong way is to ghost the Add button on the list box, and give the users no clue they need to put something in the fields that we know represent the Tier first before the Leaf system becomes available.

The Right Way depends entirely on what UseCase or UserStory you need to render. If the story says they must add a Tier before adding a Leaf, so be it. But, following the rule that "The Actors in a Story are _Not_ the Objects in a Program", then the Right Way must be considered in isolation from the object model on the inside. This is exactly where user-involvement in GUI building is so totally important.

We usually get the CDB when we take an entry-level programmer (maybe one who got the job by demonstrating the ability to run a GUI forms editor), and tell them to write a UI for this Object Model that someone else created. Then we tell them they are too junior and unimportant to be allowed to disturb the August User with their distastefully neophytic presence.

Junior now goes and, after a few days struggling with SDK example code that raises a blank frame window with a menu, makes a menu item raise a dialog that represents the Root. (Keep in mind that the blank white client area in the middle of this frame window will probably remain blank forever.)

Then they put a button on this dialog that says Tier, and this raises a dialog showing the Tier object.

Then (can you guess?) they put a button on that dialog that says Leaves, and this raises a dialog showing the list of Leaf objects!

Then, in an ultimate fit of championship hacking, Junior puts a button on THAT dialog that raises a dialog showing a LEAF!!!

(Obviously, along the way, these dialogs interact with global data structures that non-robustly parallel what's displayed, because in Junior's GUI classes in college they never told anyone that each dialog can remember its own private data chunk to support these kinds of problems. But they did teach global variables.)

Of course you can get the CDBAP in many other ways, but you can always bet on the combination of no UI design, a junior GUI programmer at the helm, and no OnsiteCustomer involvement.

--PhlIp

Not entirely an AntiPattern if the cardinality on the first relationship is not 1->0/1 but 1->*, as there are few ways to achieve all of this in one screen which are both usable and not unnecessarily complicated. You also end up violating OnceAndOnlyOnce and the LawOfDemeter if you try and map two one-to-many relationships with lots of associated data onto one screen. Not to mention confusing the user when you suddenly take everything away from them for seemingly no apparent reason.