This is my first topic here on the jQuery Mobile forum, and it is also the first time I'm publicly showing the project I've been working on. Hopefully you don't think it sucks.
I think it's well known that there are some challenges to overcome around transitions and the blinkyness/jumpiness that is often experienced before and after a transition. The JQM team has provided the option to default to none if desired, which improves the user experience on Android, but it would be nice to smooth out the transitions a bit more, even when running on Android or other 3d challenged devices.
So, first the demonstration using jquery.mobile-1.1.0.js from the officially released JQM v1.1:
Now, for the demonstration using the customized version of jquery.mobile-1.1.0.js that uses the jQuery plugin "ScrollTo" (http://flesler.blogspot.com/2009/05/jqueryscrollto-142-released.html) to provide a callback to the scroll as well as easing, which actually uses another jQuery plugin "Easing" (http://gsgd.co.uk/sandbox/jquery/easing/). In this case, I'm using the "easeInOutExpo" algorithm. Note: while recording the videos (this one in particular) I made it a point to only use the down arrow button in the footer or the actual scroll bar to scroll manually (although, I messed up and did the two finger scroll in the first video above - i.e. while I was on the queue page - but didn't feel like starting it over). The rest of the scrolling you see is being handled automatically by the modified transition phases.
This was a bit of an experiment to see if I could take control of the necessary scrolls both before a transition (scrolling back to the top) and after a transition (when going back - i.e. the scroll back down to the last scroll position of the previous page when returning to the page). This video was taken in the best of circumstances (i.e. in Desktop Chrome running on OSX). In my limited testing, it seems to "kind of" improve things on the worst of circumstances (Android 2.x) but can still seem jumpy if the frame rate of the animated scroll isn't good enough to keep up.
Nice. I think your modified scrolltop looks pretty slick (same for the app!) If i could choose, I'd much rather have a slick scrolltop than the current fade in/out impelementation. how about cross posting on Github?
Thanks, I'm glad you like it. At the moment, only transitions using a sequential handler work fully with the modified scrolltop logic. When a transition that requires the simultaneous handler is used (e.g. the classic slide) the smooth scrolltop works, but the actual slide out transition of the current page isn't working (the from page just disappears and the to page slides in as it should). Of course, the from page should slide out simultaneously while the to page is sliding in. So, I need to fix that.
I'd also like to provide a configurable option to not only choose whether to use the smooth scrolltop, but also a choice of whether to use a simple smooth scrolltop (a standard jQuery animate scrolltop) or an animated scrolltop with easing (using the scrollTo and easing plugins). And, it would also be nice to provide a way to specify which easing algorithm to use.
Before I spend any more time on it though, I need to get some more feedback to see if it's even worth it. Your feedback certainly pushes me in that direction though. So, a github post might follow soon enough. Cheers.
I spent the majority of the day yesterday trying to get rid of the blinkyness on Android when using fixed toolbars (header and footer in my case). I think I made some good progress, but it can still use some work. Here are two videos showing some basic navigation in my app while running on Android 2.3.7. Phonegap 1.6 was used to create the "native" app:
First, here's the experience with the officially released 1.1 version of the jquery.mobile-1.1.0.js and jquery.mobile.structure-1.1.0.css:
Note: In both scenarios above, I have Scott Jehl's recent opacity trick in place to prevent some of the flashy blinks that were making it even worse in some cases. It's still pretty blinky though with the official files.
@frequent: no, I don't mind. I commented on your feature request to offer a suggestion.
@mspisars: Thanks! I can still optimize it a bit more, but I'm happy with the performance so far. I will be releasing soon. There will be an open source version of MPDTunes for anyone that wants to free their music and own their cloud. In fact, the mantra will be; Free your music, own your cloud™. The free version can also be used to remotely control a server running MPD (Music Player Daemon). There will also be a premium version targeted to anyone that wants to run their own music cloud service such as the one I'll have running at www.musotic.com. I will be donating 10% of all profit to The jQuery Project to show my appreciation and support.
@zSprawl - thanks for the comment. However, I just don't think reverting to the 1.0.1 transitions would solve the fundamental issues that exist when using fixed toolbars. When I remove the data-position="fixed" attribute from my header and footer, the transitions improve 1000% (even with 1.1). But, there is still the scrollTop call before the transition and the jump to lastscroll when going back that causes a feeling of jumpiness. If you're not using fixed toolbars and you just want all of the old style transitions back, then reverting to the 1.0.1 transitions is probably the thing to do. If I remember correctly the jumps will still exist though right?
I also started a small repo with some files that people can use if they want to use the smooth scroll to top. It's more than that though, the jquery.mobile.defaults.overrides.js contains a heavily modified createHandler function that includes a lot of changes that seem to have gotten rid of a lot of the jumpiness and blinkiness on Android. See the README for some notable exceptions. Some of the blinks were addressed by slowing down the transitions.