We have an interface that shows a list of sports games. Some of them are canceled and need to be indicated as such.

We have a status column (7th) that indicates whether the game was played or not, and whether it was canceled or not.

The issue we have is we need a very clear way to indicate to users that a game has been canceled. The status column has a status indicating icon (a red ban symbol) but some users hide the status column because they don't use it ever and then they completely miss the fact that the game was canceled.

I've been asked to make canceled games have a red background, but that would really clutter the interface. Canceled games aren't frequent, but probably frequent enough that having any significant number of the rows a red color would significantly add to the difficulty of using the screen.

Some other ideas are to have a red strike through the whole row. That's less clutter than a red background for the whole row, but I don't know if that's the best way to indicate that a game was canceled.

Here's what the main interface looks like:

Interface overview

Here's what a row looks like in detail. Note that it has a canceled game.

enter image description here

So the ask - What are some good ways to indicate an important piece of information in a table without cluttering the screen?

  • How about moving those icon-only columns to the beginning of the row? Having the icon at the beginning of the row makes it quick to spot when an icon is different to those around it (plus it's not in the middle of the table somewhere so finding the icon in relation the event name could be quicker too)
    – Harrison
    Mar 22 at 17:00
  • A very light-red background might be subtle enough to help indicate the event was cancelled, maybe something like #FFE3E5 or rgba(255, 0, 0, 0.1);
    – Harrison
    Mar 22 at 17:02
  • One other thing that just popped into my head is to have a thick border-left value, a bit like the Bootstap callouts codepen.io/superjaberwocky/pen/rLKxOa or getbootstrap.com/docs/5.3/customize/components/…
    – Harrison
    Mar 22 at 17:23
  • Thanks, Harrison. Those are some good ideas. I thought of something else. The status we are concerned about is transient - after a short time it goes away for a given row. So it won't really clutter the interface if we make it red or somehow very obvious because it is a special case. Mar 22 at 23:48

1 Answer 1


Graphic Coding 101

The most elemental elements for graphically coding an attribute include:

  • Color (which includes brightness, hue, and saturation)

  • Frequency (which includes density, rate, weight, and size)

  • Orientation

These can be applied to:

  • The foreground (the font, in your case)

  • The background

  • Borders

For example, using color you could indicate canceled events with:

  • Red background

  • Red font

  • A red box around the row

Or maybe you just use the brightness level of the color. For example, give canceled events a pale gray background.

Roughly speaking, frequency is how much space something remains the same before it visually changes somehow. For example, the border around a canceled row may be thicker than the others, may be dashed or dotted while the others are solid, or the entire row could be taller than the others. Orientation is the angle of something, for example italic versus normal font. Strikethrough and underlining are also orientation in that they add a strong horizontal visual element. The elements can be combined to make patterns and textures. For example, canceled events may have a background of pink diagonal stripes. Pink is color coding, the stripes (of a given size and spacing) are frequency coding, and the diagonal orientation of the stripes are, well, orientation. From these principles, you can probably dream up countless ways to code canceled events.

For more on graphic coding, see my old blog posts Graphics of Distinction and Putting the G into GUI.

Indicating Importance without Cluttering the Screen

The question for you is:

  1. How much do you want your graphic coding to stand out?

  2. What codes will be easily mentally associated with the attribute value (“Cancelled” in your case)?

The first question is easier to answer. The greater the difference between an object and its surroundings on the three graphic dimensions combined, the more it stands out. A bright red row among white rows stands out a lot. A bright red row among barn-red rows not so much. It also depends on the variability of the surroundings. A bright red row stands out pretty well if all the other rows are barn red, but not so with other rows being a mix of light green and dark teal and burnt orange and so on.

You are correct that large graphic differences (e.g., several red rows when the surrounding rows are white) can make for a cluttered appearance. However, that does not necessarily adversely affect user performance, so it may be more an aesthetic or emotional-experience question (e.g., do you want an “exciting” table of events, or a “calming” table of events?). Generally, you can judge just by looking how much graphic difference is enough for the users’ task. The real questions is, what is the users’ task?

1. Find the canceled events -> Large difference. If the users’ task is to find canceled events (e.g., in order to send refunds to event-goers), then you need a relatively large graphic difference. You want to make those rows to “pop out” and draw the eye as the user skims the table. A red background will certainly do that. However, if all the other rows are plain white (low variation in the surrounds), a smaller difference such as a pale pink background, like Harrison suggests, will work just as well.

2. Realize event is canceled -> Small difference. If the users’ needs to realize an event is canceled once they find it (by some other attribute), then you only need a small graphic difference, since they’re already looking at the event. A big difference can distract the user from the events they're supposed to be looking at. An example of this task is a user to preparing to go to a specific known event so is checking the table for a place and time. A change in font color or style (e.g., italic) will be enough to indicate that something is up.

3. Ignore the canceled events -> ”Negative” difference. If the users’ task is to skip over the canceled events and focus on the non-cancelled ones (e.g., the users are looking for an event they want to attend), then you want the event to have a small difference from the background, so the font doesn’t stand out. “Graying” the font will do that. Dithering font (frequency-coding) or making it transparent (if there’s varying background) will work too.

As for the second question, you want a code that indicates “not there no more,” like your ban symbol. Regardless of the size of graphic difference you need, I would not go with a color code, in particular not a hue code like red, at least not by itself. Color codes in general tend to be arbitrary. There are stereotypical meanings associated with hues in various cultures, but not necessarily anything for “not there” really. In western cultures, red can mean Important or Urgent Action Needed or Danger or Stop. Which meaning users use can be unpredictable. Does red mean an event is about to happen so you have to get to it right away? Unless the users’ task is to act right away on a canceled event or else bad things may happen (e.g., the user should post a cancellation notice to keep people from showing up), I’d avoid simple red coding (or any color coding), whether it’s the background, foreground, or border.

Actually, I'd stay away from coding in borders in general, and shy away from coding the background as well. Too often these codes mean "selected" in apps. That's probably not what you want.

If the purpose of coding canceled events is to keep users from going to canceled events, I would favor graphic coding that suggests deletion. Strikethrough certainly suggests that. Graying out the item works too, but getting a compelling gray-out may break W3C guidelines. If the user’s task is more along the lines of Task 2, you can reduce apparent clutter by limiting the strikethrough to just the event name and maybe event date-time. That will tell users that whatever event was occurring it’s not this one any more, or whenever the event will be, it’s not at this date-time any more.

Personally, if we're talking untrained infrequent users of the table, and it’s really important to know if an event is canceled, then I would super imposed “CANCELLED” in transparent font over the event name regardless of the columns the user has hidden. Let’s not make the user guess what our codes mean.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.