UI Programming (Usually) Sucks Feb 14th 2017

I'm a UI programmer who hates programming UIs. The ironic part is that I happen to be very good at it. I do however thoroughly enjoy something that comes with UI programming: having the biggest possible impact on the user experience and, crucially, the first impression. Leave it to irony to bring me that joy through the most tedious, dull, and soul-sucking part of coding.

Let me set the tone: I find great joy in some UI programming. Particularly when I get to design something new: an awesome system, a new way of doing things, or -- if you know me this won't come as a surprise -- a new power tool. The problem is that most of the things you do in UI programming is something that's been done before, and, even worse, something you've done before. A thousand times. Hook up that button. Add that menu item. Put a tooltip on that checkbox. You're not making anything new and cool, and it's boring.

However, with every one of these tiny dull changes you're improving the user experience. You put a tooltip on that checkbox because a group of users didn't understand what it did. And I can get lost in those little changes. The work to result ratio is unmatched. I put an interface in front of me and I stare at it. What do I want from this interface? Does something annoy me? Does it do everything it should? Does it do too much? This is one part of UI programming that's good - the part where you're not actually programming. After isolating the changes you want to make, it's time to implement them. And that sucks. Big time.

You usually have a nifty visual editor to lay out your design. The visual editor always sucks. It's nothing to do with the design of it or the way it's done. It just sucks. It's an unwritten rule. Microsoft has a tendency to make theirs suck just a little bit more. What else would I be referring to but the hideous monster they call WPF, where unless you're completely and utterly out of your mind you'll be writing your layouts in XAML. Manually. Here's an example of a very simple WPF layout, from my open-source IRC client:

<UserControl x:Class="CodeCafeIRC.ui.ChatBox"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             mc:Ignorable="d" 
             d:DesignHeight="250" d:DesignWidth="350">
    <RichTextBox BorderThickness="0"
                VerticalScrollBarVisibility="Auto"
                HorizontalScrollBarVisibility="Auto"
                x:Name="TextBox"
                Background="Transparent"
                IsReadOnly="True"
                IsReadOnlyCaretVisible="False">
        <FlowDocument x:Name="Document" 
                    FlowDirection="LeftToRight"
                    IsHyphenationEnabled="True"/>
    </RichTextBox>
</UserControl>

If that's not enough to turn your stomach, try this. Then do that thirty times over.

Microsoft of course provides a visual editor to help you with your layout, but it's about as useful as a heater in the desert given the vast number of strange features you'll be using to fully utilize the oh-so-time-consuming MVVM pattern (and how often I've had to restart Visual Studio because the XAML Designer was so adamant it had found an error that didn't exist, or just flat out crashed the process). In fact, it's so time-consuming that I am fairly convinced Microsoft doesn't plan in terms of manhours anymore but rather in terms of headcount. "The pattern is not very productive to work with? Assign more employees to work with it." WPF and MVVM are as inseparable as siamese twins, and I used this on/off for nearly two years for Parakeet 2. It's terrible. So, so terrible.

Okay, so when you have a draft of the interface, you have to hook it up. Here's a quick 2-step guide on how to hook up any user interface: Ctrl + C, Ctrl + V. You can only write button callbacks so many times before you start paying more attention to the lyrics of the song you're listening to than the work you're doing.

Now you have to wait for the program to recompile (another stellar moment to pay attention to lyrics), and I have to be careful not to start ranting about compilation speed here because that is a whole topic in itself that I will surely cover eventually.

Rinse and repeat until you're done. That's the recipe for every standard interface you see in every program, but let's leave that gloomy alley of depression and talk about when UI programming doesn't suck: when creating a completely new system. Unlike most UI programming, creating new systems to solve a problem is incredibly difficult and it's likely you're gonna get it wrong the first few times - expect it, and accept it. You don't want to be the person who designed Clippy. For me, it's the challenge that makes it interesting - and it's amplified by all the times I've been frustrated with a program's design or workflow. I'm a workflow addict and a power user. I know what I want and I'll spend hours on end to get it. I put the user experience above everything, and I will do my damnedest to make sure no users of my designs -- or any designs I have any influence over -- ever get frustrated. (That being said, the customer is not always right.)

When users praise your work, that's the best part of UI programming. It's validation that the decisions you made on their behalf were spot on, and that using the program is a better experience because of it. Users don't care about the internal refactoring or optimization work, no matter how avidly you try to convince them about the benefits. They care about what they can see, hear and interact with. Unfortunately all this awesomeness goes hand in hand with the monkey work. It's no surprise that I avoid UI-heavy projects like the plague in my own time, where I don't have eight hours to spend each day.