5 ms·
> put about 10k rows into the browser and let the user use ctrl+f to find what they're looking for" which is probably also wrong for all sorts of reasons. I a
by tryauuum 5y ago
> put about 10k rows into the browser and let the user use ctrl+f to find what
they're looking for" which is probably also wrong for all sorts of reasons.
I actually use a UI like that, and this particular one is not fun to use. You have to wait 2-3 seconds and experience unresponsive UI untill all the 10k rows are loaded
Having said that, I think this approach ("put about 10k rows into the browser") could still work, it just needs more love.
- listenallyall 5y agoNavigating to page 6 of a result set, for example, generally takes a bit longer than 2-3 seconds. Just getting to page 2 often takes longer.
- partomniscient 5y agoTotally agree with you and the author of the post. Part of the problem is the lack of filtering (or even sorting) on the client side to reduce the information overload to something you're willing to wade through, which would trade off results returned for query complexity (of course, this also assumes its been programmed correctly...). We lose a lot using the 'search box only' query interface that google popularised. If there is filtering, sometimes you can see how poor the integrity and/or quality of the data is due to some weird-ass categorisations, typing mistakes etc. etc. Attempting to limit searches on laptops to a specific screen resolution did my head in on pretty much all of the major manufacturers sites.
- Someone 5y agoBut if, most of the time, what’s on page 1 is all you need, paying the extra time every time so that things are faster in the rare case you need page 6 is a net loss, both in user waiting time and costs for the site (often a big one). Also, with smaller pages, site owners can track whether many users need page 2, 3, etc. and change page size or reload the next page’s data accordingly.