Virtual Thought

...of CSS: A 3-column layout entirely in CSS that puts the content first where every column’s size is independent and, by the way, the layout has footers and headers.

Yup, “Holy Grail” sounds way better.

Truly the best part of the List Apart article is the step-by-step deconstruction of the effects of each CSS tag. Sweetness.

I’ve been thinking a lot about how to [tag]unit test[/tag] [tag]UI[/tag]s in [tag]C#[/tag]. There’s this trope that I hear again and again from developers: “Unit testing a user interface is nigh impossible.” I think anyone who has worked with thick client UIs(user interfaces) should go and have a looksee at the programs available for testing the user interaction with those UIs. Most of them rely on pixel-interaction and, on Windows, sending fake Windows messages directly to the message pump of the application being tested. Both of these methods seem error prone and like deadweights around the neck of an [tag]agile[/tag] process. In a sense, these kinds of heavy user interface tests are a rigid kind of documentation of a UI and not a very expressive one at that.

One of the things I like best about NUnit is that the unit tests become declarative statements about the units being tested and, by extension, the program itself. The unit tests become a sort of negative space around the map of the correct functionality of the units and serve to document those units in a very expressive way. Each small test not only gives the assurance of correct functionality but serves to define what that functionality is and explain it to the reader. The tests play multiple roles: as guarantees and as documentation. That is fantastic.

I think a tool that could help test UIs would also serve multiple purposes. I think that it would not only help define proper interaction and proper states but also help keep UIs standard across far-flung organizations.

So why isn’t there a tool like that for testing UIs? I think, in part, because people become wrapped up in the presentation of a user interface and forget that there’s a logical structure underneath it all, waiting to be exposed. I’ve heard many times that, “If only the UI was built more as an MVC then we wouldn’t have this problem.” Wrong. An MVC exposes a model in a view whose interactions are externally controlled, sure… but I don’t think this particular design pattern is flexible enough to simultaneously maintain proper UI state, make a programmer’s job easier, and enforce UI standards across an organization. We need something that will address all those at once.

Maybe a correct approach is to think of most UIs as a kind of state machine (or maybe several interlocking ones if that is simpler). Each piece of the UI mosaic contains state (enabled/disabled, checked/unchecked, valid/not valid) that relates back to the whole and can be used to draw conclusions about that whole (user can enter text here but not here, user can click there but not there, etc.). I think this state machine is separate from the model and the view and shouldn’t be in the controller at all. It should express concepts about the UI, and contexts about the UI, without specifying “button this” or “menu that”.

To segue a bit… I’ve also been using Spring, a very cool IOC/DI(dependency injection) tool, which has taught me that a simple shift in paradigm can reap enormous benefits. Utilizing Spring has made my development life much more pleasant: my objects are more testable, my interfaces more meaningful… in general, the app is much more flexible. By using Spring and adapting the code just a little bit I feel like the codebase has greatly improved.

In that way it is similar to Rails. All that Rails asks is that you, the developer, shift your focus a bit and follow some conventions. The leverage that it provides as a framework creates enormous productivity gains while the models it provides engender a paradigm shift in what I think is the right direction: less grunt work, more concept work.

Which all brings me back to my pie-in-the-sky UI testing guy (Rhyming is Good): Who wants to hand check every UI that the team produces to make sure that it is pixel perfect in order to match UI standards for a company? Who wants to spend time adapting UI tests because usability tests indicated that the buttons should be a bit narrower and shifted down a few pixels thus throwing off the auto-clicker UI tester? Who wants to spend concept time doing the grunt work of tracking down why the damn “Save” menu item is enabled when the user hasn’t dirtied the editing window yet? Man, not me.

So here we are. I think good UI unit testing has to follow these rules:

• Be a framework. Ask the developers to give up some ground and the maximum flexibility provided by their programming languages so that the framework can transmute a little prior knowledge into a big win at UI time.
• Enforce a logical context separate from the view, model, and controller. Consider that most languages that define UIs in thick clients smash together the view and controller by default (Windows forms, anyone?) and you’ll see that if this isn’t made drop dead simple most developers will fight it. Enforce the idea that the user’s interface exists in a logical space that is separate from anything found in UI control libraries.
• Declare and document functionality. Any UI tests should not just exercise the user interface but should also define it. Don’t just verify what it does, state what it does in a compiler-enforceable language.
• Enforce arbitrary standards. I should be able to define any wacko standards that I wish easlily and declaratively. They should be in code just like the tests themselves.

