Make skip 20 actually skip 20

[matgb]

Title:
Make skip 20 actually skip 20

Area:
Reading page

Summary:
Wouldn't it be nice if when you clicked the 'back 20 entries' link on your reading page that's actually what it did?

Description:
When reading entries on DW, if you skip back at the end of a page, if new entries have been made then the next page you load will have some entries you've already read. This is made worse if you sub a high-traffic comm, especially one with a moderator queue (*cough*DW_Suggestions*cough*).

If enough entries have been posted while you've been reading, it's possible the top entries on your new page are new to you, then it goes to entries you've read-some people may even stop then assuming they've skipped back, etc.

It's my understanding that when the reading page is loaded, it will load however many it's been set to by user preference, but will "know" what the next entry will be at time of load.

How about making the 'skip back X entries' link at the top/bottom of the page link not to ?skip=20 but instead, say, ?start_id=XXXX where XXX is the item id of the 21st entry on the reading page (ie the next one not loaded).

This way you can backread a lot quicker, reduce server load of duplicate entries, reduce bandwidth for those of us on a mobile connection, etc.

I can imagine that some people like the current style, so it may be necessary to make an option as to how it should work, but if the number who like this current setup is small option creep should be avoided?

Regardless, I got this idea directly from my web-based Twitter client which runs as a much better web interface for my preferences (ie it works like DW/LJ reading pages with no dynamic memory hogging scripts getting in the way), http://dabr.co.uk Log in there with a Twitter ID and you can see how it works,

Poll #7886 Make skip 20 actually skip 20

Open to: Registered Users, detailed results viewable to: All, participants: 74

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
33 (44.6%)

Should be implemented with changes. (please comment)
3 (4.1%)

Shouldn't be implemented.
23 (31.1%)

(I have no opinion)
13 (17.6%)

(Other: please comment)
2 (2.7%)

Comments

[ratcreature]

I agree that it is inconvenient to see some posts twice when going back in a changing page, but if the page behaved like you said, I'd overlook the new entries, because I wouldn't have a way to notice their existence. I'd read backwards and then go away, not knowing that new have been posted while I was reading. I would need to remember to check the first page again to make sure nothing new was posted.

[susanreads]

My problem with skip= is that I go back till I find the overlap and then read forward, so I have to keep all the pages in separate tabs in case new stuff on top causes there to be a gap between, say, skip=40 a while ago and skip=20 now. I think this would fix that, so yes please. (Then I just need to remember to refresh the page once I've caught up.)

[montuos]

I see the problem and have been annoyed by it myself, but I definitely would not want this to be a default behaviour without the existence of new post notifications, since I too use the creep as an alert that I should not walk away without waiting for the reload to finish when I return to the top.

[eruthros]

I'd especially like this for the network page, because I often have enough posting on my network that I can't get to earlier posts - by the time I've even just skimmed the posts on one page, skip=20 takes me back to fifteen of the same posts and just five new ones. It's one of the things that keeps me from browsing my network view more.

[axiom_of_stripe]

I'd like this, but only after the (purposeful) notification of new posts is available because I am also one of those people who uses the skip-overlap as a notification workaround.

[erika]

I'm confused as to what this idea means. Could someone explain it to me in small words?

[ursamajor]

Hmmm. I could see this being useful for mobile viewing or other slow connections, though maybe a bit less so when you're actually viewing your read page with a low-bandwidth version designed specifically *for* mobile. I could also see this being an accessibility issue? On the other hand, I'm so used to the current behavior, and I don't do a lot of mobile DW, so it's not bugging me right now. (Plus I filter noisier communities off into their own reading filters.) On the other other hand, I could also see this as "too many options spoil the broth."

The point people are making about network pages above is valid, though I find it somewhat mitigated when I browse my network by ?show=P, ?show=C, etc. But I think overall, I feel mongoosey about the suggestion.

[existence]

If I understand this suggestion correctly, this suggestion would replace the skip feature with this nifty new thing of skipping back a precise number of entries? Which does sound cool, but honestly I would enjoy it more if it was an option after every entry on the reading list/network list, so that the current default behavior was my user default, but I could use the nifty skiping feature if my list was particularly overwhelming. But since that's a bit of a have your cake and eat it too situation, associate with the problems of adding more potentially confusing links, etc, I'm not really sure that idea is quite as feasible? Eh.

[zing_och]

Yes please! Like eruthros I'd love this for my network page; I mostly read it in "personal journals only" mode because otherwise it's really difficult to handle.

[andrewducker]

If you're looking at entry 1-X, and when loaded it makes a note that entry X+1 is the next one, then starting the next page at X+1 might end up skipping an entry, if someone posts an entry that would have sat in that gap.

You'd be better off asking for pages >X instead, that way this corner-case can't occur (it's unlikely, but it _will_ happen).

Personally, I'd rather that we produced an eternally-scrolling page instead, where getting to the bottom and clicking "more" loaded the next set of entries, removed any duplicates, and appended them.

[turlough]

I wouldn't want this at all. It would completely break the way I interact with my reading page(s - since I use a gazillion of subscription filters).

[kyrielle]

Oh god PLEASE.

Please please YES please.

I read my reading page just as you describe, going back, and I often have to go a ways down before I'm sure whether "I've seen that!" to the top one means I'm caught up, or means it scrolled. And I don't even sub high-volume communities, but I do have a toddler and get distracted.

Also? My iPhone often refreshes pages when entering/leaving the browser, and can only have 8 open at once. This would let me actually READ my reading page on my iPhone, knowing that (after the first 20, anyway) if I went back it would pick up the "real" next 20 and any refresh would end up with the same result (because it'd have a start id, not a skip=whatever).

Oh please YES. I only wish I could vote for "should be implemented as is, and forced into the LJ codebase"....

[aedifica]

I do not want this suggestion to be implemented *unless* "Make the reading page's window title change when new entries has been posted" is implemented.

(My reason is something matgb put well in a comment above: seeing duplicate content when I skip back is my notification that something new has been posted.)

[jeshyr]

Having just switched from reading via RSS reader to reading via reading page I want to say OMG YES a lot to this suggestion.

The thing that bugs me most about having switched is that I have to make myself read all the older-but-unread entries before I flip back to read the newest unread things because otherwise I'll get hellaciously confused about where I'm up to. I liked being able to flip around so much in my RSS reader and this wouldn't totally fix that issue but it'd certainly help!