Mark Gilbert's Blog

Science and technology, served light and fluffy.

"Agile Software Development and UI Design: a Match made in Heaven?"

This past week the XP West Michigan users group held their monthly meeting, and brought in Professor Robert Biddle of Carleton University in Ottawa, Canada.  Professor Biddle spoke about the research that his group has been doing on agile teams around the world.  The talk was fascinating on many levels, and Professor Biddle made a number of very interesting points.  Here is a smattering (paraphrased):

A tremendous amount of energy has been poured into developing agile teams, and describing how to be a better or “more agile” team.  However, what can be said about how to be a good customer interfacing with an agile team?

Professor Biddle made the observation that agile teams frequently find themselves hating the process after about three months.  Why?  The customer nods and goes along with the development team for that amount of time, making light comments about the direction of the project and hoping that they eventually get on the right course.  The three-month mark typically is the breaking (snapping?) point for the customer, and they finally let their frustrations out.  To avoid this, a good customer needs to have the courage to say things like “no, this isn’t what we need” or “no, we’re not there quite yet – here’s where we’re still falling short of our goals”, and they need to say these things as soon as the customer realizes them – not three months later.  For most human beings, this is a very hard thing to do.

Tell your stories.  Let everyone know where you’re coming from.

“User stories” aren’t supposed to simply be a list of requirements for the new system.  They are meant to be stories – tales that involve real people facing real problems in the real world.  One of my favorite books is “The Soul of a New Machine” by Tracy Kidder in which he tells the story of a company (Data General) working to bring a new computer to market.  The story he tells is riveting because Kidder gets you involved in the people.  He explores their past, their motivations, the circumstances that brought them together as a team, and their challenges to get a completely new machine out the door at a breakneck pace.

Granted, we aren’t all Pulitzer prize-winning authors, but the stories that we collect for a new piece of software have to be more than simply “screen 42 will collect the order shipping information”.  They need to involve the people that will be using it, their motivations, their goals, etc.  Otherwise, we’ll miss valuable information about who the system is being built for, and the other team members won’t understand where we’re coming from.

Prototype the system using paper instead of digital tools.

Professor Biddle described teams that would mock up screens using sticky notes and pens, and ask people to “interact” with the system.  The system is low-tech, inexpensive, very easy to change, and only requires a few seconds for the users to suspend their disbelief.  What’s more – and this was a point that struck many in the room, including myself, as profound – no one will mistake sticky notes for a nearly finished system.  The same can’t be said for a prototype built with a RAD suite.

Computer Science (CS) students rarely learn UI design.  Human-computer interaction (HCI) students rarely learn how to program.  This is bad.

Professor Biddle mentioned that at Carleton University the HCI curriculum was part of the Psychology Department – not the Computer Science department.  His position at the University happens to be co-listed between the two departments so he is able to pull in researchers from both.  He makes the point that not everyone needs to be experts in both disciplines, but everyone does have to be aware of what is going on around them.

The User is not always king.

I think this was my favorite example of the evening.  He alludes to the attitude on several agile teams that the user is the ultimate driving force for the direction of the development efforts, and their word is final.  After all, the software is being built for them, right?  The user is necessary and critical, but not sufficient for a good piece of software, he illustrated it with the example of an ATM being designed purely by a user:

  1. The user walks up to the machine.
  2. The machine dispenses money.
  3. Preferably not the user’s money.

Perhaps we should consider other points of view?

All in all it was a terrific presentation.

March 29, 2008 Posted by | Agile | Comments Off on "Agile Software Development and UI Design: a Match made in Heaven?"

Dude, where’s my .CancelButton?

One of the minor road bumps I encountered was trying to build the WPF Media Player, and especially the Songs popup list, was how to denote the Close button’s Click event handler to fire when the user hit the Escape key.


In Winforms, the CancelButton property of the form did this trick nicely.  There was also an AcceptButton property that determined which button would be “clicked” when the user hit the Enter key.  These two properties were invaluable when creating Winforms utilities.  When you’re opening and closing the applications over and over (you know, like when you’re debugging the utility initially), being able to slap the Esc or Enter buttons to test something saves a lot of time.

In WPF, however, things have changed.

These two properties have moved from the form to the buttons themselves.  There are now button properties for IsCancel and IsAccept.  As the names suggest, these take Boolean values and define which button will be “clicked” when the user hits Esc or Enter, respectively.

I can’t say that I’m entirely pleased with this move.  With a Winforms form, you could only have at most one button defined as the Cancel button, and at most one as the Accept button (these two could theoretically map to the same button, but doing that would confuse the user, to whom “Enter” means “come on, do something, I don’t have all day!” and “Esc” means “no, wait, stop, I didn’t want that!”).

But with the WPF forms, and the IsCancel property (for example) attached to the buttons, what would happen if I had more than one button defined with “IsCancel=True”?

Would they both fire when the user hit “Esc”?  That could get a little messy, not to mention confusing for the user.

Would the first button in the tab order fire, and the others be ignored?  That could be confusing for the maintenance programmer.

As it turns out, having multiple buttons defined with “IsCancel=True” does neither of these things.  In fact, hitting Esc repeatedly simply tabs between the two (or more) buttons defined in this way.  The Click events never fire; the focus merely jumps around the screen.

The lesson here is that WPF makes it easier to shoot (or is that click?) yourself in the foot.  Take care that when you define a Cancel or Accept button for your form you only define at most one of each.

Ultimately I decided not to use the IsCancel property in the 0.1 release to implement the Esc-key functionality.  However, I’m glad I know where it’s moved to, even if it is a little more quirky than before.

March 29, 2008 Posted by | WPF/Silverlight | Comments Off on Dude, where’s my .CancelButton?