Tables are underutilized for how concise and descriptive they can be when making comparisons. It's a shame most text editors start with a blank table instead of inserting one pre-configured with some good design choices.
The design philosophy of Great Tables
11–20 of 94 posts
Re: The design philosophy of Great Tables
#12Fantastic article, duly bookmarked. However.
“The democratization of computational tables arguably began with VisiCalc in 1979… I mean, try it out and you’ll see that this is quite limited in more than a few ways.”
Them’s fightin’ words. IMHO VisiCalc’s ability to generate models quickly changed civilization. It freed people to try out ideas at no cost and to view or manipulate data in ways no one could hope to do before.
Re: The design philosophy of Great Tables
#13This 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 formatting capability: very often, there are organizational constraints that mean that Excel _needs_ to be where this data ends up.
The most common reasons I've seen for data ending up in Excel: 1. Other parts of the report rely on Excel features - you want to build pivot tables or graphs in Excel (often, these are much easier to build in Excel than in Python for anyone who isn't a real Pythonista) 2. The report you're sending out for display is _expected_ in an Excel format. The two main reasons for this are just organizational momentum, or that you want to let the receiver conduct additional ad-hoc analysis (Excel is best for this in almost every org).
The way we've sliced this problem space is by improving the interfaces that users can use to export formatting to Excel. You can see some of our (open-core) code here [2]. TL;DR: Mito gives you an interface in Jupyter that looks like a spreadsheet, where you can apply formatting like Excel (number formatting, conditional formatting, color formatting) - and then Mito automatically generates code that exports this formatting to an Excel. This is one of our more compelling enterprise features, for decision makers that work with non-expert Python programmers - getting formatting into Excel is a big hassle.
Of course, for folks who can ditch Excel entirely, this is entirely unnecessary. Great Tables seems excellent in this case (and anyone writing blog posts this good is probably writing good code too... :) )
[2] https://github.com/mito-ds/mito/blob/dev/mitosheet/mitosheet...
Re: The design philosophy of Great Tables
#14Does anyone know any similar projects that can render to an HTML canvas?
Re: The design philosophy of Great Tables
#15There's also a book on the subject: https://en.wikipedia.org/wiki/The_History_of_Mathematical_Ta...
Interesting aside: AI models trained on spreadsheets need "good tables" such as column names, headers, etc. to understand context. Like Fortap: https://arxiv.org/abs/2109.07323
Re: The design philosophy of Great Tables
#16There's also a book on the subject: https://en.wikipedia.org/wiki/The_History_of_Mathematical_Ta... Interesting aside: AI models trained on spreadsheets need "good tables" such as column names, headers, etc. to understand context. Like Fortap: https://arxiv.org/abs/2109.07323
Thanks for sharing the book info! I really need to find a copy of that somewhere :)
Re: The design philosophy of Great Tables
#17I'm interested in the midcentury modern ones because they have lots of vertical rules. I'm active on the subreddit for LaTeX and there is a religion common there that even one vertical rule is an unforgivable abomination.
Re: The design philosophy of Great Tables
#18Summary:
This article is about a Python library called “Great Tables” that is focused on the display of tables for publication and presentation (not for interactive browsing).
The article does not specify which output format it supports.
Also you get some bonus historical context on tables.
Re: The design philosophy of Great Tables
#19I'm interested in the midcentury modern ones because they have lots of vertical rules. I'm active on the subreddit for LaTeX and there is a religion common there that even one vertical rule is an unforgivable abomination.
Great summary of the problem on StackOverflow: https://tex.stackexchange.com/a/40555
Re: The design philosophy of Great Tables
#20I love this package and have been using it for a few years in R. It's great [for making] tables in html but the pdf and docx output is a little less polished. I do worry that the recent shift to bringing the python version up to speed with the R version has slowed down the R development. Though it's well worth checking out whatever your language.