Implement Chrome/Firefox animation for page back

I might chime in as a voice of dissent here. Clearly many people would prefer this interaction but one of the main things I value in Orion is "it's Safari but better", adhering very closely to Apple's HIG & macOS conventions. Chrome & Firefox (and their ilk) seem to have made the deliberate choice not to try and appear native within macOS and these navigation gestures are just one of the many places that shows up.

For those who don't like the native gesture because of the perceived slowness, the ⌘[ and ⌘] keyboard shortcuts or long/right-clicking on the next/back arrows seem like much better ways to accomplish e.g. quickly moving back 5 pages as one of the examples in this thread has than using gestures, without impacting the most common case of going back/forward a single page.

I hate suggesting "just add another option" but I would hope should this change get implemented those of us that prefer Orion's native behaviour have a way to preserve that. I also value that it makes it very clear you're performing what can be a destructive action by having the whole page move rather than a comparatively small arrow peeking out from the side (in some of the mockups proposed here it's less than 1% of the window area which seems very easy to miss), and allows you to quickly peek to refer back to content on the previous/next page without losing the current page.

adamaveray Thanks for chiming in. We definetely do not want to make it another option as each new option makes codebase big and hard to maintain, and the goal of Orion is not to please users of other browsers, but to offer the best browser experience on Mac. I can see arguments from both sides as firefox/chrome solution is faster, while safari solution is native.

So I urge community to land on a consensus. But an option it should not be.

An important detail that no one in the discussion seems to have noticed: You can turn on animation-less swiping in Safari!

On macOS Ventura, go to "System Settings" -> "Trackpad" -> "More Gestures“ and set "Swipe between pages" to "Swipe with Three Fingers". Then, when you swipe with three fingers, Safari does not show an animation on swiping.

Thus, it seems to me that WebKit cannot be the culprit here. Also, I'd say, animation-less swiping does not really go against a particular Mac aesthetic when it is built into Macs already.

gds

oh interesting, it works quite well in safari, only thing that is annoying tho is that its 3 fingers.

when activated Orion back and forward gestures don't work at all with any amount of fingers

It seems this issue is pitting two Orion design principles against each other. Speed and Native. The native behavior (sliding animation) is not fast. And even if does is or could be made to take the same amount of time, the visual jarring causes delay in perceiving the new page.

I am firmly in the speed camp (no animation or small animation)

Navigating between pages can feel quicker if one can turn of the animation of swiping back to the previous page. (Like Chrome is only showing an arrow to indicate that you will navigate to the previous page)

A simple toggle in the settings pane will do ("Disable swipe back animation").

Yes yes yes! Can't stand the swipe back animation in Webkit on desktop.

Please add a way to disable certain animations such as the entire page swipe that happens when you go back a back. It can be very disorientating.

I agree with this, although I would actually support removing it altogether. I thought this was poorly thought out when it was added to Safari. Firefox and Chrome wisely declined to add it to their interfaces.

1. It makes single-page applications that use pushState() behave in unexpected ways.
2. It adds nothing and is just visual flair. Any context of "you are going back" can be added in other ways (see Chrome or Firefox for examples)
3. There is no consistency with any other aspect of the UI behavior:
   1. The page didn't swipe over to "cover" the existing page when the user clicked a link to go to a new page. Why does it swipe backwards to "uncover" the previous page? UINavigationController on iOS swipes back, but it also slides the new view on top of the old view when navigating forward. This "stack" consistency makes sense, while the behavior in Safari and Orion does not.
   2. The back button does not slide but navigates instantly. So there are 2 different behaviors depending on how the user navigates. Again, iOS is consistent with the back button.
4. The animation must complete before the page can be interacted with. This slows down browsing.
5. Users with accessibility issues requiring "Reduce motion" to be enabled in accessibility prefs still must watch the entire page slide away when they navigate back using the trackpad. This can cause issues for those users requiring them to work around it (retrain behavior, remap swipe with BetterTouchTool, etc.)

In summary, I don't think it adds anything useful to the UI while causing issues with both applications and users with accessibility needs.

cloudbread Can you show a video of what effect are you talking about? By the sound of it it sound like something built into webkit.

Vlad

I agree with the feedback of removing it entirely or using an alternative feedback mechanism. It adds complexity and some odd behaviors. On rare occasions I've noted that it won't actually navigate back but reload the page. The UX really only makes sense on mobile and I'm convinced it was some bureaocratic decision in the name of consistency.

My work around to this is to use the CMD-[ keybinding which just does the back navigation. Though having used Chrome for years is hard to break the muscle memory of swiping left.