Snatching Complexity from the Jaws of Simplicity

    Photo by gurdonark

This post is both a rant and a warning. Simplicity is a noble goal, but far too often adding simplicity actually creates more complexity (usually in unintended places.) As I talked about in my post on security tradeoffs, no analysis of a security improvement is complete without first identifying where it weakens security. The same is true with anything that simplifies a process: Somewhere down the line something is being made more complex.

What I’m talking about specifically is a part of Windows Presentation Founation which is the new framework for writing GUI software in Windows. (My apologies to those that aren’t developers, or don’t want to be, but I will try to word this for computer nerds of all stripes.) WPF is a really amazing piece of engineering, but not without some compromises. The thing that’s really been bugging me lately is the Visibility property used on UI elements.

Prior to WPF elements had a property called Visible that was a Boolean type (boolean types are either true or false.) So that, for example, if you wanted a button to show or hide based on some value within a program it was pretty clear how to do it:

SomeButton.Visible = User.IsAdministrator;
SomeButton.Visible = Customer.OrderCount > 100;

WPF has a different concept of visibility which is due to the way that elements are designed to flow around each other. When a UI element is hidden it is either just invisible and still takes up space or it is completely gone so that other elements may take its space. The WPF designers decided to turn the 2 value Visible property into a 3 value property called Visibility. Visibility can be set to Visible, Hidden, or Collapsed. 

Now, this decision seems to have been made for the sake of simplicity. The other option would have been to create a second Boolean property such as IsCollapsedWhenHidden. Taking two properties and making them a single property is a good idea, right? Well, it may have simplified the writing of the framework, but it made things more complex for us developers. Coding the same things as above now looks more like this:

SomeButton.Visibility = User.IsAdministrator ? Visibility.Visible : Visibility.Hidden;
SomeButton.Visibility = Customer.OrderCount > 100 ? Visibility.Visible : Visibility.Collapsed;


When a developer is showing or hiding components they need to spend extra energy thinking about whether the component is to be hidden or collapsed, something that rarely every changes during the run of a program and is a decision that should have been made earlier in the process. This seems like it’s not such a big deal, but it’s just a small piece of the pie. WPF has a concept called binding where properties of elements are tied to properties of objects so that a change to the object is reflected in the interface automatically. Here’s the code if Visibility was a Boolean type:

[Button Visibility=”{Binding Path=IsAdmin}”/] 

Pretty simple. Here’s the code with the current type of Visibility:

[BooleanToVisibilityConverter x:key=”boolToVisibilityConverter”]
[Button Visibility=”{Binding path=IsAdm[in Converter={StaticResource boolToVisibilityConverter}}”/]

The BooleanToVisibilityConverter, as its name implies, turns True into Visible and False into Collapsed. But what if you want False to be Hidden?  There are a couple of ways to do it, here’s one:

  [Button.Binding Path=”IsAdmin”]
        [con:Mapping From=”True” To=”{x:Static Visibility.Visible}”]
        [con:Mapping From=”False” To=”{x:Static Visibility.Hidden}”]

There are other ways to get there, but they’re all about as complex. All of this could have been avoided if early in the piece someone stopped to think what the consequence would be of the new Visibility property.

Any time you think of an improvement that will simplify something, take a moment to ask what all of the effects are. Making something simpler almost always makes something else more complex. Be especially wary of things that make life simpler for you but more complex for your users.