Author Archives: loufranco

It’s Bad, Now What?

Creators of visualizations can learn a lot from sonifications, especially the focus on action. When your alarm goes off, you know to get up (or at least snooze). When I look at a lot of application dashboards, I often don’t know what to do. It looks bad, so now what?

One way we solved it at my old job was to pre-define levels on visualizations meant to show system health. We started with numbered levels, but then for simplicity we settled on green, yellow, and red. When you are driving, you know exactly what to do when the light is green or red. Even yellow only has a few options.

To help us think about these levels more, we labeled them Excellent, Acceptable, and Unacceptable.

Like red and green traffic lights, it’s clear what to do when your levels are Excellent or Unacceptable. Yellow/Acceptable levels are harder, but since our company mantra was “Don’t do Nothing” (in the face of a problem) and our goal was Excellence, we had to do something.

For us this meant (something like):

  • Yellow: Investigate and put a ticket on the backlog with enough priority to get addressed soon. It will be released as appropriate (no rush).
  • Red: Make a ticket and assign it now. It might be released immediately.

In practice, other things mattered.

  • How red or how yellow?
  • Is this a blip or sustained issue?
  • Is this caused by us or related to the environment (e.g. is US-East down?)
  • Will it go away on its own?

But even under these ambiguities, the first few steps were pretty clear, and the options for what to do next were small. And since the status got posted to our slack every morning (and reported to grand-bosses every month), we were very unlikely to let it drop.

How A Car Honk is Like a Green Light

A couple of days ago I wrote about sonifications, the sound equivalent to visualizations. Even though they haven’t permeated business culture in the same way visualizations have, they are around us used in a folk way—meaning, designers use sound in their interfaces, but it isn’t systematic or directly supported in tools.

Even without that discipline, sonifications generally do a much better job of making themselves actionable. This is because that’s the main reason you use sound. You need to interrupt the user and get them to do something now. In my last essay on this topic, I gave a list of examples you encounter while driving: car honks, sirens, lane-drift warnings, etc—they all need immediate attention.

If we look at visualizations we encounter while driving, actionability is a core-driver. The gas light, tire-pressure warning, traffic lights all translate to simple actions. Even the check engine light wants you take an action (which is true even if you ignore it).

A lot of visualizations I see elsewhere aren’t that clear. It’s easy to make charts in most software that has data, and the easiest thing to do is to pick a chart template and populate it. It practically makes itself.

The problem is that many visualizations are communicating the list of data and not the action. Instead of random lines going up and down periodically, I want a green or red light*. And just like in my hometown of Queens, if I don’t pay attention to the light, a honk.

* Augmented for color-blindness and accessibility, of course

March 2021 Blog Review

This month I released a podcast. I believe that a podcast can be a companion to another activity. I had thought that I could come up with something related to coding, but that was too hard to do without visuals.

So, I decided to try a writing program for programmers. Write While True is a podcast that helps programmers establish a writing habit. Each episode is around 10 minutes, and you are meant to do the writing exercise it describes as soon as the podcast is done.

If you are finding this post way after March 2021, and you are interested, I recommend listening to the first few episodes. They are foundational and meant to be evergreen. If you are a programer that writes publicly and has some tips, get in touch, because I’m going to have guests at some point.

I’m proud that my process makes my podcast accessible.

I’m thinking a lot about Excel. I have seen a lot of non-programmers make incredible things with it. I wrote Excel is Programming and Excel as a Programming Language with my nascent thoughts on that. I plan to write more about this.

I had a lot of random pieces related to software development:

Yesterday, I wrote about sonifications, which are the sound equivalent of visualizations. I’ll have a lot more to say about that in April.

What is the Sound Equivalent of a Visualization?

Visualizations are well-studied, understood, and popularized. They are a part of every day life—we see weather maps, activity circles, and stock charts every day.

We know the names of the patterns: bar chart, pie chart, line chart, etc. We learn them in grade school. You probably put one in your slide deck last week.

I’ve often wondered why this was not true of Sonifications. If you’re like me, this term will be new to you. It actually took me a while to find it—my google searches came up with Auralizations and Audibilizations first. But, if you’re talking about trying to understand data with sound, the correct term seems to be Sonification.