Dive into Accesibility is one of the coolest web usability sites I’ve seen in a long time. It has great little gems like the Lynx viewer (what does your site look like using Lynx to give you an idea of what people with visual disabilities hear first?) and Vischeck, a neato interface for seeing what your site looks like for people with varying forms of colorblindedness.

Frickin’ sweet. So that’s what this guy did after writing “Dive into Python”. Heh.

Martin Fowler has some neat things to say about humane interfaces... the basic idea being that you want interfaces that work the way you do instead of being minimal and complete. Fowler talks a bit about duck typing in Ruby as a sort of continuation of the earlier article.

Interesting. This banged around in my head for a bit until it found the corollary thought: design UI interfaces to be workflow based instead of feature based. As developers I think we naturally componentize and abstract away our systems into sets of features: save, save all, save as, delete, editing options, undo/redo, etc. The user doesn’t break up his or her system that way at all; the user thinks “I need to get X done quickly.” That’s a very different way of thinking.

And to apply that to coding? So that I can say wonderful things like “list.last” instead of “if (list.length > 0) { list.get(list.length – 1) } else { null }”? That’s fantastic.

Not to say that it’s without problems: more methods = more testing, of course… but since you’re using TDD you wrote the tests before you created those seventy-some-odd methods, right? Right.

The Narrator has a great howto for installing Ruby, Rails, FastCGI, LightTPD and MySQL on Tiger mostly from source.

After munging up my system with lots of unstable fink installs (heh) this was exactly what I was looking for to get a good, stable Rails dev setup going again. Sweetness.

And, in other good news, I found my Pickaxe buried in a box in my computer room! I thought I’d lost it or lent it out or something and was despairing, figuring I’d have to buy a new one… fantastico.

Why not try this tutorial that manipulates a galaxy using SQL? It’s pretty frickin’ cool.

On a slightly unrelated note I’m thinking about starting an Austin chapter of the Ad Lib Game Development Society. Any takers?

I have an itch to program on my Mac at home. Something in a game kind of way.

ObjectiveC and XCode are right out the window. If I wanted to program with technology that felt 5 – 8 years old I would stick with C++ on Visual Studio 6 on Windows 98. Thanks, but no thanks… the Interface Builder rocks. Totally rocks. But XCode itself makes it pretty plain to me that Apple doesn’t love its developers—mayhap they even hate their developers. C’mon Apple: go find out how to make a real IDE and give us something useful! And, BTW, don’t make developers use a language that doesn’t have namespaces for God’s sake: don’t make me preface all of my type names with DRH and make me feel like I’m still using Emacs (Escape Meta Alt Control Shift) and gcc. Sheesh!

There’s always Ruby using TextMate. That’s a little painful though: I find myself posessing a rotted mind and missing my little auto-generated code and my Intellisense. I’m not proficient in Ruby enough to get the OpenGL bindings or, even, the FXRuby bindings to work. They don’t quite compile on the Mac… and many of the pages I find about RubySDL are in Japanese.

There’s also Python, of course… after all, Google uses Python... and I like the language. I even downloaded some Python game libraries that allow some pretty cool stuff with not much code. The pyGame library offers exactly what I’d want for a game programming library: reasonably fast, very productive, straightforward and well-documented with tons of examples. Fantastic! Definite possibilities here… except for my unfamiliarity with the language which would quickly be solved by starting a home project. Hrm.

But what about proce55ing, which Sean is totally obsessed with these days (his fertilization simulation efforts are coming along nicely)? I think I’ll have to put this one a distant third for now… something about the format doesn’t quite click with me… although the easy conversion of all your work to an applet is pretty frickin’ cool.

Of course, I could totally just put my old PC back together and make a managed DirectX game… what’s this I hear about DirectX 10 not being backward compatible? Whoa.

So how ‘bout Java with a little JOGL on the side? Then I get to use Eclipse which wouldn’t be so bad… but, I don’t know, Java?

Then there’s Mono alongside some incarnation of Tao to handle graphics… but what IDE to use? Ah, yes… what about fucking Monodevelop which has earned the dubious honor of being the hardest program I’ve ever tried to compile (including the Linux kernel!). Fink has been faithfully plugging away trying to update my GTK# libraries for the past three hour so I can even, maybe, possibly think about compiling Monodevelop myself. Blech.

But, all in all, it’s kind of fun.