Hacker News Reader

Comment by dusted | Hacker News Reader

As a non-designer developer, I'm going to say this is dictated by UX designers and has no technical merit. My preference trends towards "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.

Only thing worse than pagination is infinite scrolling.

View on HN

Bonus points for infinite scrolling where results that aren't on screen are removed from the DOM, making ctrl-f entirely useless. Looking at you, Twitter.

At least they're saving on memory, to be fair.

Twitter hates their website. And it shows.

Is there a good way to handle this without all the overhead of the full DOM object for each invisible thing? Some way to keep searchability from the native client while changing the amount of data stored in memory?

No, you'd need to handle the search. Which is something I see more and more sites doing.

I don't personally think there is a good way to handle this. The best compromise is that this type of infinite scrolling only comes along with a fleshed out, well working and prominent search and filter feature.

In the case of Twitter, ctrl-f would allow me to search through my bookmarks, my feed or the replies of the tweet I am looking at. Can the Twitter search do these things? If it can, it's really not obvious, and if not, that sucks because a lot of usability is going out the window with no replacement.

drives me mad too, but for infinite scrolling you do basically need to do this if you don't want your site to be a lag fest/memory hog on older hardware. of course twitter runs like shit on older hardware anyway

Extra bonus points for contacts page (including careers) only reachable through the bottom of the page, which is continuously pushed forther bottom by infinite scrolling.

Pages are very useful when you don't want to dark pattern users (see: social media).

We could make very, very long scrolls of text in real life, but books are more practical.

Similar thing here, not everyone uses "Ctrl-F". Heck, many users don't know how to search (try to ask non technical people, you'd be surprised) and on mobile browsers for example, frequently there's no way to search (or no easy/easily discoverable way to search).

If you already know your search term, an actual search feature would be more useful. Scrolling and pages are for browsing where you need to see each item to make a choice.

Infinite scrolling is crap, but 10K rows in a result is going to feel a lot like infinite scroll.

Sometimes you want to see all results and then ctrl + f multiple search terms. You wouldn't want to reload page as you try different keywords. Sometimes I don't even know search terms until I have scanned through a few rows.

In our non-web app we do this. We have "special" grids for this which wraps our query as a subquery, does a count() so it can accurately draw the scrollbar, then uses limits to pull only the visible rows from the database.

When the user add filters on columns or sets sort order it's added in the where or order by clause respectively of the outer query.

This way we can easily show 100k+ rows (like, all their invoices or orders), the user can scroll and filter to their delight etc, all super-responsive.

Surely it shouldn't be much harder to support on the web if one wanted?

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

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

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

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

The other thing worse than pagination is broken pagination.

The initial query of all rows might be slow, but once I have a snapshot speed is not the issue. I regularly do ctrl+a ctrl+c alt+tab to Excel and ctrl+j to run a program that gives me the result I am looking for.

Where I have control over the back-end, I like to provide static dated snapshots of queries.

I can be stingy but I would look at: Time to run the query vs. Value of having all the data.

Maybe we can also discuss application that don’t involve very large numbers of elements.

100-1000 elements for example could be accommodated on the same page. 10k make me think about data grids which may be improved by filtering on multiple columns for example.

Server admin's gonna need an additional fire extinguisher for that.

EDIT: Guess you guys have no humor on this page

Reply on news.ycombinator.com