Tag Archives: UI

Emoji in console output

Posted on by
Reply

Recently, my friend was talking about some output he got from running the minikub program. Each line included a leading emoji character. He was not thrilled, and I don’t think they did it well. But when used appropriately, emoji can add valuable context to the output.

root@test# minikube start
? minikube v1.0.0 on linux (amd64)
? Downloading Kubernetes v1.14.0 images in the background ...
? Tip: Use 'minikube start -p <name>' to create a new cluster, or 'minikube delete' to delete this one.

? Unable to start VM: Error getting state for host: getting connection: looking up domain: virError(Code=42, Domain=10, Message='Domain not found: no domain with matching name 'minikube'')

? Sorry that minikube crashed. If this was unexpected, we would love to hear from you:
? https://github.com/kubernetes/minikube/issues/new
root@test# minikube delete
? Deleting "minikube" from kvm2 ...
? The "minikube" cluster has been deleted

I should say, in the interests of full disclosure, that I have written tools that include unhelpful emoji in the output. Some of the emoji are not helpful. The crying cat because it crashed? Doesn’t add anything. The broken heart when the cluster is deleted? I don’t have time for your guilt trips. But the light bulb for a tip and the bomb for a Big Bad Error help draw attention to what could be a wall of text.

Here’s what I see as some guiding ideas for using emoji in output:

  • Have a fallback, but not a stupid one. For the code above, there’s a fallback to ASCII. If you thought the emoji added no value, check out how un-valuable the fallback is. The fallback should probably be “print nothing and go straight to the text output”.
  • Don’t print emoji to logs. The console should be human-readable (and a well-placed emoji can help with drawing attention to the right places), but logs should be machine-readable (well, grep-readable). Log messages should be more structured anyway, so maybe it doesn’t really matter, but don’t rely on your user having an emoji keyboard available when they need to grep the logs.
  • Try to use unambiguous emoji. Pictograms are language-independent, which is nice, but if you’ve ever tried to communicate with A Youth via emoji, you know there’s a lot of room for nuance. Stick to well-understood characters and document them somewhere.
  • Use emoji to enhance context, not to replace text. Log parsing and screen readers are two reasons that you don’t want to get rid of text in favor of emoji. Use the emoji to draw attention to important messages and provide hints as to why they’re important, but make sure the messages still stand on their own.

Your crappy UI could be lethal

Posted on by
1

The tech industry embraces (some might say “fetishizes”) the philosophy of “move fast and break things”. Mistakes are common and celebrated, and we don’t always consider the effects they have. Autonomous cars may help bring that to the forefront, but many dangerous effects already exist. This is a story of how a UI decision can lead to dangerous consequences.

A friend of mine has a daughter (we’ll call her “Edith”) who has diabetes. Like many people with the disease, she checks her blood sugar and takes an appropriate dose of insulin to regulate it. One night a few months ago, Edith checked her blood sugar before dinner. The meter read “HI” (over 600 mg/dL), so even though she felt fine, Edith gave herself 15 units of insulin.

As she ate, Edith began feeling shaky. She re-checked her sugar: 85 mg/dL. It was then that my friend realized “HI” was actually “81” and had Edith disconnect her insulin pump. Severe hypoglycemia can lead to a coma or worse. Had Edith been alone, misreading the meter could have resulted in getting the full dose of insulin from the pump, which could have caused a dangerously low blood sugar level.

How could this have been prevented? Using the word “high” instead of “hi” perhaps. Or any other unambiguous message. If it’s the “digital clock” style screen, have the elements race around the edges. Or put a plus sign and have it read “600+” with the plus sign blinking in a demonic color. Whatever. So long as it’s not easy to misread (especially if the user wears glasses but does not have them on, as an example).

Unambiguous UIs are always good. When it comes to medical devices, unambiguous UIs are critical. If misunderstood, the consequences can be lethal.

P.S. Happy birthday, “Edith”!

The UX of a microwave

Posted on by
2

I’m not a UX expert except in the sense that I have experience using things. Still, I spend a lot of time at work serving as a proxy for users in design discussions. It’s hard to get UX right, even on relatively simple experiences like a microwave oven.

Years ago, my systems analysis professor got on a tangent about user interactions. He pointed out that it can be faster to enter a minute on a microwave as 60 seconds instead of one minute, that 111 seconds is faster to enter than 110. Design choices (including the design of instructions and documentation) that seem obviously correct are sometimes incorrect for non-obvious reasons.

It took a little while, but I eventually discovered that the “Quick Set” menu doesn’t have pre-programmed settings, it just adds a zero to whatever code is entered. So the quick set to cook two slices of bacon (20) simply sets the time to 2:00. In that sense, it functions less as a shortcut and more as a list of cook times.

On a whim today, I tried to warm a cup of coffee by using a quick set code of 6 instead of 10. It didn’t work. Apparently the microwave requires quick set codes to be exactly two digits. For a one-minute cook time, the quick set is hardly any quicker than a manual entry.
My microwave came with the house, so while I don’t know exactly how old it is, I know it’s at least seven years old. Maybe recent microwaves have a more sensible UI. Or maybe it’s a problem that will never quite be solved.