Business Tech: UX/UI Part I

My green screen does what I like, and I like what it does. I've used that line in presentations. Not because I feel that way, but because I understand that feeling. There is something comforting about living in a 24x80 world. You can't be expected to do much that's new or different in how the software looks on the screen. You get to concentrate on the engine work, the power of the application. GUI, HTML, smart phones, etc., these push the needle more toward form and less toward function. What's an engineer to do when we also have an obligation to be artists?

Non-artists tend to think of art as a world without rules. Oddly enough, it is quite the opposite. Art is endlessly subdivided into genres, styles, movements. Those names build a constraint around each type of art. While novels in Science Fiction and Romance are both collections of words, the reason we call them by different names is because the rules for each are different. Art is about playing within the rules in addition to playing against the rules. In that way, it is very much like programming.

IOU UI

UI (User Interface) is the aspect to the program that connects the person to the process. It can be a green screen, a voice (think Google's Assistant, Siri, Alexa, or any other auditory interface), a watch, a webpage, or any number of other things. If you want to see how esoteric interfaces can get, look up an electronic musical instrument called a Theremin.

On the other hand, UI can be very physical. The modern car has a surprising amount of tech inside it. The steering wheel, the gas, and the brake are UI elements. When we design a user interface, we have to understand more than just the engine it connects to, we have to understand how people will want to use it.

And we have an obligation to do that. Just because the green screen didn't give us a lot of options, didn't mean that we weren't responsible for doing it back then, either. Let's talk green for a moment.

\ E Q X /

Imagine if you went to work in the early eighties and every screen you used had a different way to exit. One program requires a "Q" for quit. This one wants you to "slash out" with a back-slash, while another wants you to "slash out" with the forward-slash. I've seen systems of that era that wanted you to "TOP" out in some places and "X" for others.

You might guess that I'm making a case for consistency, but I'm not. Let's examine one of the most successful modern interface elements to see how far off that assumption really is. Consider the humble HTML link. What happens when you click on it?

• It takes you to another page.
• It takes you to a completely different site.
• It rebuilds the current page with and additional criteria.
• It opens a hidden area on the current page.
• It changes information on the current page.
• It brings up a pop-up box.
• It presents additional menu options.
• And so on.

Links do not have a single, assured behavior. No one cries foul and demands we fix this terrible problem. People are okay with this far-from-singular approach. I mentioned cars before, let's get back to that for a second. Assuming your car still uses an ignition key — some don't — what do we all know about what happens when we turn the key and remove it? It shuts the power, right?

Wrong.

If I turn my key and take it out but I don't open the door, I have an, ahem, window of opportunity to roll up my windows, because removing the key doesn't turn off all of the power. Oh, and the headlights still work. Of course, the blinkers still do, otherwise you couldn't use your four-way flashers with the keys out. And no one is demanding that this be more consistent.

What our web link and our car key have in common is that every way in which they break the rules makes sense to us. I'm fine with "E" to end here and "Q" to quit there if I perceive a difference between the two types of exits. Differences that make sense are distinctions. Differences without sense are sloppy.

No Exit

UI isn't just about exits. We need to navigate from field to field. We need to have a way to correct errors. A way to ask for help. The list goes on. Just like we need a rule that tells us to put last name in attribute one of a particular table, we need rules for how we design the controls in our software. And we need to understand the bias in our rules.

I've played games where your character is told direction by using the keys W-A-S-D because they are grouped together on a QWERTY keyboard. That's not a good interface for a voice module. Can you imagine guiding a robot through a maze by shouting A-W-W-W-D-S-W-W-W? For voice, using words — left, right, forward, back — makes more sense. And on my iPhone, the keyboard is unlikely to be visible during my game. That's screen real estate I can't give up.

Using the back-slash to go back in a green screen might make sense, but the availability of the mouse makes the whole idea of field-back obsolete. Touch screens require us to re-evaluate the use of indirect methods like the mouse. So, we need a guide that works for each medium.

Ultimately, UI is about creating the shortest ramp from new to experienced. The more the controls make sense, the less time the user has to spend learning how to make your amazing tech do what it was designed to do. We have the power, and the obligation, to make things easier.

UX Again and I'll Still Say No

UX (User Experience) is the sum of the UI plus other design elements. We'll talk about UX in the next installment.

Featured:

May/Jun 2017