unify tables/listings

[chadwhitacre]

We achieved consistent charts in #3067. Let's do the same for our tables/listings:

• explore
• search
• members
• receiving
• giving
• history
• events
• elsewhere teams

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Changaco]

Is charts.js really an example ? I protested when you threw out my d3 code and what I said still stands.

What exactly would tables.js library do ? What would it do that a generic jQuery table plugin doesn't ?

(Also, there are no tables on the search page.)

[chadwhitacre]

(Also, there are no tables on the search page.)

Not yet. In #3221, I'm proposing that we unify the Explore and Search interfaces.

[chadwhitacre]

Is charts.js really an example ? I protested when you threw out my d3 code and what I said still stands.

Yes. Here's your protest:

The new tip distribution charts look terrible, and I'm not convinced that writing our own code instead of using d3 is a good idea.

There are two concerns here:

1. Design of the user experience.
2. Choice of tools.

As much as possible, (1) needs to drive (2), and not the other way around.

When we do get to tooling decisions, we find a trade-off between control and convenience. We err on the side of control. Yes, we could use Django or Rails with their ecosystem of convenient plugins and ORMs. Instead, we use Aspen and PostgreSQL, because that gives us more control. Yes, that also makes us responsible for the bugs in Aspen and Postgres.py, but it's worth it to us for the increased control. Some day we'll port to Haskthon for the same reason. ;-)

Re: D3 in particular, #1278 was actually the second instance of the tail wagging the dog (and afaict the D3 implementation of the tip distribution chart was primarily @cakey's, not yours). The first was #937. I had suggested in #792 that we switch to D3 without changing the UX, because I also wondered whether "writing our own code instead of using d3 is a good idea." We tried to switch to D3 in #937, and we failed to achieve the user experience we wanted, so we abandoned the attempt. D3 did not give us the control we want.

What exactly would tables.js library do ? What would it do that a generic jQuery table plugin doesn't ?

It would do exactly what we want it to do. It would give us more control than a generic jQuery table plugin.

When you said that the new tip distribution charts look terrible, @clone1018 asked you to say more, and you didn't answer:

[H]ow does the chart look terrible? Is it the data or the actual design of the chart?

That's the primary conversation we should be having, about both charts and tables: what user experience do we want to deliver?

[Changaco]

We tried to switch to D3 in #937, and we failed to achieve the user experience we wanted, so we abandoned the attempt. D3 did not give us the control we want.

That's not what I'm seeing in #937. From what I can tell the problem was that you tried to port to SVG while keeping the exact same look and behavior as the HTML version, thus ending up thinking "Why are we wasting time rewriting this if we don't want to change anything ?".

It would do exactly what we want it to do. It would give us more control than a generic jQuery table plugin.

That's a non-answer, what do you want it to do ? Do we have special needs that can't be addressed by a generic solution and justify writing our own custom thing ?

[H]ow does the chart look terrible? Is it the data or the actual design of the chart?

Screenshot from #2499:

Screenshot from today:

Some day we'll port to Haskthon for the same reason. ;-)

My current name for that still-at-the-concept-stage language is Croc. ;-)

[chadwhitacre]

My current name for that still-at-the-concept-stage language is Croc.

Noted. :-)

[chadwhitacre]

Screenshot from #2499:
Screenshot from today:

Here are the problems with the old tip distribution charts, and how they're fixed in the standardized tip distribution charts:

• The X axis breakpoints—1.78, 3.16, and 5.62—are awkward and unintuitive.
  The standard charts use the more intuitive breakpoints 1, 2, and 5.
• The whitespace between bars is distracting, and inconsistent with our other charts.
  The standard charts have no whitespace between bars.
• The Y labels on each bar are "chartjunk," i.e., pixels which neither directly represent data nor are strictly necessary to orient the viewer.
  The standard charts show the maximum value, which orients the viewer to the Y scale, providing sufficient information for comparison across bars; specific information is available on hover/click.
• Same for the X labels.
• The X axis label is inconsistently aligned.
  The standard charts consistently align the X axis label.
• In the X axis label, "in US dollars" is redundant with the unit specifier "($)."
  The standard charts only use the unit specifier, "($)" (the whole site is in USD, so the dollar sign here is not ambiguous).
• The charts have no title, but are introduced with prose instead. The Y axis labels are redundant with the prose introductions.
  The standard charts have titles that explain the meaning of the Y values.

In general, I subscribe to the Tuftean school of data graphics: Data graphics exist to assist viewers in comprehending patterns in data, i.e., information. Therefore, pixels should either directly represent data, or minimally orient the viewer to the data. Pixels that don't serve this purpose are a distraction that Tufte calls, "chartjunk."

If you would like to continue to claim that "[t]he new tip distribution charts look terrible," please explain your reasoning.

One thing I don't like about the standardized tip distribution charts is that the bars are too wide relative to the labels and to other charts, due to the fewer number of bars compared to the time series charts. If we want to tinker with the tip distribution charts let's make a new ticket. The current ticket is about standardizing tables across the site, with our general treatment of charts being a parallel.

[chadwhitacre]

The current ticket is about standardizing tables across the site, with our general treatment of charts being a parallel.

In short: I want to see us have a consistent, principled approach to the design of our tables and/or item listings, just as we do with our charts.

That's a non-answer, what do you want it to do ? Do we have special needs that can't be addressed by a generic solution and justify writing our own custom thing ?

Here's how to answer this question:

• Fill out the rest of the IA on discuss roadmap based on information architecture #3220.
• Identify all of the places where we need a table and/or item listing.
• Determine what the needs of all our specific tables/listings are.
• Visually design a solution that addresses all our needs.
• Evaluate tooling options to implement the visual design we want.

I've updated the title and description of this ticket to better reflect the purpose here (I was wagging the dog myself by leading with, "Custom library!").

[chadwhitacre]

The newly revised Product page indicates what pages currently have a table/listing on them.

[chadwhitacre]

https://techblog.livingsocial.com/blog/2015/04/06/responsive-tables-in-pure-css/