
A Case Study of Complex Table Design - tosh
https://jlongster.com/case-study-complex-table-design
======
schrototo
The font change seems like a wash to me. Notice how the decimal points and
thousands separators for the balance column don't line up in either of the
screenshots? A change that would actually improve readability would be to use
_tabular numbers_ , supported by both San Francisco and Inter.

~~~
divbzero
+1 on _tabular figures_ [1] but it appears to me that OP is already using
them? It’s hard to tell for sure but the 1 and 2 in 1,000.00 and 2,000.00 seem
to be aligned. The misalignment in decimals and thousands separators could
instead by caused by normal vs. bold font weight.

[1]: [https://practicaltypography.com/alternate-
figures.html#tabul...](https://practicaltypography.com/alternate-
figures.html#tabular-and-proportional-figures)

------
sixQuarks
I recently tried to design a table that had a sticky header row AND a sticky
first column. I couldn't figure out a way that worked well on both desktop and
mobile. All the solutions I found were janky in one form or another.

Anyone have good tips for this?

~~~
divbzero
This sounds tough.

A common solution, which qualifies as “janky”, is to render sticky rows in a
<div> element, completely separate from the <table> itself. If I remember
correctly, DataTables [1] takes this approach for its sticky headers. React
Table [2] takes a similar approach, and actually abandons <table> altogether
by using <div> elements for table body, rows, and cells.

[1]: [https://www.datatables.net](https://www.datatables.net)

[2]: [https://react-table.js.org](https://react-table.js.org)

I haven’t seen many solutions for sticky columns, but the least bad solution
might also be a “janky” separate <div>.

~~~
capableweb
The implementation here would decide if this is "janky" or not as in web-dev
circles, "janky" specifically refers to stuttering, lag, juddering and such,
not in general something that is "hacky" (poor or ad-hoc solution).

So if it's performant, it's not "janky" (again, in web-dev circles) but it
could still be a "hacky" implementation, even without any jank. It's also
different from "robust", so something can be not-janky but also not-robust.

------
troughway
Very good example of "kill your darlings" when it comes to removing slick
animations in favor of straightforward, no non-sense, zero latency feedback
for the user. I suppose there is some deep down desire to implement these
things that first must be realized, only to be quelled before it's shipped.

------
fovc
Another option for showing the trsnsition would be a very brief change in
contrast in the table (bg a little darker or text a little lighter). Your eyes
can still focus a spot, but you get the visual feedback of a change.

In my mind the bigger issue is being able to cancel or merge transitions if
scrolling quickly. Otherwise you end up like excel's animated cursor which
literally is slower now than before it was animated. Nobody likes scrolling
through molasses

------
bigtones
The images are so small it's hard to even tell what he is writing about. If
you're going to write 1,200 words on your new table design that is only
subtlety different to your old table design, maybe show said design at 100% of
the size when you click on one of the images.

~~~
ken
Ironically, if you make the window smaller, the images get bigger.

~~~
cjsawyer
Reading on mobile was just fine

------
Scarbutt
Probably should add HTML to the title. Though it was about SQL.

~~~
sjc01234
+10,000% !!!

------
jspash
Nice job overall. My only nitpick is that there are no affordances to know
that you can drag/drop elements. I've often started dragging things by
accident only to find out that it's the default behaviour of links. Probably
so you can drag them to the toolbar/desktop etc. If I didn't know about the dd
behaviour of this table, I would probably never use it. Otherwise it's pretty
nice!

------
cosmotic
The partial animation of the rows and columns sure makes things confusing;
until operations complete, the table is presenting inaccurate information.

------
mnsc
"Since the budget table is static in the new design, each row is rendered how
you would expect..." It would be nice to have one more "structure of the DOM"
image like the ones above for the new design. I tried to check with dom
explorer but there was a lot of divs...

------
DHPersonal
> Since the budget table is static in the new design, each row is rendered how
> you would expect: each row is inside a div.

I know it's probably petty of me, but I would disagree: I expect the contents
of a table to be placed within <table>.

------
chadlavi
Always remember to see what your blog looks like in a browser with content
blockers turned on. I was very confused why this guy would use Times New
Roman, turns out it's just a google font.

Also define backups!

------
kevindeasis
Thanks for this blog, I might actually write one in the future too from what
Ive learned from making tables.

I've never usually thought writing a blog about making tables would be a good
idea

------
stickfigure
Can you work on a replacement for Xero instead? Please, take my money.

------
sjc01234
See the words "case study" \- "complex" \- "Table" ... Start to read the blog
post and realize this is just a bunch of front-end stuff about fonts and
animations. >.> Misleading! >.>

