Quick jump to next/previous entry

[allen]

Title:
Quick jump to next/previous entry

Area:
reading page

Summary:
Add a javascript function to skip to the next or previous entry in your reading page. The function would be available either through a sticky element for desktop, or through a swipe gesture for mobile.

Description:
This is kind of like the Jump Links suggestion (which it looks like was accepted but lost in the bugzilla crash), but with a few differences.

The problem that it's supposed to solve is for when you end up with some long, uncut entries on your reading page (like from changelog or an RSS feed). And then you want to go to the next entry, but end up hitting page down a whole lot. Or worse, you're in mobile and you have to scroll down and keep scrolling and scrolling...

So the idea is to have a javascript function available to scroll to the next (or previous) entry in your page. This could be made available with a sticky module which would be available either in one of the sidebars or (if you don't have a sidebar) at the top of the main entry area. It would have just a 'Next' and 'Previous' button, which would take you to the next or previous entry in your reading list.

We could also include a jquery touch plugin that would add the same functionality with, say, a two-finger swipe up or down.

Edit 2017-04-24 I don't see much love for the sticky idea, but having a way to configure an optional shortcut has at least some support. So now I'm thinking a new tab in My Account Settings for Shortcuts, which would have options for

Enable keyboard shortcuts (checkbox, default unchecked)
Next (text field, default j)
Previous (text field, default k)
Enable touch shorcuts (checkbox, default unchecked)
Next (options for swipe/disabled, 1,2,or 3 fingers, and up/down/left/right)
Previous (options for swipe/disabled, 1,2,or 3 fingers, and up/down/left/right)

I could also add a way to make a link call the JS function so that anyone who wanted to use links instead of key bindings or touch gestures could just include those in their styles.

Poll #18201 Quick jump to next/previous entry

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
8 (25.0%)

Should be implemented with changes. (please comment)
4 (12.5%)

Shouldn't be implemented.
11 (34.4%)

(I have no opinion)
6 (18.8%)

(Other: please comment)
3 (9.4%)

Comments

[marahmarie]

I voted for both this suggestion and the parent you linked back to. The implementation using s2, as seen on exor674's journal, is fantastic; it does what it says on the tin - I'd just want text for "previous" and "next" on the buttons/links instead of the arrows they chose to use.

[kyrielle]

Oh, please, no. No swipe on mobile. I intensely dislike swipe features on mobile, because when I'm trying to scroll down, I often swipe over instead and end up loading someone I didn't want to. And then I hit back, and maybe it gets to the right place and maybe it doesn't. (My phone browser offers back/forward swipes already, too, so I'm not sure how this would interact with it. I wish I had a way to turn that off in the browser!)

[allen]

I'm hoping that making it a two-finger swipe will reduce false positives sufficiently. And it could be made optional to the style, so you wouldn't need to enable it on your pages.

[allen]

Since I put in this suggestion I went ahead and made a proof-of-concept implementation. From that I learned:

1) Having a JavaScript function for 'quick-scroll to the next/previous entry' is super-nice (but of course I think that)

2) The sticky-nav feature (having a div in one of the sidebars that stays at the top of the browser viewport when you you would otherwise scroll past it) is a fine way to make it so the links are always available, but can look a little bit bare-bones (and very bare-bones in some styles). I could imagine styles authors wanting to modify that so that there was some additional content that would be in the sticky navigation section--for instance, you could make it so when you scrolled past the end of your sidebar, then the sticky div could be the profile module plus the next/previous entry navigation module.

3) Because of 2), I'd probably suggest the module be disabled by default for most styles, so only users who active enabled it would get the sticky nav section.

4) Two-fingered swipe is awkward, at least for me, since I usually scroll with the thumb of the hand that's holding my phone. Still, it's better than a single-touch swipe, because it's super-annoying when you are just trying to scroll or click and your phone thinks you're swiping.

5) It would still be a good idea to also make the swipe functionality opt-in (probably by making it dependent on the sticky-nav module), if only because I don't trust mobile manufacturers not to mess things up. ("We made the only way to switch tabs a two-fingered swipe up and down! Oops, guess that doesn't work if you're in DW!")

[montuos]

As far as floating/sticky-nav features go, I'm very fond of the words "teeny" and "tiny", and "optional". I'm all for the ability to fix "Holy Christ if I'd had any idea how long this entry was I'd have skipped it for later!!1!", but not at the expense of screen real estate on anything but my desktop's ginormous monitor.

So having "previous" and "next" on buttons/links at the top and bottom of entries would be good, but for floating in the sidebar, I absolutely want nothing larger than those arrows exor674 used.

Being very awkward still with any kind of swiping, I'm in favor of having actual buttons, no matter how sticky/floaty, on my phone. But again: "teeny" and/or "tiny"!

[susanreads]

I'm in favour of the previous version of this that you linked to, but not this one. I haaaaaaate floating headers, which I think is what you're talking about. Something that takes up screen space after you've scrolled down the page? No thanks (and I'm on a laptop, not a mobile even). Until I read the comments I didn't understand; I thought "the navbar's at the top of the page, how does that help with scrolling past posts?"

I'd much rather have extra links in the entry footer (since I'm generally reading up the page, but down each entry), which wouldn't rely on Javascript.

[turlough]

Hear, hear!!

[msilverstar]

I love the laptop option of j/k that Tumblr and some other systems have, but don't know how to do a similar thing on small devices.

[allen]

I'm not on Tumblr so I haven't seen that before. But yes, that's pretty much exactly the functionality that I'm after here.

If this suggestion gets voted down I might try again with the j/k keyboard shortcuts.

[denise]

As long as it's something people can disable (or not enable in the first place), like a S2 module or whatever, it may make it over to Github even if it gets a lot of No votes, unless somebody gives me a really good reason why not...

[matgb]

I found the original post to be slightly confusing but the comments have clarified the plan, and I think I like it but it'd need careful consideration: I also, for example, loath floating headers that aren't helping me, but this floating could help me if done right.

As a specific example, have you tried the Opera Mobile browser? if you fast scroll on that it will display an arrow in the scroll direction as a transparent overlay in thumb position, press it and you go direct to the top or bottom depending on scroll direction: incredibly helpful in many cases but not exactly what we'd want.

Aside: in Gmail j/k are next/previous email and [/] are next/previous+archive, very useful functions and those keyboard uses are great.

We're basically looking for a trigger to have the screen scroll to the next anchor of a given type, which given the very well marked up styles DW uses is fairly easy to establish/amend: I think it'd be better to have it stylable, I personally would prefer it on the right of my screen as floating up/down arrows for example but I'd imagine that would really annoy others.

[jducoeur]

I like this specifically for the mobile swipe, which I think it really logical and likely to be usable. But strongly agreed that it *must* be opt-in...

[melannen]

As long as it's an optional part of the style system, I don't care. But please make it very opt-in if implemented.

[shy_magpie]

I think this was implemented? You can currently do this under account settings under short cuts. It even lets you pick the key or gesture you use to a certain extent.

[allen]

Yes. I just added the bugzilla: implemented tag to reflect that. It went out..early last year? Something like that.