I have an iPad. There seem to be two kinds of toggle switches in the native apple apps; one of them slides and animates, but the other one can only be pressed and it doesn't animate the transition. The latter is less common, but I've seen both in the same app before (settings I think).
It's likely a strange bug, but I think it's relevant since you can't _always_ slide it.
UISwitches can be dragged by design. Prior to iOS 7, when dragged they followed the position of your finger directly, like physical switches. Post-iOS 7, they only animate after your finger has moved past a threshold, but the toggle graphic expands when held to indicate that it is still draggable.
How typical of PWAs that even a demonstration site, which should demonstrate the best that PWAs can be, has a glaring UX bug on iOS.
Namely: if you swipe from the sides of the screen to go back/forward, you get a duplicate animation. If you swipe back from B to A, once the native (interactive) slide animation finishes, the page then jumps back to B and then does another (noninteractive) slide animation to A.
Fixing this would be as simple as disabling the page's slide animation, but whoever made this site didn't notice or didn't bother.
Apple does have some blame here. Disabling the page's slide animation wouldn't be a perfect solution since it wouldn't distinguish slide gestures from other ways to go back/forward (which ideally would still show an animation), like using the browser's back/forward buttons if accessing the site in a browser rather than as an app, or using a keyboard shortcut with an external keyboard. I don't think it's possible to easily detect which kind of gesture triggered navigation (in order to conditionally show the animation).
Another option would be to disable the native slide gesture entirely in favor of a fully JS-based one. In the past it wasn't even possible to disable it, but that has been fixed for years now [1]. However, it's hard to exactly replicate the native behavior.
Ideally there would be a more purpose-built interface to detect and customize the native swipe gesture.
The native iOS behaviour is to only do that when flicking (ie. scrolling and letting go). Didn't see anybody copying that yet. However, it makes a huge difference in usability.
Be warned, though, that if you slide your finger before the slider finishes animating in, that movement is ignored. Too many times I tried a quick adjustment like that only for the volume to remain the same after my movement. It’s why I added separate volume buttons to my Touch Bar and switched to using those primarily.
The sad thing is there’s no good reason for the slider to ignore your input during the animation. I think Apple just didn’t care enough to test it thoroughly. They only tested the Touch Bar with computer newbies who press every key slowly.
As a non iOS user, I always get thrown by the horizontal slider toggles. I can never tell by looking at one if it is on or off. And sometimes on touch screens I try to slide them sideways and it doesn't work.
The animated transitions don’t work very well with iOS’s built-in “swipe from left edge” back gesture. The animation appears to double-play, since the Safari back gesture implements the reveal animation in native code, then once it sends the back event to the browser, the library plays its own animation.
He lists that as a separate bug, so it seems the drag targets are too small and they don't respond to taps.
I had some trouble myself interacting with an iOS7 time picker but it was about confusion of how wide the active areas where.
I'm also dubious of the still skeomorphic toggle buttons. They look like something you could drag across to activate, but you need to start your drag on the toggle switch so they're basically buttons.
Quite a few people are mentioning prior art and then going on to give examples where it's just an animation. I'm not saying that there isn't prior art however it does specify that the animation is initiated with a finger:
"The animation responds to a simple swiping motion with the finger, which turns the page over just as it happens on a paper book. A different swiping motion will flip the pages quickly, and a vertical finger movement will flip the page just enough to reveal what’s on the next page."
Talking of which - does anyone find the iBooks animation to be slow and annoying? On my iPad 3 it lags for a split second and generally feels a bit rough. It sounds picky but it's quite annoying and judging by a quick search on Google, others are annoyed by it too. Has it always been this way or is this a bug that will be fixed?
Another hidden tweak (that unfortunately interferes with yours): "Swipe between pages" set to "Swipe with Three Fingers." No more animation when navigating back/forward in Safari, and it works in more places to boot, e.g. Finder and Xcode Documentation. (This is because it uses an entirely different code path for navigation. Some more context under "Technical Notes": https://sensible-side-buttons.archagon.net)
Apparently Apple has enabled a feature to reduce/remove the motion when switching, not sure if that fixes point 1 above, but worth a try: http://apple.stackexchange.com/a/255220/183228
30 here. On my iPad, if I bring up an app in the floating view, I often have to rediscover how to dismiss it. I just tried to do it now and this is how it went:
My first instinct was to flick it up from the bottom, but that brings up the recents switcher. Next instinct was to try flicking it off to the right, but it just moves a bit and springs back. While trying more times to fight the spring I noticed a short bar at the top and realized it was probably a drag handle. Grabbed that and tried to flick it downwards. No luck, but it moved in a way that made it seem like dragging down more would do it, but nope of course that wasn't it either. How about a flick to the right? Nope. Dragging it to the right? Agh! It's trying to dock into split screen mode! I dragged it around some more hoping for different behavior before dropping it back into place and again trying a flick to the right using the handle at the top. And that FINALLY did it. Apparently I didn't put enough enthusiasm into the first flick I tried... What a pain in the ass.
I don't like how sensitive to speed some of the actions are. I have similar issues with bringing up the dock. I usually end up going to the home screen instead.
Wasn't it the case that they used to prevent touch interactions until the animation finished? I remember moving to iOS from android in 2017 and being really annoyed at that, but they fixed it in like iOS 11 or 12.
Weird, I am on iOS 16 on both my iphone and ipad and i still have the swipe animation for books. Apple doesn't really do much A/B testing so this really kinda surprises me.
Edit: Think I figured it out - looks like PDFs still have the page turn animation on iOS but epubs are using the new animation
I got my iPad, tried several different apps, and I now see that the feature is present in all of the ones I tried.
I think what I did differently this time was hold the spacebar down long enough for the feature to kick in. On my android phone there isn't that long of a delay, so I think that's what threw me off.
It's likely a strange bug, but I think it's relevant since you can't _always_ slide it.
reply