If a bull charges at them, they will run

It’s a natural reaction. When people see an angry animal charging towards them, they run. Very fast.

Charging elephant
[image by RollingEarth]

So why do programmers think setting user interface controls that are enabled to display as disabled, is acceptable?

When users see a greyed out text box, what do they think? It’s disabled. There’s an application I’m maintaining where the text boxes are all greyed out, the same colour as the background (it’s a Windows program).

“Oh I can’t enter anything,” complains the user.
“Really? Have you tried typing something in the text box?” I ask.
“I can’t type anything, I tell you!”
“Ok, let me check…”

*some time later after checking*

“Hi, I’ve checked. You can still type stuff into the text box. It’s just greyed out. And you can save the information too. I’ve also modified the program to make it easier to see.”

Yes, users are so convinced of the obvious that they don’t even bother to check if the text boxes are actually disabled. Is it the fault of users? Is it the fault of the programmer? I feel both are at fault, but the programmer more so. Wrong display of enabled and disabled controls is too simple an error to make.

The scene described above actually happened during my work. It’s not about educating the users that they can actually type in the text box, because it’s a design flaw. It’s the fact that they didn’t even bother to try that I’m concerned with. It makes debugging user queries very challenging…

Sometimes, the obvious blinds us, to the point where we react to something that seems obvious to us, but is not the actual thing. There are now things and events we can have time to think through before reacting. I believe we have evolved more than our hunter/gatherer roots.

Of course, if there’s a raging bull charging at you, don’t stop to ask questions. Just run.

Null is foreign concept to users

Is it hard to imagine … nothing? Apparently, it is for some people.

There was this report that my users view/print. For one of the items, there wasn’t any database records for it. Correspondingly, there wasn’t anything printed for that item.

One person asked, “There’s an error. Why isn’t item X shown?” Even though the report printed out records for items Y and Z, that person didn’t figure out that there wasn’t anything to print for item X, hence blank for item X.

So the takeaway lesson? Show something, even if there’s nothing to show. For example, displaying “There are no records retrieved.” is better than a blank page. Your user might still ask stupid questions, but at least you know your application is working correctly. Sort of.

Then comes the question you should ask yourself, “Why isn’t there any records to show?”

Are you making this restaurant service mistake when you code?

I visited two restaurants recently, and realised both made a common mistake. It made me feel frustrated, and generally unhappy about the experience. So what did they do?

They made it unpleasant for the customer (me) to buy and eat their food on their premises.

Case study 1: The Coffee Bean and Tea Leaf

Every weekday, I’ll go to the nearby Coffee Bean restaurant to take my breakfast before going to work. (The reasons why I do this is too numerous to explain. Perhaps in another post…) Recently, I started hearing some grumblings from the staff about students. It’s near exam time, and the students come to the restaurant, order a drink, down it to about halfway, and then sit in the restaurant for hours on end, supposedly studying.

The infuriating thing is, the students will come plop their stuff onto the tables and seats. Each student will effectively take up a four-seater-two-table place. If they’re happy, they might even share their table with another friend.

Now during peak hours, this is unacceptable to the restaurant. It is potentially losing four paying customers for one lousy-cheap-drink student. More importantly, I can’t have my chocolate brownie and Earl Grey tea on my off day weekends because of those students (there I’ve said it).

So the restaurant staff came up with a plan. One day, when I arrived at the restaurant for my breakfast, I felt a bit funny walking towards the ordering counter. Then I realised it. They’ve rearranged the tables and chairs.

All the tables were separated into single islands of one table with two chairs. They told me it was because of the students. It was a bit cramped actually, because the restaurant floor space was now reduced. I had to maneuver carefully to avoid spilling my tea.

I asked what if the students pushed the tables together. They said they’d tell the students they’re not allowed to join tables. After a few days, I asked them the results of their tactic. It seemed to have worked.

Now for the problem. Though aggravating, the students still represent a small percentage of customers. Why are they making all customers to have an unpleasant experience? From the front of the restaurant, the view looks kind of daunting, militant, uninviting even.

