The decline of the user interface

When we first got the personal computer, we didn’t worry much about how things worked. We were, frankly, stunned that we even had such a thing. You had to learn some arcane lingo to type into a DOS prompt. That the computer might be difficult or awkward to use didn’t occur to us. But things gradually got more sophisticated, and when the original Macintosh came out with its powerful graphical user interface, we started realizing that the process of interacting with a computer could matter to us.

Software developers started having to think not only about how the program was going to get the job done, but also about how the user was going to interact with the program to get the job done. It became clear that a good user interface was something that would sell more software. If it were easy and intuitive to interact with an application, then users could get more done and would love the application.

Standardization was the first step. One of the things that the Macintosh, and later Windows, did was to make a lot of the computer interactions we take for granted today “normal.” The File menu, with options like New, Open, Save, and Exit, became commonplace. Dialog boxes had Ok and Cancel buttons, and all of these things did what they were expected to do.

This idea culminated in a seminal book by Alan Cooper, et. al., called About Face: The Essentials of Interaction Design, which codified and explained many of the design patterns that computer users have come to expect, as well as blazing a trail for new ideas that made human interaction with computers work better.

Sadly, everywhere you go on the web these days you can see that these very useful, helpful notions are being lost.

The demise of the Ok button

One bedrock principle widely adopted in GUI apps was to make very clear what action would be taken when the user pressed the mouse. If, for instance, a user brought up a dialog window that had a number of options for them to set, then there should always be an Ok button that would accept the changes and a Cancel button that would reject them.

The Ok and Cancel buttons played important roles. A user might go to a Settings dialog, change a bunch of settings, and then click Ok, knowing that their changes would be applied. But often, they would make some changes and then think “You know, nope, I just want things back like they were.” They’d hit the Cancel button, and everything would reset to where they started. Disaster averted.

Sadly, this very clear and easy way of doing things somehow got lost in the transition to the web.

On the web, you will often see Settings pages without Ok and Cancel buttons. Instead, you’re expected to click an X in the upper right to make the dialog close, accepting any changes that you’ve made.

But what if you make changes and then decide you don’t like what you’ve done? How are you supposed to reset and ignore what you’ve changed? You can’t. The burden is then on you, the poor user, to remember what you changed and set things back to where they were yourself. And sometimes remembering is hard.

And heaven forbid that closing the popup dialog requires you to actually click outside the dialog box, leaving you wondering, “Did my changes take effect or not?”

We need to bring back the Ok and Cancel buttons.

Fine mouse motor skills required

Another annoying change is the surgical precision now required from mouse users (and worse, touchpad users). Somewhere along the line, we started needing incredibly fine motor skills to make things happen.

One of the great features of GUIs is the ability to size windows and move them around the screen. With the advent of very large monitors, this has become particularly useful. But operating system vendors (I’m side-eyeing you, Windows) have made sizing and moving windows challenging. 

In the newer versions of Windows, I spend a dismayingly large amount of time trying to get the mouse to the right spot in the corner or edge of an application so that I can size it. If I want to move a window, it is all too frequently difficult to find a location at the top of the application to click on that will result in the window being relocated.  Applications used to have a very clear title bar that was easy to see and click on.

Take a look at your browser tab set right now. If you, like most of us, have a ton of tabs open, where exactly would you put the mouse to move the window to a better location?

It used to be that these “affordances” (a word coined by Don Norman, the author of the wonderful book The Design of Everyday Things) were plain to see and straightforward to use. The borders of windows were thicker and easier to “grab,” as was a window’s title bar. But in the name of aesthetics, I suppose, these borders have become razor thin and hard to grab. 

What application is this, anyway?

Next up, there are times when I’m not at all sure what application I am looking at. An application used to declare itself very clearly by name in the title bar, but now? Nope.

For instance, what application is this?

IDG

You can tell that it’s a browser, sure. But is it Google Chrome? Firefox? Who knows?

It’s actually Microsoft Edge. How would I know this by looking at the application? There isn’t any way to do it, as far as I can tell. You have to go somewhere else to know what app you are looking at. Grrr.

My rant about the persistent and utterly irremovable irritant that is Microsoft Edge will have to wait for another day.

Everything is gray now

Color is a powerful indicator. We all know that when something is red, we need to be wary, and when something is green, we can feel safe and happy. Color in user interfaces is useful as well. In the golden age of GUIs, it was common to color a button to indicate that it was active and clickable, and to gray the button when it was inactive. Similarly, tab colors used to be clear and bright to indicate active, and dim and gray when inactive. 

For instance, which tab is active?

IDG

Somewhere along the way, it seems designers decided that grays and blacks were the “clean and cool” colors, and stopped using clear and distinguishable colors to mark boundaries or signal status. I’ve even seen interfaces where dark gray indicated “selected” and light gray indicated “unselected.” Look, gray is not ever “selected” or “active.” Blue is selected or active. Or green. Gray is unselected.

I think what happened was that designers rightly figured out that gray is indeed preferable to black and then went overboard with that, thinking “gray everywhere for the win!” But gray is just not preferable to, you know, other colors. 

Looking cool is winning

It saddens me that “looking cool” seems to have become preferable to “useful and usable” in the minds of application and operating system developers. Software applications should be easy to use. I should be able to do the things that I want to do without having to struggle or wonder, “What just happened?” A great application just works and doesn’t require me to think or read a manual to make things happen. Form is important, but sacrificing functionality at the altar of form and design is a big failure.

Okay, I agree, first world problems. But I find this epidemic of poor usability to be very irritating, and very dissapointing. We used to do better.