Skip to content
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

Closed

Conversation

CarwynNelson
Copy link
Contributor

@CarwynNelson CarwynNelson commented Oct 21, 2023

I realise that I have not co-ordinated this work in the Discord or the GitHub issues. This was a bit of an in-the-moment frustration fix that I had not planned to work on, so apologies for the drive-by contribution.

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:

  • User hits / (opening small web for the first time)
  • The index handler detects that there is no url parameter, and therefore no video to play
  • User is redirected to /next
  • The next_item handler picks a random piece of content using the same logic as before
  • The user is redirected to ?url=$url with a HTTP 307 response code (this seems like the correct one based on a quick check on Wikipedia?)
  • The index handler pulls the content based on the url parameter

Notes

  1. This logic should still works for Youtube videos (that is what I use SmallWeb for the most personally)
  2. I have removed the 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.

@vprelovac
Copy link
Contributor

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.

@vprelovac
Copy link
Contributor

Rather it feels it would be more 'in character' if we could disable the next post for 2 seconds before the next one.

@CarwynNelson
Copy link
Contributor Author

I like how the current website forces us to be more mindful and not just frantically click the next post button

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.

Rather it feels it would be more 'in character' if we could disable the next post for 2 seconds before the next one.

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.

@vprelovac
Copy link
Contributor

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.

.stumble-link button {
    pointer-events: none;
    opacity: 0.5;
}

@keyframes enableButton {
    to {
      pointer-events: auto;
      opacity: 1;
    }
  }

.stumble-link button {
    animation: enableButton 0s forwards 5s;
}

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.
@CarwynNelson
Copy link
Contributor Author

@vprelovac I have raised #122 to implement the JS disable for the "Next Post" button

@CarwynNelson
Copy link
Contributor Author

@vprelovac Now that disabling the "Next Post" button for a period of time has been solved how do you feel about this patch?

@vprelovac
Copy link
Contributor

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.

@vprelovac vprelovac closed this Nov 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants