The rhythm of software
I live in Adams Morgan, a multi-ethnic part of Washington, D.C. not far from the famed Dupont Circle and on the same street as the White House. Nearby is Meridian Park, a semi-green oasis in the middle of the city. At one end is an imposing statue of Joan d’Arc gifted to “the Women of America by the Women of France.” On summer weekends, Joan is witness to a most amazing spectacle.
Many people, most male, and mostly from Jamaica, West Africa and Spain, congregate here with all manner of percussion instruments. The gathering is not formally organized and everyone is welcome. Each person just joins in with his/her instrument and makes some amazing music. It is quite a spectacle to see 20-30 people playing all manner of drums and the crowd enjoying/dancing to the most infectious beats.
As I sat and listened to the beats today, I found myself thinking about software. Weird, yes, but that is my passion and I inevitably draw parallels. In the drummer group, there is no leader and people join and drop out at random. As new people join, there is a clear dissonance, but gradually, they sync up, beat for beat until it is so perfect that you cannot help but look for the conductor.
I think about the similarities this has with designing a user interface. I am not very good at software engineering, but I do put quite a bit of effort into the user interface of my software. Creating the U.I. almost always starts off with dissonance. Even with planning and preparation, the initial result is seldom pleasing. It takes several iterations and many days, sometimes weeks, before everything starts feeling harmonious. It’s like the drummers…you can’t instantly sync up…it takes time.
Although I have no scientific data to back this up, I think that successful software has an underlying rhythm. Elements work together in harmony so they become invisible and actions have a natural flow. This is the signature of intuitive software.
When Microsoft unleashed ASP.Net on the world, it helped us take a giant step forward, but in the U.I. area, I think it was two steps back. ASP.Net has single-handedly resulted in the propagation of some of the most dissonant and horrible web user interfaces the web had witnessed. And this is not the first time Microsoft has done it. When Microsoft gave us VB, the same thing happened. By making it easy to create a U.I. by dragging controls around on a page, Microsoft unfortunately created the U.I. equivalent of a cancer. I cringe every time I see controls grouped willy nilly and adorned with superfluous fonts, lines, colors, bevels…you name it. This stuff eats away at app usabililty.
With ASP.Net, my pet peeve is the “auto-postback.” Whoever put that into ASP.Net should be drawn and quartered. And developers who use it deserve the same. For instance, few things are more horrible in a U.I. than to have a page postback when the user makes a selection of a dropdown item to populate or reveal additional form items. Extreme dissonance! This should be done client-side, and not server-side. If there is a lot of data, use XMLHttp. There is no excuse for postbacks that occur without a user click action on an actionable user interface element (i.e. button, icon, hyperlink etc.).
When I evaluate web software, I look at the usability first and the capability second. My rationale is that if it is not usable, who cares what it can do. If I see that the app is an ASP.Net app, I have a litmus test. If I go make a dropdown, radio button or check-box selection and the page posts back, I am done evaluating. As far as I am concerned, the app is unusable. That said, my favorite portal DotNetNuke abounds with instances of this. So although by my definition it is unusable, I continue to use it for two reasons: (1) it has a lot of other positives, and more importantly (2) being on the core team, I am empowered to change this, but haven’t, so I consider this my own fault.
Anyway, I work around it by never using any of the built-in DNN modules other than the registration (which I hope to change some day, because the postbacks on it drive me nuts). With version 3.x, my worst fears were realized. Now, DNN settings pages sport collapsible sections that — you got it — post back, to expose more fields. Arrrrgggghhhhhhh!!!!! I would like to fix it but my biggest fear about fixing some very obvious problems with the DNN U.I. is that I am afraid to break some functionality in the process. DNN has so many moving, interdependent parts that this is actually quite easy to do. I know I should get over this unjustified fear and fix things. Someday soon I will work up the courage to do it, until then I will present mini-fixes through my blog as I have been doing and live with the dissonance.
