Dialog Boxes are Evil

In terms of the user experience, if dialog boxes are generally evil, Modal dialog boxes are the devil himself. Dialogs are UI concepts from what is slowly (and gladly) becoming a deprecated model. The 30 year old ‘GUI’ is being re-fashioned with a focus on touch-screens rather than mouse and pointer. Overlapping rectangular windows are being replaced with more web-style page navigation and interfaces (see Windows 8) yet we still see dialog boxes on Web pages today.

Jakob Nielsen states as an advantage of modal dialogs that it improves user awareness: "When something does need fixing, it’s better to make sure that the user knows about it". For this goal, the light-box design provides strong visual contrast of the dialog over the rest of the visuals. The light-box technique is now a common tool in website design [Wikipedia]. I don’t disagree with that, but it seems we are presented with modal dialog boxes far more frequently, more commonly than just when the user really needs to be involved, even on the web. A classic example that we can find in almost every application on the desktop or the web is this one (taken from Windows 7 in this case);

clip_image001

Curiously, this file is actually headed for the recycle bin, so it’s a reversible option, so we don’t really need to be asked. Recycle bins are good because they let the user make reversible mistakes, but in this case we also have an unnecessary intervention. At least Windows is mature enough to support keyboard shortcuts, [Return] and [Esc] for cancel. This is something a lot of Web page GUI clones would do well to emulate.

Presented with enough of these interventions, the user soon becomes de-sensitised to the warning. Windows 7 is riddled with, “are you sure?” queries like this. For instance, UAC transfers the responsibility of system protection to the user, which in many cases the least qualified party to decide if opening a file is safe. In essence, one could argue that the computer is saying, “I don’t want the responsibility of the thing that I’m about to do…so, if it goes wrong, it’ll be your fault”.

clip_image003

To most users, this intervention just gets in the way. Pressing ‘No’ means the application won’t run, pressing ‘Yes’ means it will. Sure, it’s adding a guard layer to ensure the user is aware that this program is about to make system changes and providers an opportunity to back out. I’m not against that, if you’re going to run with Administrative permissions on the desktop, it’s merely a design compromise based on the least path of resistance.

I don’t want to get distracted by whether it’s a good idea to show the user this dialog in the first place, but having done so, note that it’s a “modal” dialog. Meaning, that I can’t do anything other than either press ‘yes’ or ‘no’. There’s no third option.

Nielson is correct here. This operation should be modal, but does it really need to be a dialog? If all I can do is choose one of those two options, and I have a 15 inch screen with a pixel range of 1280×1024, why do I have to target one of two bulls-eyes only a little taller than my mouse pointer?

In fact Microsoft has until recently had a 30 year love-affair with the MessageBox. You only have to use Kinect to see evidence of this unhealthy obsession. Even a full-body motion controller interface has its share of dialogs with yes/no options and it’s far worse here because you need to somehow find that tiny button whilst floating your hand around in 3D space.

If there are only two options, and (computer) you need my attention that badly, why not just give me something genuinely full-screen like this;

clip_image004

OK, it’s Ugly with capital ‘U’, but I’m just making a point. First of all, in the western world we read left to right, so progressing forward is the right-hand option. The left hand half of the screen is to go back or cancel the operation I’m about to do. For Kinect this would map perfectly to left-arm/right-arm. I no longer need to locate a tiny target. I can use a whole body gesture; left arm or right arm. Since there’s nothing else I can do, so why not use the whole screen, or the whole body if I have a full-body controller.

Now I’m not for a second suggesting that we turn all dialog boxes into full screen option buttons, dialogs are still evil after all however they’re styled, but let’s take a look at a very common example in Google docs. We see the “Are you sure?” warning on delete operations all the time, but Google even have this on document creation in Docs;

clip_image005

Nowhere near as mature as Windows, this GUI does NOT support keyboard shortcuts at all, so I’m forced to pick up the mouse and locate that [x] in the top right. Try accurately hitting that on a touch-screen. But a more important question to ask yourself is whether you really need a dialog at all. One could argue that in this case, since this operation is ‘permission’ related that we really need that user confirmation before we proceed, but with a re-think it might be possible to design this dialog out altogether.

Going back to common delete operations, this is where Google get it right. If you delete a file in Google docs it doesn’t ask if you are sure, it just does it, but gives you a reverse operation (undo).

clip_image006

This is known as “User Forgiveness” and it’s exactly the same thing that Windows does with the Recycle Bin. Announced just yesterday, SkyDrive now has this. Additionally, the Web already has a “go back” concept with the browser navigation buttons which can be used in a lot of places where dialogs are often chosen instead.

At Nupe, we favour user forgiveness over blame transference every time and we’re working very hard to design-out both the, “are you sure?” model and other legacy GUI concepts that aren’t touch-friendly in general like dialogs along with horizontal scrollbars, cascading menus. You’ll see the benefit of this effort over the coming months.

One Line System.Web Caching Template for .Net

Whenever I have something that rarely changes, but takes a little while to calculate I like to cache it, typically, in ASP.Net’s Web Cache. One example might be a bit of JavaScript I want to return minimised and I can’t use System.Web.Optimization for some reason. So, I was finding myself repeating the same algorithm over and over;

1) Is the item cached already? If yes, return it immediately.

2) Build the item.

3) Cache for next time

4) return the item

It’s not many lines of code, but it’s nevertheless prone to cut and paste error and requires a new unit test each time, and then I came up with this neat little shortcut;

    public class Caching
    {
        static Cache _cache = HttpRuntime.Cache;

        public static T CacheThis<T>(string key, Func<T> resolverFunc)
        {
            // Use our own cache if ASP.Net cache is not available
            Cache cache = _cache;
            if (HttpContext.Current != null)
                cache = HttpContext.Current.Cache;

            // Look for a cached version of key
            var output = (T)cache.Get(key);
            if (output != null)
                // Smashing, we can return this from the cache
                return output;
            else
            {
                // Resolve, cache, return
                output = resolverFunc();
                cache.Insert(key, output, null, Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration);
                return output;
            }
        }
    }

So basically I templatised the algorithm. Now whenever I want to cache anything I can wrap my code in this neat little one-liner;

            var scriptName = "minifiedMainScript.js";
            return Caching.CacheThis(scriptName, () =>
            {
                // get resource without a cache in the normal way
                var Text = MyLoaderClass.Load(scriptName);
                return Text;
            });

Or literally, this could be written on a single line, but you can put as much logic in that code block as you want. It won’t run unless it needs to. Easy huh?