Cell background color

[seancolsen]

In #1280 I'm adding new functionality that gives more granular status info (loading, success, error) at the cell level instead of the row level.

In our design, we're using background color to communicate a lot of things:

	Scenario	Cell background
1	Row is newly added	green
2	Row failed to add	red
3	Row is deleting/adding	yellow
4	Row is selected	blue
5	Row is hovered	gray
6	Cell is in edit mode	white
7	Cell has client-side validation errors	red
8	Cell has server-side validation errors	red
9	Cell is being updated	yellow
10	Cell has been updated	green

Notice that all of those scenarios are independent. Almost any combination of them can be true at once. Thus, deciding the appropriate color for the background requires some complex triage.

I'm wondering if we can improve this design a bit, hopefully simplifying it.

[seancolsen]

Proposal:

• Eliminate scenarios 1 and 10 (no more green background after data is updated). I don't like the green background. It's not consistent with spreadsheets or AirTable or DB GUI tools. It makes me always want to hit the refresh button after editing a cell.
• For 4 and 5, use translucency to ensure that hover color and selection color will combine with the other colors. That's consistent with AirTable, but not how we're doing it now.
• ...I still need to give some more thought to the rest, but that's what I've come up with so far.

(I'll continue fleshing this proposal out soon. I just wanted to start this discussion now since some of these issues came up in #1280 and I didn't want to bog the PR down by having this discussion in the PR.)

[kgodey]

In additional, I think we could also eliminate the yellows. I don't think we should be drawing the user's attention to a cell unless it's responding to their action (select, hover) or there's an action they need to take (fix an error of some sort).

[pavish]

@kgodey yellow is a response to their action, where something is being updated after a user interaction.

@seancolsen Here's the issue:

• We cannot compare ourselves to Airtable or spreadsheets. Airtable maintains the complete state of table on the frontend, and syncs changes to the backend with websockets. Google sheets also maintains an open live connection. Their updates are fast.
• We rely on regular http requests at the moment, which are substantially slow. For eg., Work with your network settings throttled to 3G or less, you'll notice not having state indications making it a lot harder. Slow network connections are very common, atleast in my side of the world. I'd suggest never relying on the request completing fast enough for a frontend interaction.
• Having said that, I also hate the green background.

My suggestions:

• Use a timeout to clear the green backgrounds after 5 seconds (or 3). It will let the user know that the row/cell has been updated, but clears automatically thereby not annoying the user.
• Let's retain yellow (or make it even lighter), since it only appears while a request is in progress. It would change to green (and get cleared) or red based on the response.

[pavish]

For 4 and 5, use translucency to ensure that hover color and selection color will combine with the other colors. That's consistent with AirTable, but not how we're doing it now.

I think this is a good idea.

[kgodey]

@kgodey yellow is a response to their action, where something is being updated after a user interaction.

Yes, but the user can't do anything about it. Their eye gets drawn to it due to the color change but there's no actual action to take. Selecting/hovering is an active action that fits into the user's current task.

In various design books I've been reading, one of the principles that keeps coming up is not to interrupt the user's flow in completing the task they're doing. As a user, I don't care if something is in the process of saving or how long it takes as long as it eventually saves.

Turning the whole record a different color draws my attention to it and makes me think "Why did that happen? Do I need to do anything?" and over time, that slowly adds up.

---

I'm not going to keep pushing it, though. I think it's better to make a decision quickly than to make the correct decision, we will probably need to make changes after usability testing anyway.