September 9th, 2005

  • evan

dynamic ui

Another surprise from my brief foray into Windows was that every window looked different: not only the positions of the buttons, but also the relative spacing between the controls and even the fonts. And not just because the programs were made my third-rate vendors, but even the Windows update popups.

After a night's sleep, I think I have a reason.* I thought back to my Windows development days and remembered building UIs. If you want to make a static layout of controls, like a preferences dialog, they've got a great UI builder that even measures distances proportionally to the current font. But it's much harder to make UIs that behave dynamically.

For example, if you want to have a window that contains a control that resizes with the size of the window -- in particular, a text box -- the right way to do it is to handle the resize message on the window and manually measure out the new size the control ought to be. This gets rather complicated when multiple controls are involved. And worse, you're similarly out of luck if you want to add or remove widgets to a window that's already visible.

(Right here it's probably worth stopping to note that it's considered bad UI do those sorts of things. But when you think of popular, well-designed apps these days, like iTunes, they do it all the time to great effect. It may be just that our models for software changed. Back in the MFC days all the app construction was centered around toolbars and one big box for drawing whatever it was you wanted to do.)

(And here's another example of a resizable window, from a Windows LiveJournal client I was working on back in 2001: screenshot1, screenshot2.)

So what appears to have become popular in Windowsland is to use a declarative language that handles layout for you; unfortunately, that language is HTML. Their (definitely powerful) integration of Internet Explorer into everything means that it's often simpler to just push some HTML at an IE widget than it is to position the controls together the right way.

HTML UIs on the web have somehow managed to make users comfortable with the fact that every site they use has an entirely different UI; somehow, concepts like "click on the blue stuff" and "the back button" are sufficient to not get people totally confused. This freedom makes people lazy and there are plenty of unnavigable websites to show for it. So similarly in Windows, at least two of these weird-looking dialogs that popped up looked suspiciously HTMLish, either with blue links to activate further options or with wacky fonts (probably the result of an <h2>).

In the GTK world, I think they happened upon a better way of doing it: the composition of every app is done with code, with Java-style layout managers. So you get resizing for free because you're required to do it from the start, and dynamicism for free because you're creating the initial layout with code anyway. And then you can build a nice dialog layout system** on top of that.

* Well, one reason secondary to my post is because they switched from MS Sans to Tahoma in Win2k but your app only gets Tahoma if you know which resources to twiddle. The Quicktime installer didn't.
** I love the irony that the layout of Glade itself is totally hideous -- look at the spacing of the rightmost window!
*** If you're actually reading these footnotes you get a bonus pic that I found while digging up those other two, of a teenaged and more gothy me.