On the contrary, pagination makes it impossible to keep your place in the list if it changes between page loads.

▲ nkrisc 4 hours ago | parent | next [-]

How are you going to keep your place if the order changes anyway? What is your place if the order has changed?

If the order changes, all bets are off regardless of pagination or infinite scroll.

▲ afandian 6 hours ago | parent | prev | next [-]

The challenge is to retain an ordering over the result set. How would infinite scroll behave any differently in this case? The changing results seems to be an orthogonal concern to pagination/infinite scroll.

▲

xigoi 6 hours ago | parent [-]

Infinite scroll makes the problem much easier, even if it’s still a problem. The only action you need to support is loading more results, which you can do by loading all results and filtering out those already shown. With pagination, the user may say “give me page 3” and you have no idea what was on pages 1 and 2, if they were even loaded.

▲

hdgvhicv 4 hours ago | parent | next [-]

If page 1 and 2 were 10 each you load results 21-30

Same as if you are scrolling and have reached result 20 And want to load more.

▲

falcor84 4 hours ago | parent [-]

But the underlying table changed since. I'm not very familiar with these myself, but it seams to me that the best solution is to keep a session cursor for the user, and these are a lot simpler when you only ever move it forward.

	▲	Dylan16807 3 hours ago \| parent \| next [-]
		It's slightly different but I don't see why there should be a notable difference in difficulty. You need to somehow represent what you saw so far and act based on that.
	▲	Terr_ 2 hours ago \| parent \| prev [-]
		IMO "pages of search results" is one of the problems where the closer you look, the more potential problems and inconsistencies you see until you realize it's a leaky abstraction, and sometimes it gets too leaky. We want visitors to imagine that we just plopped a binder of sorted results down in front of them for their page-by-page perusal, but the suggests permanence and invariants we don't want to provide (because it's harder.) For example, the assurance that page 2 will always have the same items on it unless they "search again", and the last item on page 2 will not not duplicate itself on the top of page 3 as they page forward. By way of contrast, imagine a system where a result-set was not just a UI metaphor, but real domain concept. Do a search, and you get a Result which is a limited-size listing generated at time X for user Y and will be cached for Z.

▲

svachalek 2 hours ago | parent | prev | next [-]

You can implement pagination exactly the same way. It's a UX decision that has nothing to do with underlying queries, although it typically maps.

The typical infinite scroll that I've seen implemented does not work the way you describe though, it's just pagination without controls. The reason it works is because it's pushing content you never asked for anyway and it just keeps pushing. Without any sense of pages you'll never know the difference.

▲

malfist 3 hours ago | parent | prev [-]

I mean sure, if you do it that way. But its easy to encode the page starting index and pagenate from there. Its even exactly the same algorithm as infinite scroll.

▲ bigbuppo 3 hours ago | parent | prev | next [-]

Ah yes, let me just look at Instagram for the ideal model of infinite scroll UX. You can't even scroll up to something you've actually subscribed to that you didn't mean to scroll past without it tossing it into the memory hole and replacing it with something you don't care about.

▲ vitally3643 3 hours ago | parent | prev | next [-]

Did you think HN has an unusable and bad interface? It seems to be a remarkably popular website despite having hard pages that change order on every refresh.

▲ cwillu 6 hours ago | parent | prev | next [-]

‹looks at hn›

▲ thaumasiotes 2 hours ago | parent | prev | next [-]

> On the contrary, pagination makes it impossible to keep your place in the list if it changes between page loads.

Well, that's obviously false. There are two styles of pagination:

    https://yourblog.zox/archives?page=4

    https://yourblog.zox/archives?before=2019-06-03&count=10

That second style will never change (unless you insert entries into the past). The first style will change. But it hardly makes it impossible to keep your place in the list; if you come back three years later, you'll find that that link goes to a random location, but if you come back next week, that link is going to go to a place that is very close to the place you left off, requiring minimal adjustment to find your place again.

▲ im3w1l 6 hours ago | parent | prev [-]

Why is the list constantly changing anyway?

▲

xigoi 6 hours ago | parent [-]

Because other people keep adding new posts (and upvoting existing posts, which changes their order).

▲

im3w1l 6 hours ago | parent [-]

While that's true I think that once the feed has been observed in a certain way the advantages of stability outweigh the advantages of showing a tweaked version the second time it is loaded.

▲

xigoi 5 hours ago | parent [-]

The user expectation is that if you refresh the page, you will see fresh content.

▲

8note 3 hours ago | parent | next [-]

mine isnt?

if i refresh the page it should be almost the same. maybe a couple new things at the very top, but i should still be able to find the thing i was just looking at.

by comparison, facebook auto-reloads while you're halfway down a page, and wont show you any of the same things. its an incredibly poor experience

	▲	drdexebtjl 40 minutes ago \| parent [-]
		Yeah, this is terrible UX that we somehow normalized. At the very least we should be able to scroll backwards after a page refresh to see previous posts.

▲

alpinisme 4 hours ago | parent | prev [-]

Not if you’re on page 2