Writing user interfaces

Some of you may know that I don’t do a lot of user interface work. Well, in the last couple of weeks I’ve been doing little but user interface work. I thought it might be time to share a few reflections.


The designer in VS 2005 is actually very good – for a designer. It still has its “thou shalt not touch this bit of code” which of course you then have to touch in order to include some controls which aren’t in the toolbox, but overall it’s pretty reasonable. I particularly like the “GenerateMember” property it uses to decide whether or not to create a member variable for controls. No more silly label variables for no reason!

One day I’ll be able to use WPF/XAML, which is of course another step up again, but until then this isn’t too bad.


Hooray, a half-decent layout in WinForms. Whatever people may say, just using Dock and Anchor doesn’t give enough control over layout in my view. Lining things up with absolute positioning should have been a thing of the past years ago.

TableLayoutPanel appears to have some significant shortcomings, however. In particular, I was in a situation where it would have been really nice if TLP allocated all the “Absolute” sizes, then gave as much as possible to the AutoSize rows, then gave any spare to the percentage rows. However, it goes top to bottom, left to right. Basically I wanted a couple of buttons below a multi-line label, and for the label to become a scrolling area if there wasn’t enough room for it, with the buttons always present just below the label. Maybe there’s a way to lay this out the way I want, but having sworn over it for most of an afternoon, I’ve given up.

Scrolling is also a pain – it tooks me a long time to get any scrollbars to appear when I wanted, and I still don’t know exactly what triggered it suddenly working. Even now they aren’t quite right, as the appearance of a vertical scrollbar forces a horizontal scrollbar to let you get at the bit of the panel which is now taken up by the vertical scrollbar – even if there’s nothing there! All very frustrating.

Overall architecture

I really suck at this. I’m trying to separate everything out appropriately, but I don’t know enough about it to cope when things get tricky. All the samples of MVC, MVP, Humble Dialog etc are fine when they’re doing relatively simple stuff, but it feels like UI is particularly prone to “I know I shouldn’t have this logic here really, but it’s much easier than doing it properly…” Hmm.


I have really mixed feelings about the satisfaction derived from UI. A lot of the time it seems like very slow work – implementing a small UI feature seems to take a lot longer than implementing a small server-side feature – but when it’s working, it’s very visible. You can show people the results. Just demonstrating hundreds of working unit tests and a few database tables filled with data doesn’t have nearly as much of a pull. I think a prototype UI (not prototyping the real UI, just enough to demonstrate backend features) is possibly the way forward here.

Basically, I suspect I’ll never be a GUI person at my core. I can grow to be passably good at it, but I suspect that you have to keep working at it for a high proportion of your time to know all the gotchas and tricks involved and keep a clean design.


In other news – the book is still coming along. Sorry to have kept so quiet about it, but I’m hoping I’ll be able to announce something properly (and tangibly) fairly soon.

5 thoughts on “Writing user interfaces”

  1. Funny enough, I’ve recently had the same experience. I’m no UI genius, but I’ve had to try to architect a “best-practices” approach on a rather large project I’m leading, because no one else came in with any ASP.Net experience.

    I have pretty much given up on doing MVP using vanilla ASP.Net. We implemented it according to some articles we found online (after a lot of research) but after doing it for a while it just felt more and more like indirection with no real benefit (which I have zero tolerance for), and we ended up ripping it all out. I’ve heard good things about Monorail and Spring.Web, but we didn’t have enough time to take a long look at them before we had to start producing some functional screens.

    One small framework I like is PageMethods. It’s not perfect, but it tends to lead to code-behind code IMHO. Check it out–it only takes about ten minutes to learn.

  2. Uh, that should read: “It’s not perfect, but it tends to lead to CLEANER code-behind code IMHO.”

  3. I don’t think MVP is recommended for ASP.NET. On the Web MVC rules the roost.

    There are also varying differences in the different kinds of MVP you can implement, see MartinFowler.com for Passive View and Supervising Controller. Both of these can also be implemented in various ways.

    I however prefer a kind of mix between MVP commonly and MVC when using databinding (as MVP + databinding isn’t really MVP).

    As ever it’s a bad idea to be too much of a zealot about what the pattern says, as you are making software rather than just making patterns.

Comments are closed.