Elegant Software

Sensible defaults

This evening I went onto HSBC Bermuda's internet banking website to pay my cable TV bill. After choosing the payee, entering the amount, and clicking "Pay" - leaving the date as its default value - I was presented with this:

 

Right now it's 9.45pm on Thursday 16 May. The date in the date field is 16 May. So the error message - "pay date 1 should not be earlier than today" - isn't even accurate.

But what's really frustrating about this error is: if 16 May isn't a valid payment date (presumably because I have now passed the cutoff time for the payment to be processed today), why didn't the date field default to 17 May instead?

(The other problem with this error message is where it is. Even though the message is in red, it always takes me a moment or two to notice it. It would be much better if it had been placed next to the date field that's the source of the problem.)

The purpose of defaults is to make life easier for your users, to help them complete their tasks more quickly. Wherever possible, you should set them, choosing values that are appropriate for the most common use case of your interface. However, never set a default value that could actually cause an error - better to not set a default at all.

 

Parsing structured text files in C#

If you need to parse a structured text file in C#, such as a CSV file, you have a couple of options. You might try to get away with a simple String.Split or a regular expression. You could use a third party library, like FileHelpers. Or you could just go over to the dark side and use Visual Basic, specifically Microsoft.VisualBasic.FileIO.TextFieldParser.

I have no idea why Microsoft put this class in the VisualBasic namespace. There's nothing VB-specific about it and you can happily use it in C# code by simply including a reference to Microsoft.VisualBasic in your project.

To parse a comma-separated file with quoted values, for example, you'd write something like this:

   string contentsOfCsvFile = ...;
   using (var reader = new StringReader(contentsOfCsvFile))
   {
      var parser = new TextFieldParser(reader);
      parser.TextFieldType = FieldType.Delimited;
      parser.SetDelimiters(",");
      parser.HasFieldsEnclosedInQuotes = true;
      while (!parser.EndOfData)
      {
         string[] fields = parser.ReadFields();
         // Add code to process field values here
      }
   }

Easy!

Downloading to a string

Today I had to write a piece of code to download a CSV file from the web. I needed to get the file as a string so I could parse it. Here's what I wrote first:

   var request = WebRequest.CreateHttp(_url);
   using (var response = request.GetResponse())
   {
      using (var stream = response.GetResponseStream())
      {
         using (var reader = new StreamReader(stream))
         {
            return reader.ReadToEnd();
         }
      }
   }

This worked fine, but I couldn't help feeling there should be an easier way. So I poked around a bit and sure enough, found that I could do this instead:

   return new System.Net.WebClient().DownloadString(_url);

Much more elegant!

Taming cats with extension methods

The following post is based on a true story. The names have been changed to protect my company's intellectual property.

Consider the classes below:

Yesterday I was writing some code to use them, like this:

   var phil = new Person("Phillip Wells");
   phil.Pets.Add(new Cat("Dark"));
   phil.Pets.Add(new Cat("Stormy"));
   ...

However, I have many cats¹ and having to instantiate a new class and add it to Pets every time quickly became tedious. What I wanted to do was write something like this:

   phil.AddCat("Dark");

Unfortunately, when I went to add an AddCat method to the Person class, I realised that I couldn't do it. Person is defined in the PhillipWells.Common package and Cat is defined in the PhillipWells.Common.Animals package. The latter has a reference to the former but I couldn't add a reference to the latter from the former without creating a circular dependency.

To work around this, I started by writing a PetHelper class:

   public static class PetHelper
   {
      public static void AddCat(Person p, string catName)
      {
         p.Pets.Add(new Cat(catName));
      }
   }

This let me write

   PetHelper.AddCat(phil, "Dark");

which was shorter, but not particularly elegant.

Then it occurred to me that extension methods might offer some help. To implement one, I created the following class in PhillipWells.Common.Animals

   public static class AnimalExtensions
   {
      public static void AddCat(this Person p, string catName)
      {
         p.Pets.Add(new Cat(catName));
      }
   }

allowing me to write the code I originally wanted:

   var phil = new Person("Phillip Wells");
   phil.AddCat("Dark");
   phil.AddCat("Stormy");
   ...

Extension methods are often considered a tool for adding methods to classes when you don't have access to the source code. As the example above demonstrates, however, they can be useful even when you do have access to the source code, but can't change it for some other reason. In this case, using an extension method allowed me to eliminate repeated code and write more readable code, while retaining the proper dependencies between the two packages containing my classes. Purrfect.

^{1. Specifically, four. Two of them really are called Dark and Stormy. They're named after Bermuda's national drink, the "Dark & Stormy", a mixture of black rum and ginger beer. The other two are called Black and Coke. Go figure.↩}

Your brain at work

Solving problems and making decisions are things we have to do every day, in both our work and personal lives. This fascinating talk by David Rock looks at what neuroscience can teach us about the things that help and hinder our ability to think.

 

 

It's an hour long, but well worth your time. The key points:

• Our belief in the superiority of rational thought is significantly overstated: our capacity for rational problem solving is actually extremely small.
• Perceived threats have a large, long-lasting, negative impact on our ability to solve problems and make decisions. The way we typically deal with negative emotions, by suppressing them, makes this worse.
• Social needs are primary, not secondary (Maslow was wrong). Social pain (for example, someone telling you your work is deficient) activates the same regions of the brain as physical pain. The brain craves status, certainty, autonomy, relatedness and fairness (SCARF). Threats to these hamper our ability to think.

The two papers mentioned in the talk - "Managing With The Brain In Mind" and "The Neuroscience of Mindfulness" are also worth reading, especially the first, which covers some of the same ground as the video. Rock also has a book that discusses the ideas in more depth.

Would an email do?

Instant messaging is great. When you urgently need to speak to me, it's perfect for seeing whether I'm at my desk and getting an answer to a quick question. You can carry on with your task with your flow uninterrupted.

Alas, I may not have been so fortunate. Your message may have caught me in the middle of thinking through a tough problem, forcing me to change gears to consider your question. Now I've lost my train of thought and have to backtrack before I can pick up where I left off. According to DeMarco and Lister's classic book "Peopleware", your 30 second message may have cost me 15 minutes in lost productivity.

A tempting way for me to deal with this is to permanently set my status to "Away". This can be effective, but then why am I running an IM client at all? So I can still IM you despite discouraging you from IMing me? Isn't that be a bit selfish? So I can still be contacted for truly urgent things? But who would deal with an urgent issue by messaging someone who appeared to be away? 

I could set my status to "Do Not Disturb" when I really don't want to be interrupted. But I have to remember to do this. And if I forget - bang! - there goes my flow again.

A colleague, whose status is always "available" when he's around, has set a permanent status message saying, "Do you really need instant access or would an email do?". When you send me an email, no window pops up to distract me from what I'm doing. It goes quietly into my Inbox, where I can read and respond to it at a time that's convenient for me.

So the next time you're about to send an IM, ask yourself whether your message is really urgent enough to justify interrupting the other person and potentially breaking their flow. If not, send an email instead.

On perfection

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

Antoine de Saint-Exupéry

Four design principles

I recently came across The Non-Designer's Design Book. In it, Robin Williams lays out four basic principles of good design:

• Contrast. Contrast is about making sure that items that are different look different. It's about providing focal points for the user that grab their attention and guide them through the interface. Ways to provide contrast include careful use of colour, images, or fonts. A good way to check whether your interface has sufficient contrast is to apply the squint test: can you easily distinguish the different parts of your interface even with your eyes partially closed?
• Repetition. Repetition is about repeating aspects of the design throughout the entire design. It's about creating a consistent look, making sure that items that are similar look similar, whether because they share the same colour, the same font, or some other aspect of the design. 
• Alignment. Alignment is about ensuring every element in the design has a visual connection with something else. Nothing should be placed arbitrarily. This ties in with the suggestion I made in my last post about ensuring UI elements are aligned to a simple, consistent grid.
• Proximity. Proximity is about ensuring related items are grouped together. Conversely, items that are not related should be separated. Make generous use of white space.

I was building a new interface this week, and found that consciously paying attention to these principles really helped me decide where to place each control and what fonts and colours to use. Fortunately, the principles are easy to remember thanks to their helpful acronym!

Steven Bradley and Andrew Houle have several good articles discussing these ideas in more depth, with lots of examples.

Minimising complexity

Complex interfaces make applications harder to learn and more difficult to use. Users can struggle to find the information and functionality they need, leaving them feeling frustrated and overwhelmed. Minimising complexity is essential to provide a good user experience.

The best way to minimise complexity is to only include features that users really need. Unnecessary features not only clutter the interface, they cost development and on-going maintenance time too.  Steve Jobs:

“I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.”

Ironic, given iTunes’ reputation for bloat, but perhaps it illustrates how difficult saying “no” can be.

If a feature has to be included, there are often multiple ways it could be exposed in the interface. Brandon Walkin has an excellent summary of some of the issues and solutions that I recommend you read in full. But to summarise:

• Use progressive disclosure. Give prominence to common features, and hide those that are used less frequently. It’s why it’s better to hide a function that the user doesn’t have permission to perform, instead of just disabling it.
• Be consistent. If the user can access a function in multiple places, ensure it’s accessed in the same way in each place. For example, don’t make the print function a toolbar button in one screen and a menu option in another.
• Don’t use context menus for primary actions. These menus are hard to discover as there are no visual cues to indicate they exist. Instead, consider placing important contextual controls near each object after the user signals an interest in it.
• Align UI elements to a simple, consistent grid. This helps reduce the perceived complexity of the application.
• Use lower contrast controls. This decreases visual noise and also helps reduce the perceived complexity of the application.
• Use icons carefully. Give meaning to icons without labels by carefully designing and grouping them and don’t use too many. Put infrequently-used icon-only buttons in drop down menus that include their labels too.
• Align the interface with the users’ mental model of the task. The interface will feel more complex if the language it uses and the functionality it provides don’t match the way the user thinks about the task.

By eliminating unnecessary features and designing interfaces that follow these guidelines, you can help users accomplish their tasks as quickly as possible and minimise the learning curve for new users.

Fewer error messages, more constraints

My last post made some suggestions for making error messages more user-friendly. But many users find any error message scary. I’ve encountered many people who, when they see an error, instinctively click whatever button will make it go away, often without making any attempt to read or understand it. They either try the action again, hoping that this time it will work, or they just call me to find out why my application is broken.

Because of this, if a user is not permitted to perform a particular action it’s better to prevent them from taking the action in the first place.

Consider the dialog below, which one of my (old) applications shows to a user who tries to create a new trade if he does not have permission to do so:

The only argument for showing a message like this is that it explains to the user why they can’t perform the action. But does the user really need to know why? Do they even need to know that the action exists at all? If not, it would be better to prevent the user from even clicking the control that results in this message, by hiding or disabling it.

Even if the user does need to know that an action exists that he cannot perform, is there another way the interface could communicate this more elegantly? For example, an interface that I built to allow business users to run reports displays the reports in a tree view. Reports that the user does not have permission to run are placed in a separate branch of the tree,  collapsed by default. Thus, the user can see the reports that are unavailable to him if he wants to, but most of the time they are hidden out of sight.

The dialog above is poor in several other ways too: referring to the user by name instead of simply as “you” is awkward; the action identifier “aNewTrade” is meaningless to the user so should be omitted; and there is no indication of what the user should do to obtain the missing permission.

Hiding vs. disabling

The dialog above was shown as the result of clicking a toolbar button that allows users to create new trades. So is it better to disable the button if the user doesn’t have permission to use it, or hide it?

The most commonly repeated guideline seems to be that if the user can do something to allow them to perform the action, the control should be disabled. For example, if one control in a form is only applicable if another control has a certain value, the first control should be disabled if the second does not have that value. In addition, the relationship between the controls should be made clear in the interface, perhaps by positioning the second control beneath the first or displaying a message that describes why the control is disabled. Seeing a disabled control and having no idea how to enable it can be frustrating for a user.

If the user cannot do anything to enable them to perform the action, the control should generally be hidden. In the example above, since permission to create a trade has to be granted to the user by an administrator, it’s probably best to hide the button.

In summary, every time you find yourself adding an error message to your application, ask yourself if you could use a constraint instead.