UI considerations for designing large data tables
coyleandrew.medium.com
UI considerations for designing large data tables
1–10 of 30 posts
Re: UI considerations for designing large data tables
#2ag-grid is pretty great at all of this. it will get you 90% of the way there, then you just need to ensure you are ordering columns correctly and using the right types, and potentially using a few custom cell renderers to display novel data.
we're using it to infinite scroll / sort / filter a table with 3.2M rows of data and it 'just works'
Re: UI considerations for designing large data tables
#3this article is so pedestrian I'm puzzled why it's featured so highly here.
Re: UI considerations for designing large data tables
#4ag-grid is pretty great at all of this. it will get you 90% of the way there, then you just need to ensure you are ordering columns correctly and using the right types, and potentially using a few custom cell renderers to display novel data. we're using it to infinite scroll / sort / filter a table with 3.2M rows of data and it 'just works'
I'm struggling to think how I'd meaningfully do any of that with 3.2M rows. :(
I'm reminded of old books that were various number sequences for checking calculations. Clearly somewhat useful, but incredibly niche and seems to lose to other tools rather quickly.
Re: UI considerations for designing large data tables
#5this article is so pedestrian I'm puzzled why it's featured so highly here.
I was equally scrolling for the big reveal only to leave very unsatisfied
Re: UI considerations for designing large data tables
#6this article is so pedestrian I'm puzzled why it's featured so highly here.
Yes, articles like it (and some much more pedestrian) have made the front page in the last year or so, and I'm not sure why. Possibly I just didn't notice them before. Or maybe I'm getting smarter! :D
Re: UI considerations for designing large data tables
#7Wish HTML tables supported basic grid features like column pinning. Sadly you have to resort to bypassing `table` and instead use divs.
Re: UI considerations for designing large data tables
#8ag-grid is pretty great at all of this. it will get you 90% of the way there, then you just need to ensure you are ordering columns correctly and using the right types, and potentially using a few custom cell renderers to display novel data. we're using it to infinite scroll / sort / filter a table with 3.2M rows of data and it 'just works'
I've tried ag-grid but trying to make it look consistent across light and dark mode was a pain. The available light and dark themes have a lot of discrepancies. To make it look right you have to dive deep into its styling system which is complex.
Re: UI considerations for designing large data tables
#9I feel the tension when just looking at those screenshots, thinking of trying to utilize a large table in a website UI - JavaScript, scrolling, dynamic updates, the pauses and hangups, Internet latency, etc., plus the very limited capabilities.
Just give me my local spreadsheet app. Your web UI is never going to come close to that speed and functionality.
I understand that might not fit every use case, but I guess that any user unwilling to use a local spreadsheet will not be interested in the the 'big data' of the complete, large table. In that case, cut the large table to a small one, appropriate to your platform and users, and provide a link for the data scientists to download the full thing.
Re: UI considerations for designing large data tables
#10ag-grid is pretty great at all of this. it will get you 90% of the way there, then you just need to ensure you are ordering columns correctly and using the right types, and potentially using a few custom cell renderers to display novel data. we're using it to infinite scroll / sort / filter a table with 3.2M rows of data and it 'just works'
I'm struggling to think how I'd meaningfully do any of that with 3.2M rows. :( I'm reminded of old books that were various number sequences for checking calculations. Clearly somewhat useful, but incredibly niche and seems to lose to other tools rather quickly.
Hope I do not misunderstand your comment, but I think the point is not that you use millions of rows but that you should be able to use all of your rows/data without having to use pagination as a workaround to hide the problem that the GUI is incapable to render too many rows at once.
Imagine having such a terrible UX while editing a large source code files, the editor loads only 20 lines then you need to click a button or scroll down to load the next 20 lines, search would also be slow since it would do a request to the backed.
Sorry again if I missunderstood your comment, its not super clear to me what was your point.