As immediate (and satisfying) as the table separation solution was, the long term solution should come from a management perspective, a design perspective.

Case study 2: McDonald’s

My nearby McDonald’s just underwent a renovation. Now it looks brighter, more woodsy-brown, different from it’s previous Hong Kong movie stars and music scene theme. The restaurant management also restricted the cashier line to just one, when they have three perfectly working cashier machines.

I’m guessing they’re trying to improve efficiency, since the staff at the sole cash register is working like crazy to get all the customers’ orders in. A receipt is all that represents the customer, which is pushed to one side while other staff scramble to fulfil the order.

This is like a multi threading problem, where before there’s three cashiers taking and fulfilling orders, and now there’s just one cashier taking orders with multiple staff fulfilling orders. In both cases, an attempt is made to move through the order taking and fulfilling process as fast as possible, in as parallel and concurrent a method as possible.

In theory, that should work. In practice, the user experience suffered. I would much rather that the one staff taking my order goes through all the way with fulfilling my order as well. Sure other staff can help out, but I want the same person serving me.

In the new method, my order was taken, and then I’m shunted off to the side, like some tool whose usefulness was spent. I don’t know who’s getting my drink. I don’t know who’s getting my burger. I don’t even know if anyone was doing anything for me. It sucks.

The coming together

When you go through your project requirements document (you do have one right?), do you simply want to get a certain function done, without giving any thought to how a user would experience it? Sure all the buttons are there, and all the display controls are there. But is it intuitive and easy to use?

I recently had this user explain to me how a screen from a legacy program worked. The sequence where she clicked buttons and checked output made no sense to me. She clicked a button on the bottom left first, then checked some data display, clicked another button on the top right, checked some more display, and clicked a button that was above the first button.

There was absolutely no logical flow to perform the task. Yet my user followed this pattern and was astounded that I had no idea how and why it worked. The user had conditioned herself into a negative usability pattern because there was no other way. I went back to my office, silently swearing at the programmer who originally coded the program. I swore even more after I saw the code…

Why was the user being subjected to this kind of service? As programmers, our users are like our customers. We should be treating them well, even if they aren’t paying us.

Are you making it hard for your users to use your application?

Programmer’s dilemma – Making tough choices

I’m lucky to be given relatively free reign in my design and coding decisions. Unfortunately, that often means I have to choose between what is right, and what is easy. Here’s a few of them:

Usability – If it’s optional, then don’t make it mandatory
When given the choice of optional fields, a user can and will take the path of least resistance, which is to leave all optional fields as is. I recently developed a web page that retrieves records from a database. All fields are optional. Consequently, everything from the database is retrieved. Which crashed my web server.

Since I was giving a presentation to a customer when this happened, I was just a tad embarrassed. After the presentation, I went back, made a few fields mandatory, with corresponding error messages to avoid Raymond’s feedback form experience. Sometimes, I have to be a user too.

Result oriented – Programmers Don’t Like to Code
I used to tell people I love programming. I’m not so sure now. Then I realised what I really love is solving problems, and that I can express my solution in a program. Even though solving that CSS display bug or optimising that loop gives me joy, it means little to the result-oriented user. So I have to choose practicality sometimes.

CSS Design – Suckerfish Dropdowns
There is this web application I’m maintaining that displays a menu for navigation. The code is unwieldy and makes use of some Javascript copied and pasted without much thought. Hideous to look at and horrendously tedious if I have add a new page. Luckily I found a more elegant dropdown menu solution. It means I have to redesign the navigation element, but it’s worth the effort.

The one you never want to meet – The Brillant [sic] Paula Bean
I have seen my fair share of obnoxious idiots of programmers, and chose patience and understanding instead of exclaiming their ineptitude. But Paula, the experienced Java programmer, raises stupidity to an art. Brillant!

Socialise or be ostracised – In Programming, One Is The Loneliest Number
Not only is programming by yourself lonely, but it’s dangerous to your code, health and social life. It was tough when I first started interacting with people I don’t know but were on my office floor. Don’t have any programmer colleagues? Get help by persuading your manager to hire another competent programmer.