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.

[matgb]

So currently your reminder that there's new stuff at skip=0 is that you've had duplicate content? That makes sense but it'd be a very quick habit to get into to just go back to the top afterwards (I do it on Dabr constantly).

However, I think there was a suggestion recently to give a notification for new content, perhaps if that's approved it could be in some way combined?

Regardless, you'd still see the missed entry, next time you check your page, surely?

(I am expecting a billion different "but I do it this way" responses to this one, the vast diversity of the ways we can all use the exact same interface always astounds me, normally in a good way, and it definitely makes me appreciate a good UI design a lot more)

[ratcreature]

I don't tend to run into this on my regular reading list, because I display 30 posts, and it happens very rarely that it's been so long between my visits that more than 30 new posts have come up, so I never use that skip link there. I mostly run into this when I go back through a community or tag I do not read normally to read old entries, and usually only one new thing is posted. I might not visit again.

[matgb]

Ahh, I see. Yes, that is a different use case-I'm thinking specifically of Reading page as opposed to journal pages, but it could be used there or not-I honestly don't care about that too much.

[ratcreature]

Well, as long as it would only affect my own reading page skip (and maybe the network page) but not the regular page skips elsewhere I wouldn't mind.

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

[ciaan]

That is also how I read. Or, maybe slightly different, I open each skip= in a new tab. Then, because I am paranoid, after reading (or generally, opening in yet more tabs) each entry I am interested in, I refresh the skip= before I close that tab.

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

[deborah]

Yes, this.

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

[elf]

Yes, this; for my own readlist, I can get caught up, one way or another, and I don't mind the occasional one or two repeated messages--but getting an almost-full page of repeats on the network skip pages makes it too frustrating to bother with. I tend to read the first screen only.

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

[msilverstar]

+1

[erika]

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

[matgb]

If you go to reading page and read top to bottom, you can then skip back to read older entries. Currently, if someone has posted since you loaded your page, the next entry at the top of the 'older entries' page will be something you've read, it may be a lot of things you've read if your reading list got busy.

Proposal is to change it so that instead of just loading current entries 21-40 when you skip back, which may include stuff you've seen, you instead read the next older entry at the point you loaded your first reading page.

If your reading page is quiet you may not notice this effect much, but if it's very busy you can sometimes hit the 'back 20' link and get a whole page of stuff you've already read.

[erika]

Thank you!

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

[jeshyr]

It has accessibility implications in terms of people's ability to skim or skip to find where they were up to, and with reading speed and memory issues, but it's not primarily an accessibility thing I'd say.

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

[matgb]

You do understand the suggestion, but, um, I don't know what you mean in your amendment? Do you mean have a link along the lines of 'reload reading page with this entry at top' after every entry or something?

I suspect if what I propose is doable this would be two, at least it could be hacked in S2, but the level of code needed to rejig the Reading page on its own is completely beyond me.

[existence]

Yes, that is what I was trying to get at! Wow, that sounded more coherent in my head, sorry.

The code is pretty much beyond me, as well, but it feels like the easiest compromise between how I use the page and what I want out of the page, but I can see where it would be simpler to explain and implement one thing over the other. Maybe it would be incentive to see how far I can get hacking together something, who knows.

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

[kyrielle]

How would they post an entry that would've sat in the gap? Reading pages are ordered by system time of posting - backdated entries, I thought, are omitted. In theory they should only appear at the top, I'd think?

If I'm wrong, then I agree with this modification.

As far as eternally-scrolling...please no. Sometimes I am so glad to go back one page and get that one entry that broke my display off the screen! And others I just flat don't want to blow my computer up by having that much all loaded at once.

[andrewducker]

Entries are posted with the timestamp that they are sent with. The "backdate" functionality is only needed if you're posting it before an existing entry.

So if I open my LJ client, it notes the time, and I start typing, if it doesn't update the time again before I post it will post at the time I opened it, not at the time I hit "post".

[matgb]

It's my understanding that the order displayed in your journal is determined by display time, but the order displayed on the reading page is determined by system time. I'll check this later.

Regardless, your initial objection, while valid, wouldn't be a change from current behaviour as new posts that slip in between existing posts are going to be missed by most people (say I read entries 1-20, while I do this someone posts in a way that would appear at entry 10, when I click back, I'll currently read entries 20-39, if I go back to the top later, I'll read down and stop at what was entry 1-it's that that leads me to think Reading goes of server time anyway, and if it doesn't I think it should)

[kyrielle]

+1(000)

[matgb]

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,

Oh gods no. I'd hate that, and loath it on other sites as well, not just because some sites manage memory terribly and end up hogging all the RAM, but also because it just breaks the way I like to use sites (one of the reasons I prefer Dabr for Twitter is because it explicitly doesn't do this).

However, if that were to be coded it would need a very similar 'next X' setup, so it could be done if someone wanted to code it-that would then justify options as I'd loath it witha passion so people would need to choose, if they're chosing how their reading page skips, a choice between three would be acceptable.

[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!