For every action, you need a reaction

I came across yet another example of bad interface design this morning.

After I logged into my computer, a pop-up window appeared. It was my Docker application, telling me that an update was available and ready to install. Okay, I said to myself, and clicked the button to proceed.

Except… nothing happened.

I clicked it again. And again. And again. I mashed the mouse button. Nothing. I decided there was a problem with the interface, went on with my work, and forgot all about it. At one point, I saw a Docker window appear, saying updates were being applied. Okay. Again, I went back to what I was doing.

I didn’t think anything of it — until I looked at my taskbar several minutes later. All along the taskbar were several new — and identical — icons that I hadn’t seen before, roughly one for each time that I had hit the mouse button. When I clicked each icon, I was greeted with a window that said “installation failed.” Well, almost all. The second-to-last one I clicked said, “installation succeeded.”

Yet another example of horrible design rears its ugly head.

As an application end user, if I click something where it says “click here,” I expect — and demand — that it does something. It doesn’t matter what it is. Granted, I would prefer that it performs the action that I expect when I click it, but even if all it does is change the mouse pointer, display an “in progress” icon, or display an error message, I expect some kind of response that indicates that my action did something.

An action that results in nothing is a huge pet peeve of mine, and, in my opinion, is extremely horrible design. A click that does nothing tells me that the application is doing exactly that: nothing. Having an action with no response is not only annoying, it can be potentially dangerous. What if — hypothetically — clicking a button resulted in lost data, but there was no indication as such?

A reaction is a form of feedback. If I click a button, a reaction — even if all it is is an in-progress icon — tells me that the application is doing something. If I click a button, and it does nothing, then I expect the application is doing nothing. An action without any reaction results in frustration on the part of the end user, and potentially dangerous side effects if the application performs an action that the user doesn’t expect.

If this is how you design your UX, then you need to rethink your design. When it comes to interfaces, every action must have a reaction.

Advertisement

My introduction to Docker

With my (still-relatively) new job comes an introduction to new (to me) technology. In this case, the technology in question is Docker.

For those of you unfamiliar with Docker (like me), it is, in a nutshell, a tool for deploying and running an application within a container. It is an improvement over VM (virtual machine) in that it runs at the operating system, rather than the hardware, level, resulting in less overhead and a more efficient environment.

As part of my indoctrination into Docker, I looked up some resources to help me get started.  I found this entry that seems to be very helpful.  I’m sure I’ll find some others as well.  I’ll post them as I go along.  I also installed Docker on my work laptop and have been playing with it.  At the moment, I am far from an expert on Docker (in fact, I’m not even close), but I feel like I’m starting to get the hang of how it works.  Hopefully, I’ll be productive with it before long.

I also noticed that, in the schedule for our upcoming SQL Saturday, one of the sessions focuses on Docker.  I intend to attend that session.  At this point, any resource that helps me to learn this technology is definitely of interest.

Does anyone else have any suggested resources for helping me (and others) learn Docker?  Feel free to comment below!