Live data from Hacker News

UI considerations for designing large data tables

coyleandrew.medium.com

11–20 of 30 posts

Re: UI considerations for designing large data tables

#11

this 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

Maybe it’s people like me who fled Reddit. I’m sorry!

Re: UI considerations for designing large data tables

#12
post #11

Earlier quoted context omitted.

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

Maybe it’s people like me who fled Reddit. I’m sorry!

If you're serious, read the Guidelines (link at bottom of the page) for submissions. HN is for intellectual curiousity - table formatting basics don't qualify, IMHO, but I speak only for me.

Re: UI considerations for designing large data tables

#13
post #4

ag-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.

I don't really know how to interpret this comment. 3.2M rows are not loading into the browser at once, only about 10k. The page size is configurable. The frontend and backend have a contract to agree on how this works, so as the user scrolls (and frontend needs another page) it asks the backend for more. The frontend will keep up to N pages (also configurable) cached in the client. Works shockingly well without any fuss at all. The AG-Grid team really did a great job here (it is not free for this particular feature, but well worth the cost)

Re: UI considerations for designing large data tables

#14
post #4

Earlier quoted context omitted.

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.

I don't really know how to interpret this comment. 3.2M rows are not loading into the browser at once, only about 10k. The page size is configurable. The frontend and backend have a contract to agree on how this works, so as the user scrolls (and frontend needs another page) it asks the backend for more. The frontend will keep up to N pages (also configurable) cached in the client. Works shockingly well without any f…

Apologies, it was not the technical side of it that had me musing on it. I was genuinely curious why and how I would "scroll" through that much data in a meaningful way.

And I don't mean this as a heavy criticism of the idea. I'm assuming it is useful to you. Always fun to hear about how this sort of thing is used.

Re: UI considerations for designing large data tables

#15
post #4

Earlier quoted context omitted.

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 but…

Apologies, that was not what I meant. I meant it more directly in assuming the technical side works and you are able to scroll just fine, how do you meaningfully do so with that much data?

And I don't mean this as an attack. I presume there are some techniques that I just don't know. Or data sets I just don't typically interact with.

For the ones I am used to, aggregates are key to working with them. That and graphical visualizations. (Though, it is frustrating how many visualizations can be reduced quickly to "top N" or similar.)

Re: UI considerations for designing large data tables

#16

this article is so pedestrian I'm puzzled why it's featured so highly here.

Well you would be surprised. I had to explain to several people why it is important to align numbers to the right, and why ordering of the columns can't be done unless you understand how customer works.

I shared his original article with bunch of UX people and most of them had said they learned a lot from it.

Re: UI considerations for designing large data tables

#17
post #11

Earlier quoted context omitted.

Maybe it’s people like me who fled Reddit. I’m sorry!

If you're serious, read the Guidelines (link at bottom of the page) for submissions. HN is for intellectual curiousity - table formatting basics don't qualify, IMHO, but I speak only for me.

I found the link interesting, that is why I clicked on it and upvoted it. Perhaps some of us here are interested in good UX design, particularly for hard-to-get-right areas like dense data tables. What satisfies your intellectual curiosity may not be the same for someone else.

Ironically, everyone in this thread complaining about the submission not being appropriate for HN are violating the guidelines.

Re: UI considerations for designing large data tables

#18
post #15

Earlier quoted context omitted.

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 but…

Apologies, that was not what I meant. I meant it more directly in assuming the technical side works and you are able to scroll just fine, how do you meaningfully do so with that much data? And I don't mean this as an attack. I presume there are some techniques that I just don't know. Or data sets I just don't typically interact with. For the ones I am used to, aggregates are key to working with them. That and graphic…

It's something that's both a common B2B requirement because users keep asking for it ("I want to see all of my data at once"), and something functionally ~useless.

Re: UI considerations for designing large data tables

#19
post #17

Earlier quoted context omitted.

If you're serious, read the Guidelines (link at bottom of the page) for submissions. HN is for intellectual curiousity - table formatting basics don't qualify, IMHO, but I speak only for me.

I found the link interesting, that is why I clicked on it and upvoted it. Perhaps some of us here are interested in good UX design, particularly for hard-to-get-right areas like dense data tables. What satisfies your intellectual curiosity may not be the same for someone else. Ironically, everyone in this thread complaining about the submission not being appropriate for HN are violating the guidelines.

It's not that UX design is uninteresting, but that the OP was very basic and thus not creative, expert or insightful (IMHO).

> What satisfies your intellectual curiosity may not be the same for someone else.

I pretty clearly said the same in GP.

Post reply on HN