There is a body of research about it in academia, but it doesn’t extend much outside of there. As far as I can tell, there is no equivalent to Edward Tufte’s visualization books, but for sound. There is no way to make them in Excel.

But they are all around us. We hear, make, and use them all of the time.

Consider just the ones you might encounter while driving.

When you honk your horn, you are conveying information about your car and mood to others. Similarly, an ambulance uses a siren to convey their position and direction to you.

My car tells me (with beeps) if I am drifting out of my lane. It gets even madder if I am about to hit something. It beeps whenever I shift into reverse. Turning signals remind me to turn them off with a steady metronome-like beat. So do the hazard lights.

I get warnings when my lights are left on, the keys are locked in, or if I don’t fully shut the door.

If my radio is tuned to traffic, that’s a kind of Sonification (data -> speech). My GPS does the same kind of thing for directions.

Radar detectors buzz if they detect the fuzz.

So, I hope I have convinced you that Sonifications are common. In my own thinking I have come up with these few similarities that seem to tie them together

  • Sonifications are real-time
  • Sonifications are actionable
  • Sonifications interrupt you while you are engaged doing something else

This is why we use them in a car. You are completely busy, with your vision fully engaged in a life or death activity. The sonifications are there to tell you that something important needs to be done right now.

Giving Actionable Feedback on UI Design

I cringe when I hear a GUI described as “ugly”. It’s not that I don’t see it too, but the feedback isn’t helpful. I can’t set the ugliness lower.

If something looks “ugly” to you, use that to guide your attention and analysis. What we often perceive as ugly is rooted in rules of perception and communication.

To give you an idea, considering just the visual look of a design (not its interactions), try to judge

  • How easy is it to see the entire UI as various levels: as a whole, as a collection of a few parts, at a detail level.
  • How quickly can you scan and visually acquire a component.
  • How correct is your intuition on how a component would work based on what it looks like
  • How easy it is to tell things apart.
  • How easy is it to group things

Then, try to express you critique as: this “attribute of the design” doesn’t accomplish “this specific communication goal”

Here are some examples of what I mean:

  • The button icons aren’t easy to tell apart so they are hard to find right away.
  • The buttons need more padding because the text is too close to the border, making it harder to read.
  • I can’t tell the difference between the various header levels
  • The colors of the icons don’t feel like they come from a unified palette. Let’s try to match their saturation and brightness levels.
  • It isn’t clear if this visualization means that the state of the system is good or bad — it needs more context
  • There isn’t enough contrast between the most important parts and rest of the UI
  • There isn’t enough whitespace helping to form a hierarchy of information
  • The spacing between paragraphs isn’t proportionate to the font and line height. It makes it harder to read the text.

Look at the visual variables: colors, values (lightness/darkness), sizes, positions, and shapes. Consider whitespace. Look at the relationships between the components.

Consider if there is too much or too little contrast. Is there harmony between things that are supposed to be the same? Do the most important things draw the eye? Can you scan?

These are just the surface level. Bad UIs are usually bad at a level deeper than that. But if it looks “ugly”, expressing that as contrast/harmony of visual variables is more actionable.

Call for Write While True Podcast Guests

A couple of weeks ago, I launched Write While True, which is a writing program for programmers (in the sense of a training program). The core episodes will be short descriptions of writing exercises that will get you writing.

But, I do think it would be good to have guests.

In a guest segment, I do want to eventually get to some actionable advice, and I think it would help if the guest wrote regularly somewhere, since the core thesis is that the podcast will help you write more.

If you are a programmer, then it’s fine if that writing is on a blog, but if you are not a programmer, then I would prefer that you are a professional writer of some sort.

If this sounds like you, get in touch.

New App-o-Mat Article: Why You Should Use SwiftUI for Developing Apple Watch Apps

I am developing a series of articles based on my experience developing Sprint-o-Mat. The first one explains Why You Should Use SwiftUI for Developing Apple Watch Apps.

My Apple Watch app, Sprint-o-Mat, was originally an iPhone/Watch app combination because, at that time, a Watch app needed to be paired with an iPhone app.

Then, 3 months after I started, Apple changed everything about Apple Watch app development.

I’ll be covering Apple Watch app development in detail, with an emphasis on workout apps. Subscribe to get email notifications of new articles if you want to follow along.