The design philosophy of Great Tables • Hacker News Board

Re: The design philosophy of Great Tables

#81

Post by wglb » Fri, Apr 05, 2024, 2:00 PM UTC

Someone wrote: post #80

wglb wrote: post #57

This a good article with some fascinating history. More recent history involves the production of CALS tables https://en.wikipedia.org/wiki/CALS_Table_Model . The company Datalogics https://en.wikipedia.org/wiki/Datalogics was heavily involved in the CALS table initiative. Datalogics staff was part of the ISO committee forming SGML, and trained many people on SGML, including DoD staff and their contractors involved w…

> This a good article with some fascinating history. Indeed. I don’t think it’s all correct, though. On Visicalc, it says “The grid cells couldn’t be styled with borders for presentation purposes, the values couldn’t be formatted, and the tables couldn’t even be printed” I think I even the first version had (limited, of course) formatting support. http://www.bricklin.com/history/refcard3.htm says the “/F” command all…

Thanks for noting this.

While the article is overall good, there is a bunch of history that is not covered, or covered too briefly.

Re: The design philosophy of Great Tables

#82

Post by TheCleric » Fri, Apr 05, 2024, 2:22 PM UTC

itronitron wrote: post #79

esafak wrote: post #49

Earlier quoted context omitted.

See also https://norvig.com/Gettysburg/

According to everyone that has ever told me how to do powerpoint presentations, they need an intro slide that tells the audience what they are about to be told in the presentation they are about to be told, and a conclusion slide that tells the audience what they were told in the presentation they were told.

I don't think that's just powerpoint though. This is a common public speaking method: https://quoteinvestigator.com/2017/08/15/tell-em/

Re: The design philosophy of Great Tables

#83

Post by NickFanion » Fri, Apr 05, 2024, 2:30 PM UTC

narush wrote: post #13

This is an excellent blog post - I'd never heard of Great Tables before, and I'm a newly minted fan! > confronted with an all-too-familiar dilemma: copy your data into a tool like Excel to make the table, or, display an otherwise unpolished table. One add-on (coming from the past 4 years of working on a tabular-data from Pythons startup [1]) is that users aren't just copying data into Excel because if it's good forma…

Playing nice with Excel (and PowerPoint) is an underrated feature. The next step I see from business users is taking the formatted Excel table and pasting it into a PowerPoint slide. The hacker mindset often says the Microsoft Office suite is the wrong tool for the job, so we should use X tool and Y process instead. That may be true, but there's so much institutional inertia at established organizations that it's hard to completely abandon the Office suite. Anything that lets a technical user do something programmatically, but allows the output to be easily manipulated by a non-expert is invaluable.

I've had success generating svg visuals and placing them in slides, which PPT treats as a "shape" (the Graphics Format ribbon appears), and business users like that they can modify the shapes (for example, change the color). Great Tables supports pdf export, but not svg. I just tested a pdf vector in the current version of PPT, and while it maintains the vector, PPT won't let me convert it to a shape (only the Picture Format ribbon is available). Great Tables doesn't seem to support svg export directly, so there needs to be an additional pdf -> svg conversion.

Re: The design philosophy of Great Tables

#84

Post by digging » Fri, Apr 05, 2024, 3:13 PM UTC

throwaway81523 wrote: post #8

This article is mostly blither, whether or not it is AI generated. It is about a Python library for generating nicely formatted HTML tables, though they don't tell you much about it til the near the end. The library seems to use an OOP approach. An alternative approach might be more declarative. The product name "Great Tables" appears in boldface over and over (no idea if the font helps SEO) and the name itself is aw…

Actually, it's a near-perfect article from my point of view. I don't (regularly) work in tables, I'm not immersed in data visualization culture, and I wouldn't have thought twice about reading a simple "here is our product" page aimed only at people who already know what they're looking for.

However, this article gave me some really interesting and valuable background material and then concluded with solid, crystal clear (even to me, who's never written python) examples. I actually came away thinking, "well, this look fun - I should spin up some toy project to play around with this and learn how to use it."

Re: The design philosophy of Great Tables

#85

Post by hughess » Fri, Apr 05, 2024, 3:26 PM UTC

Great article and big fan of this approach.

I'm one of the maintainers of Evidence (open source tool based on markdown + SQL) and working on a similar approach to creating presentation tables configurable in code.

Some examples here for any SQL + table enthusiasts: https://docs.evidence.dev/components/data-table

Re: The design philosophy of Great Tables

#86

Post by thih9 » Fri, Apr 05, 2024, 3:43 PM UTC

I am missing a section on UX best practices and in particular: intuitive and touch friendly solution for multi column sort.

All approaches I’ve seen here have some issues; worst of all being “press shift to sort by multiple columns” (not touch friendly).

Re: The design philosophy of Great Tables

#87

Post by AvAn12 » Fri, Apr 05, 2024, 4:34 PM UTC

Wonderful! In the 90s a colleague and I wrote a book (EBRI Datebook on Employee Benefits) which was mostly tables. In addition to SAS, our other primary tool was an ancient language called Table Producing Language ("TPL"). Despite dating back to the 1970s, TPL was incredibly flexible, expressive, and efficient - once you figured out the syntax.

The designers of Great Tables might want to check out TPL. It covers everything Great Tables aims to do, and I think may have a few more tricks up its sleeves:

https://www.ojp.gov/pdffiles1/Digitization/68013NCJRS.pdf

Regardless, thanks for making Great Tables! This goes a long way towards making table producing in python much better.

Re: The design philosophy of Great Tables

#88

Post by layer8 » Fri, Apr 05, 2024, 5:36 PM UTC

thih9 wrote: post #86

I am missing a section on UX best practices and in particular: intuitive and touch friendly solution for multi column sort. All approaches I’ve seen here have some issues; worst of all being “press shift to sort by multiple columns” (not touch friendly).

The simple trick is sort the respective columns one after the other, starting with the least significant one. E.g. if you want to sort by columns A, B, and C, first sort by C, then sort by B, then sort by A. If the sort is stable (which it should be), this will result in the desired multi-column-sorted state.

Of course, this isn’t intuitive in the sense of being self-evident, but once you know this method, it basically works almost everywhere.

Re: The design philosophy of Great Tables

#89

Post by layer8 » Fri, Apr 05, 2024, 5:47 PM UTC

paddy_m wrote: post #44

simonbarker87 wrote: post #23

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…

> DOM elements take a lot of memory.

Due to their regular structure, tables would provide an opportunity for HTML implementations to optimize and greatly reduce that memory usage.

Re: The design philosophy of Great Tables

#90

Post by throwaway81523 » Fri, Apr 05, 2024, 8:06 PM UTC

digging wrote: post #84

throwaway81523 wrote: post #8

This article is mostly blither, whether or not it is AI generated. It is about a Python library for generating nicely formatted HTML tables, though they don't tell you much about it til the near the end. The library seems to use an OOP approach. An alternative approach might be more declarative. The product name "Great Tables" appears in boldface over and over (no idea if the font helps SEO) and the name itself is aw…

Actually, it's a near-perfect article from my point of view. I don't (regularly) work in tables, I'm not immersed in data visualization culture, and I wouldn't have thought twice about reading a simple "here is our product" page aimed only at people who already know what they're looking for. However, this article gave me some really interesting and valuable background material and then concluded with solid, crystal c…

I don't think I learned anything about tables from the pictures of rectangular grids found on cave walls. Most of us don't "work in tables", but we have all still seen some, made some, and know what they are.

You might read the famous Edward Tufte book, https://www.edwardtufte.com/tufte/books_vdqi