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.
+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.
Agreed that the font change seems like a wash. At first I thought OP was trolling the reader with two identical screenshots :)
I suppose the real benefit is having a font available across all platforms. Inter appears to be a high quality typeface, and I appreciate its author for releasing it under an open license. [1] [2]
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.
Maybe see how the library from https://www.ag-grid.com/ does it or just use their library. If you check how many open bugs most JS grid/table projects have, it's clear implementing a robust grid with many features is really hard. I've used ag-grid for projects before and can recommend it (works with all major UI frameworks).
I'm afraid I have no tip to offer, but I can empathise because we've run into the same problem and we too are still looking for a good solution.
I think tables just don't sit well in HTML. We are trying to force a 2D structure where useful operations might be based on either dimension into a flattened hierarchical structure where one dimension must take priority, and that is awkward. The attempt to work around this by introducing colgroup and col elements never really went anywhere either.
So for now, we resort to tricks like artificial DOM structures and pretend margins/padding and manual positioning, the same kind of hackery that we used to use for page layouts until tools like flexbox and grid were introduced. What we really need, IMHO, is a similarly comprehensive set of dedicated table selectors and styling options in CSS. There have been proposals like the nth-col pseudo-class and the || column combinator, which look like useful ideas, but again these haven't really gone anywhere so far. There might be some value in allowing tables to be styled as row-major or column-major (a similar idea to flex-direction) and then basing other styling around the major and minor axes rather than relying on rows/children and columns specifically.
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.
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.
The most successful I’ve been at this is clever uses of position: sticky. You have to fall back to absolute positioning and scrolling the fixed headers in JS on browsers that aren’t as advanced in their position: sticky support though.
I figured it out without using JavaScript. The trick is to use a <th> on the first child of each tr, which becomes the sticky left column. Position sticky works on th’s.
It’s not ideal, but this works on about 95% of all browsers.
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.
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
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.
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!
"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...
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.
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! >.>
