Live data from Hacker News

The design philosophy of Great Tables

posit-dev.github.io

41–50 of 94 posts

Re: The design philosophy of Great Tables

#41

The example they show of a Great Table is, to my taste, way too busy. Here is my unsolicited opinion: The top and bottom horizontal rules on the Title appear to be superfluous, and I dislike how it is aligned with the first column (row labels) rather than the second. I feel like a little space to breath at the bottom, along with a bold font would add visual hierarchy w/o the clutter. The row label backgrounds are far…

the white text on a dark background really was a glaring misfeature in the original example, to the extent that i wonder if the colours looked different on the author's monitor

Re: The design philosophy of Great Tables

#44

This looks great. I so wish that the HTML table element would get some progress - it’s so limited. I don’t want to have to use some JS library component just to show tabular data especially given how badly they perform one big - but a server side rendered HTML table can be enormous and render fine. But again, so limited.

Past a certain table size, the JS libraries will use less memory. DOM elements take a lot of memory. Libraries like ag-grid only render a small portion of the total table at a time.

The next performance gain web tables comes from using a binary encoding instead of JSON, particularly arrow. Perspective uses arrow (in addition to rendering to canvas).

IME building buckaroo on top of ag-grid, I can render the table with up to about 300k elements very performantly with just JSON. Rendering speed is a non factor because only 50 rows are rendered at a time. Moving to arrow-js should be about 3 times faster for the entire system (python serialize, js deserialize, js render). Beyond 900k elements, you really want to lazily load from the server as the user scrolls. The memory usage for just the data in the browser tends to slow things down. (I am working on a library and benchmark for different serialization techniques).

Re: The design philosophy of Great Tables

#45
Something that always annoyed me about numeric data like dollar amounts in tables is that visually the comparison between quantities is logarithmic instead of linear.

E.g.:

    Cost
    $1500
     $130
     $110
     $210
The text in the last three rows look 4/5ths the size of the text in the first row. However, even if summed, the last three costs add up to only 1/3rd of the top row! People visually see the number digits, which is roughly the same as Log 10.

I’ve so often had this issue that I started putting in-cell bar charts into every finance-related spreadsheet.

Otherwise meetings will get derailed debating the cost of something trivial that is totally irrelevant compared to the biggest absolute costs.

As a real example, I had many meetings spent debating a $15 monthly cost for server log collection in the cloud for a VM running a database engine that costs $15K monthly for the license alone.

Re: The design philosophy of Great Tables

#46

The example they show of a Great Table is, to my taste, way too busy. Here is my unsolicited opinion: The top and bottom horizontal rules on the Title appear to be superfluous, and I dislike how it is aligned with the first column (row labels) rather than the second. I feel like a little space to breath at the bottom, along with a bold font would add visual hierarchy w/o the clutter. The row label backgrounds are far…

You might want to read Edward Tufte's Beautiful Evidence.[1] He discusses stuff like what you brought up about readability and distracting from the message / point of the data.

If you've seen sparklines, [2] Tufte coined the term.

Whenever I do a UI review I end up paging through it just to see if there's something we're not thinking about, and its an interesting book to just open to a random page and read.

Plus he has an entire treatise on why PowerPoint is terrible.

[1] https://www.edwardtufte.com/tufte/books_be

[2] https://en.wikipedia.org/wiki/Sparkline

Re: The design philosophy of Great Tables

#47
post #44

This looks great. I so wish that the HTML table element would get some progress - it’s so limited. I don’t want to have to use some JS library component just to show tabular data especially given how badly they perform one big - but a server side rendered HTML table can be enormous and render fine. But again, so limited.

Past a certain table size, the JS libraries will use less memory. DOM elements take a lot of memory. Libraries like ag-grid only render a small portion of the total table at a time. The next performance gain web tables comes from using a binary encoding instead of JSON, particularly arrow. Perspective uses arrow (in addition to rendering to canvas). IME building buckaroo on top of ag-grid, I can render the table with…

>Libraries like ag-grid only render a small portion of the total table at a time

such libraries often mess the scrolling and searching up

Re: The design philosophy of Great Tables

#48

The example they show of a Great Table is, to my taste, way too busy. Here is my unsolicited opinion: The top and bottom horizontal rules on the Title appear to be superfluous, and I dislike how it is aligned with the first column (row labels) rather than the second. I feel like a little space to breath at the bottom, along with a bold font would add visual hierarchy w/o the clutter. The row label backgrounds are far…

You might want to read Edward Tufte's Beautiful Evidence.[1] He discusses stuff like what you brought up about readability and distracting from the message / point of the data. If you've seen sparklines, [2] Tufte coined the term. Whenever I do a UI review I end up paging through it just to see if there's something we're not thinking about, and its an interesting book to just open to a random page and read. Plus he h…

> Plus he has an entire treatise on why PowerPoint is terrible.

As someone trying to build a PowerPoint competitor, this is awesome. I'm going to start here and work my way through his whole corpus

Re: The design philosophy of Great Tables

#49

Earlier quoted context omitted.

You might want to read Edward Tufte's Beautiful Evidence.[1] He discusses stuff like what you brought up about readability and distracting from the message / point of the data. If you've seen sparklines, [2] Tufte coined the term. Whenever I do a UI review I end up paging through it just to see if there's something we're not thinking about, and its an interesting book to just open to a random page and read. Plus he h…

> Plus he has an entire treatise on why PowerPoint is terrible. As someone trying to build a PowerPoint competitor, this is awesome. I'm going to start here and work my way through his whole corpus

See also https://norvig.com/Gettysburg/
Post reply on HN