Is that from touch down or touch up? Most controls respond on the release because holding down or dragging is a different action in many (maybe most) cases.
I'm not perceiving much lag between touch up and animation start on the back button of the UINavigationController.
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.
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.
Hi Rich. On my iPhone, I get a 3-second delay between when I “swipe to go back” and when the page is usable/scrollable on the Sapper HN. When I first went to the site, via the link above, the top nav links did not seem to work reliably, and it may have been the same 3-second delay, but I’m only getting now when swiping to go back — maybe because the page is being reloaded from the server? It’s still quite a delay, though.
On iOS4, you need to trigger 3D acceleration to get acceptable redraw performance. You do this by using a 3D CSS transformation to move the object the user is dragging (translate3d with a z value of 0). The upcoming iOS5 is much better in this regard, and makes just setting .left and .top acceptable, so you could also just wait it out.
I want to believe, but every time I try their menus on my iPhone 4 I'm disappointed by jerkiness and delay. In particular if you scroll down on the demos page and click a menu item, you see
1) the page *jerk* to the top
2) a loading dialog with a spinner over the whole page
3) a *nice* smooth animation into the new page
Then when pressing the back button:
4) a nice smooth animation to the *top* of the screen
I've lost my place! Actually navigating a hierarchy with this is painful, slow and disconcerting.
Can anyone from the project comment on what the technical reason for this is?
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.
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.
Another major thing they have to fix that I hope to God someone at Apple is thinking about are the 4 and 5 finger gestures in the OS on iPad. The 4-finger squeeze to get back to the springboard is a disaster since it just slows down the animation and you can see the horrible aliasing of the icons. The 4-finger swipe up no longer makes any sense either: it perviously slid up the screen to reveal the task tray, which is a logical direct manipulation, and now it jumps to the new task view. There is no longer a sense that your fingers are manipulating anything, it's a meaningless gesture slash macro holdover from iOS 6 that needs to be re-thought.
On my iPad mini there is also a noticable lag when you slide up the control panel and slide down the notification panel, particularly on the first swipe. And swiping down on the springboard to reveal search drops a few frames too so it's a jerky jump at the end of the animation. And god damn, I wish they would just make it so you can swipe the lock screen in either direction to unlock, the number of times I've swiped the wrong way (since there is no longer a button to slide) is crazy and pointless.
I guess I should file some radars or look these up :)
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.
> There used to be a behavior in UIKit where you could scroll a view and tap to stop the view and quickly tap a button to move on to another screen, and at some point in time when Apple moved away from skeuomorphism, the UIView scroll behavior changed in a way that from then on forced users to wait for scrolling to stop before tapping a button, but they also injected a full fraction of a second, probably somewhere between 200 to 600ms before you could interact with UI controls again.
Is this specific to certain types of scroll views? I just played around in my Mail app inbox (most likely built with UICollectionView) initiating flick-scrolls and then double-tapping to stop the scroll and select the message under the tap and it works exactly like the original behavior you describe with zero delay.
The sidebar swipe animation needs some attention; they tried to add a cute little bounce at the end when the main panel slides in and out, but it just feels weird. Nothing else does that on iOS.
Can cause problems while appearing to satisfy the desire for responsiveness. For example, on the iPhone: recent messages or calls may update in the middle of a touch, so the location of the input (thumb) actually initiates a call or brings up a thread not intended by the original display.
Showing what had been, and then updating the action of a display location, creates a UX of "shifting sands".
Often annoyingly occurs with popup ads, but in an iOS app itself is inexcusable.
I just hold the phone a little higher up in my hand and I don't seem to run into this issue. meh..
That said, I prefer having an option of manually refreshing the UI. When I'm connected to a spotty 3G tower - I don't get any indication if its fetching data or not. I suppose I can drag down the main UI and expose the iOS status bar and see the little circular progress bar, but not an ideal situation.
It has to do with the way UIViewController titles now work. When you tap something that pushes a new view controller onto the stack, the current title animates left and _becomes_ the new back button. The animation is not only pretty, it makes it really obvious where you are going, and how to get back.
There's no swapping on iOS. The delay is probably caused by iOS lazily waking up some hardware. The same happens when you use haptic feedbacks:
>Calling the generator’s prepare() method puts the Taptic Engine in a prepared state. To preserve power, the Taptic Engine stays in this state for only a short period of time (on the order of seconds), or until you next trigger feedback.
I'm not perceiving much lag between touch up and animation start on the back button of the UINavigationController.
reply