-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix browser back and forward buttons #120
Fix browser back and forward buttons #120
Conversation
I am torn on this one. A part of the beauty of the small web is it also being the 'slow' web. I like how the current website forces us to be more mindful and not just frantically click the next post button, but spending some time on the content first. Inability to go 'back' is a part of that. So will give this more thought. |
Rather it feels it would be more 'in character' if we could disable the next post for 2 seconds before the next one. |
I had not thought about it that way, but I see where you are coming from. For me the mindfulness comes in removing myself from "The Algorithm" and going back to just being served random content, which feels more like the "old web" to me.
This feels like a nice compromise to me, but I would go a bit further and say that it should be between 5 and 10 seconds. For me it takes about 2-3 seconds to notice that I am not interested in the content, so a 2 second delay wouldn't really change my behaviour and slow me down a little. The only concern I would have with implementing a delay like this is that, as far as I can tell, it would have to be done in JS. This feels fairly core to the experience, so I just want to check that you are okay with that. |
Yes 5 seconds may work. I came up with this code which 'disables' the button in CSS but it is just visual, user can still click on it. Try to add js based disable too and try it locally to see how it feels, and if it is OK you cna submit a new PR. I would keep this one around.
|
This commit introduces a "/next" endpoint which the "Next button" has been updated to use. When the browser hits the /next endpoint it is redirected to "?url=$url" with an HTTP 307 response code. This allows the posts a user has visited to be stored in the browser history making the back and forward buttons work. I implemented this because I often accidentily skip past a piece of content that I am interested in and am unable to find it again without spamming the next button until I happen upon the content.
My editor picks up that these imports are unused, so we may as well remove them.
@vprelovac I have raised #122 to implement the JS disable for the "Next Post" button |
a9b26ee
to
4b8cea4
Compare
@vprelovac Now that disabling the "Next Post" button for a period of time has been solved how do you feel about this patch? |
I feel there is less need for it as the user is less likely to accidently go to the next post. Lets give it some time. |
Update: I noticed that there is a feedback item about this at https://kagifeedback.org/d/2176-browsing-history-is-lost-on-new-post-and-refresh
Background
I often find myself accidentily skipping past a piece of content that I am interested in and am unable to find it again without spamming the "Next Post" button until the RNG blesses me with the same content again. What I would really like is if the back/forward buttons in my browser allowed me to go back to content that I missed, or want to read again.
Implementation
In keeping with the spirit of allowing core functionality to work without any JavaScript, I have implemented this entirely server-side using HTTP redirects. The logic in the PR is as follows:
/
(opening small web for the first time)url
parameter, and therefore no video to play/next
next_item
handler picks a random piece of content using the same logic as before?url=$url
with a HTTP307
response code (this seems like the correct one based on a quick check on Wikipedia?)url
parameterNotes
prefix
variable from the "Next Post" button, but I assume it needs to be put back. I'm not sure what the potential values are, and so I wanted to seek code review before adding it back.