Ramblings From The Social

On Delight

Wonderful consumer applications often will present the user features that create delight. Delight is one of the most important concepts to understand, and one of the least understood by engineers, especially in the software profession. Software engineers bathe themselves in objectivity, practicality and scientific analysis. If it isn't measurable it simply isn't important. Taken to an extreme, we get to the world of Linux, where the ideal text editors have cryptic memorized commands to simply navigate your document. Pressing 'j' and 'k' move your cursor up and down, and 'h' and 'l' move your cursor left and right. The reasoning for this? When you type, your hands are supposed to stay on the home keys. Since moving the cursor is something a user will do often, they map keys on the home row to movement so that the user does not have to move her hand away from the home row. Once a user becomes an expert at all of the cryptic commands, they become far more efficient at text editing than on any other editor.

The critics of Cover Flow in iTunes complain that it is superfluous, unnecessary, and an inefficient way of navigating through your library of music. Perhaps all of these things are true. But they are missing the point. Cover Flow creates smiles. There are little features that create delight for a user. In one of the first few posts on my personal blog, I described my experience unboxing my first iPod:

Well, finally it is in my hands, and I have to say that this is one of the coolest toys I have ever played with. If first impressions are everything this has won me over already. It is housed in the best packaging on any product ever that I've ever opened. It may sound silly, but opening the iPod box is really an experience. Everything slides open, folds open, fits perfectly, and is overall very slick. You can tell the packaging was really well thought out.

And there it is. If the experience of opening the box of a product gets someone giddy, something powerful is happening there. Human beings are emotional creatures, and emotions can override objectivity and practicality on a daily basis for everyone–except engineers. Engineers, scientists and generally those in technical professions are trained out of style over substance, and instead are laser focused on metrics and objectivity. There is important for a few reasons, least of which is that you certainly hope that bridge builders care more about stability than aesthetics! As long as product designers are not killing their users, they should focus on the emotional effect of the product itself. If users are delighted enough, they will actually overlook flaws in your product. I remember I debate I was having with coworkers over the iPod spin wheel thingy. They argued that it was impractical and impossible to hit exactly what you want in the UI. I argued vehemently, stating that it was possible with the right amount of practice. I exclaimed that I had been using iPods for years and could hit exactly what I wanted every time! So of course, I was challenged to prove myself. So I whipped out my iPod and did a demonstration. And as I bounced up and down trying to hit the menu item I was looking for, quickly my smug look faded away as one appeared on my colleague's face.

This is not an isolated incident. When enough delight is built into a customer's experience, they will march with you until the end of time. Delight creates emotional experiences. And once emotion is evoked between a user and a product, only then can a user fall in love.

Wow. Petzold really doesn't get it.

I have a tremendous amount of respect for Charles Petzold.  When I originally was utterly confused with how to make the leap from DOS-based C programming to the world of __stdcall, lpszElement and HRESULT, Petzold came to the rescue and stuck to the core of the WIN32 API, building from the ground up and making me feel like I could actually build a Windows application.

Many years later and recently immersed in the world of .NET and CLR, I hit that natural point of wanting to understand the latest and greatest in presentation framework technology.  Naturally, I picked up a copy of Programming Microsoft Windows Forms and Applications = Code + Markup, by the renowned Charles Petzold.

Imagine my disappointment when I realized that Applications = Code + Markup was not simply a terrible book, but extremely damaging to programmers attempting to understand how to use this new technology.

The book is a very detailed description of Windows Presentation Foundation (WPF), which presents a tremendous advance in presentation technology.  At its essence, WPF was designed to innately decouple the user interface from the code behind it.  I'm familiar of at least once instance of dramatic coupling between UI and logic.  In one infamous example, a crash report demonstrated that after a click to expand a tree view control, a WM_PAINT event was sent, and the code didn't have the data to display and needed to access the network to get it.  There was no internet connection available, so the handler made the obvious choice: dial the modem. No wonder the user closed the application impatiently.

User interfaces change.  People run usability testing or add new features and this should be able to be rapidly changed without having to dramatically rewrite the data layer.  Decoupling UI from logic is simply good design and is more of a mindset rather than any additional development cost to incur.  In fact, this idea has been around for a long time, since when the model-view-controller was first touted at Xerox PARC in 1979.

In another example, I was involved with writing the server code for a major feature in a previous product, and we were completely on schedule to ship.  But the PC client's UI layer was so tightly coupled with the application logic, that they said they needed an extra 3-4 months to code up the feature.  We had to cut the feature.  And it amazes me to this day that it was not the service, with all of its requirements of scalability, reliability, security and performance constraints over hundreds of thousand concurrent users, that caused the feature to be cut.  It was simply bad coupling between UI and logic.

WPF looks to solve this by letting presentation be described by a declarative XML language called XAML (pronounced zammel) which elegantly hooks into the .NET code behind it.  And lets developers stop shooting themselves in the foot accidentally with bad design.  When writing applications in this mindset, you cannot help but decouple the view from the controller.  Applications = Code + Markup.

If only Petzold believed his own book title.

When reading his book, I was confused by why Petzold completely ignored XAML until page 457.  He chose to present how to code entire WPF applications without XAML, and then presents it nearly as an afterthought in the rest of the book.  I came across this blog post by Petzold that made me even more confused:

About two years ago, I went to Redmond to attend a three-day WPF System Design Review. (At the time it was called the Avalon System Design Review.) Three days of WPF, and it was nearly all XAML. It was all very interesting, to be sure, but there was virtually nothing covered about event handling, for example. As we all know, when you're writing an actual application, almost everything is event handling. In the vast scheme of things, XAML does very little except replace a constructor of a Window class (and possibly replace a few special kinds of event handlers if you're using data binding or animation).

My realization was finally catalyzed in a large part by this post by Don Box, in which he says this about Petzold's approach:

The notion that looking at WPF through the lens of C# rather than XAML is somehow more “foundational” or “deep” is missing the point.

Going back to Petzold's post, we find:

As anyone knows who has followed my blog entries over the past year or so, my love for XAML is second to no one's. XAML is lots of fun, and it's great doing little demo programs entirely in XAML. But XAML is like crack. Once you get into a XAML-only mindset, your entire world gets smaller and smaller. You're doing cute demos, but you're not doing real-life WPF programming. Real-life programming is code. We use code because it's flexible and can do pretty much anything we want. XAML doesn't have for loops or if statements, and only if you use techniques that I pioneered in blog entries here and here, can you do any arithmetic in XAML. XAML is great for what XAML is great for, but that's about it.

And suddenly it all makes sense.  Petzold really missed the entire point of WPF.  He sees XAML as syntactic sugar over the framework and nothing more.    

His book is a dangerous one to keep on the shelves, because I worry that enthusiastic, young programmers will pick up this book and somehow think that presentation written in code is real-life programming.  That XAML is for those VB programmers but the hardcore ignore it.

I sincerely hope that this fine technology isn't singlehandedly ruined by this book alone.