I am in a long topic, pressing j j j jj to read, until i reach post 41 (i can see that in the address bar).
Now i scroll down some more with mouse scroll wheel, until i reach post 49 (i can see that in the address bar), without clicking anything.
Now i go back to pressing j jjj .
Issue: At this point my scroll position is broken, as pressing j jumps to post 42 instead of 50, as i expected.
Can you reproduce here on meta?
I can repro it here, and on our site.
J from 310-314, scroll down to 322, press J and moved back to 315.
I thought that was the expectation. As the use of j and k indicates the selection of a post. So naturally since a post is selected one would expect the next selection to be the very next post not some random post that is now in your viewport.
There is a slight inconsistency though. If you scroll long enough (maybe until additional posts have to be loaded?), then pressing j will select the first visible post, instead of the post after the previous selection.
Well, that’s because you’ve unloaded the prior selection, so it has nothing to compare to at that point. So I can see why it might do that.
I do get what you are saying though, but with this being a power/accessibility feature I’m not sure that is a big deal. Most people who use j/k to navigate aren’t switching between mouse and keyboard frequently.
I’m pretty sure that this is how Microsoft Word works (it’s a popular word processor). Scroll with the mouse and go one place but then hit the down arrow (the program has no proper cursor movement keys) and you’re back where you stopped scrolling with the keyboard. I don’t use it enough to know for sure, though.
It’s maddening there, but I think it mount be what I’d expect here. And if you know that’s how it works, being able to scroll without losing your place is pretty great.
Sure, but in Word the caret determines the insertion point. If you open a Word document read-only there’s no caret and the keyboard does nothing. It stands to reason that when the caret is present you are able to alter the document, and would never want to effect a change that you can’t see.
Discourse OTOH has two concepts of focus which only track progress through a topic. The reply denoted in the URL, which increments as a user scrolls, and the post selected by the J/K keyboard shortcuts.
The question is whether they should behave as one, or maintain separate states.
But in Discourse, when you have a post selected you can interact with it… L will like it, E will edit it (if you have sufficient permission), etc.
I guess one could argue once it is out of viewport, that the selection should be removed. As interacting with something you can’t see is obviously harmful. That in turn would then permit the notion of scrolling via mouse would trigger a new selection to be made based on what you can see using J or K.
Sure, but to make a change you still then have to add or remove characters and save the change.
My point was more that keyboard navigation in Word isn’t an analog to Discourse, which you’ve effectively reinforced with the above.
Is there any harm in making the selection match the reply indicated in the URL? If anything it would make scrolling slightly more interactive and the behavior when you do swap back to keyboard a great deal more predictable.
I’d approach it as “remove selection” when selected post is out of the viewport. No one would expect to be able to delete/like/flag/share a post they can’t see anymore that isn’t far enough out of the viewport to be unloaded. That in turn then enables the behavior you are seeking since nothing is selected anymore, default behavior would kick in and select a post inside your viewport.
Not entirely, from an accessibility perspective the current arrangement isn’t perfect.
If a user scrolls between posts the reply-specific keyboard shortcuts don’t work at all. Joining the reply focus in URL and post selection focus would allow one hand to scroll, while the other triggers post actions.
If a user simply scrolls and only scrolls they can’t interact with posts at all no matter where they stop scrolling… (today)
Let me maybe give another explanation of how i came to this issue.
In extremely long posts i can press j to scroll (instead of mouse) because of Smooth J/K navigation when using keyboard. <- But that feature is half broken for me since i only read about 3/4 of the screen bejore pressing j, so that makes me lose some text (the 1/4 at the bottom of the screen has 2, 3 rows hidden).
Secondly, it really doesn’t work properly when i use 175% zoom on my 12 inch 2 in 1 laptop, especially if i pinch-to-zoom (note that i’m using chrome here. firefox’s touch implementation is unusable).
My third pet-peve is that when i am almost at the bottom of the post (the part with like, reply, etc buttons), j jumps too soon to the next post (eg, i would like it to show me the bottom of the post just under half of the screen, so i can see clearly that the post is finished).
Because of all these, whenever i have a long post, i still use my mouse/touchpad instead of pressing j to read. After than, i keep on using my touchpad for a little while until i remember than pressing j is easier.
Problem is that if i dont specifically click the current post onscreen, the first time i press j everything is broken as i see some post i have already read previously.
Basically you may say i have 2 different problems: the first one is with smooth navigation which jumps too soon to the next “portion” (be it of the post, or next post) and the second is that current post selection is not in sync with the address bar.
Down arrow and space bar are good alternatives to using the mouse. However, I think if the de-selection of a post happens when it is out of the viewport, that is still a good solution. As the next time you press J or K, it will pick a post that is visible to you.
As long as J/K picks the topmost post in view (even if it has only 10% onscreen) i think it would make a better usage experience.
This topic was automatically closed after 3 days. New replies are no longer allowed.