3 Replies Latest reply on Oct 2, 2012 8:11 AM by Jon Tara

    Slow animations/transitions in RhoMobile app

      Hello everyone,

       

      We are currently working on a RhoMobile app. When we build the application and test it on a device (iPad 1, iPad 3, Motorola Xoom), we see that the animations and transitions are pretty slow. They aren't as smooth as they are when we test the application in the browser or simulator. At the moment the animations ruin the user experience on the tablets.

       

      Our main transition animations are made in CSS. We use the following code for them:

       

      #listMenuScroller
      {
                position:                              absolute;
                z-index:                              1;
                width:                                        18.75rem;                                                                                          /* 300px */
                padding:                              0;
        
                -webkit-transition: all 0.5s ease-in-out;
                -moz-transition:          all 0.5s ease-in-out;
                -o-transition:                    all 0.5s ease-in-out;
      }
      
      .al-animation-options {
                -webkit-transition: all 500ms;
      }
      .al-navigation-animation {
                left:                                        -100%;
      }
      

       

       

      On some jQuerey Mobile experiment site we found some code that disables all the shadows for jQuery Mobile. This improves the animations already a bit, but it's still not smooth. The animations are still slow and strange.

      It's the following code:

       

      /* disable shadows for better android performance */
      .ui-body-a,
      .ui-bar-a,
      .ui-btn-up-a,
      .ui-btn-hover-a,
      .ui-btn-down-a,
      
      .ui-body-b,
      .ui-bar-b,
      .ui-btn-up-b,
      .ui-btn-hover-b,
      .ui-btn-down-b,
      
      .ui-body-c,
      .ui-bar-c,
      .ui-btn-up-c,
      .ui-btn-hover-c,
      .ui-btn-down-c,
      
      .ui-body-d,
      .ui-bar-d,
      .ui-btn-up-d,
      .ui-btn-hover-d,
      .ui-btn-down-d,
      
      .ui-body-e,
      .ui-bar-e,
      .ui-btn-up-e,
      .ui-btn-hover-e,
      .ui-btn-down-e,
      
      .ui-shadow-inset,
      .ui-icon-shadow,
      .ui-focus,
      .ui-overlay-shadow,
      .ui-shadow,
      .ui-btn-active,
      * {
       text-shadow: none !important;
       box-shadow: none !important;
       -moz-box-shadow: none !important;
       -webkit-box-shadow: none !important;
      }
      

       

      Did any of you experience this too? And did you find any solution for this?

      We would love to fix this problem so we can serve a better user experience to the users of our tablet app.

       

      Any help or tips would be appreciated. Thanks!

       

      Best wishes,

       

      JW Geertsma

        • Re: Slow animations/transitions in RhoMobile app
          Jon Tara

          On the devices that have this problem (mostly Android) there isn't anything you can do. It is a browser limitation. Android mobile browsers are notorious for poor transitions.

           

          On iOS, you have to be aware of a couple of issues. First of all, Webviews are hampered by slower Javascript than Mobile Safari, because they lack the Just-in-time compile feature. It's not Rhodes-specific. The same Javascript will run slower in a Webview than it will in Mobile Safari itself, and there is no getting around it.

           

          Secondly, iOS does not automatically use hardware acceleration for transitions. You can "hint" the browser to use hardware acceleration by using a null 3D transform, like translateZ(0). Search for more information on this. There is a bit of an art to picking the right elements to do this on, since it can be costly to apply this to a large number of elements, and it usually isn't necessary to apply it to the entire element heirarchy.

           

          My best advice, though, is to not use transitions, because they aren't handled well yet on a wide variety of mobile devices. IMO, no transition is a vastly superior user experience anyway. Transitions are used mainly to distract the user from slow software, ironically introducing more delay in the process.

           

          One small trick: you should never use ease-in. On iOS, if you use standard "click" processing, there is first a 400mSec delay. Even on other platforms, there can be some delay, and, as well, there is a perceptual delay just from typically triggering when the user lifts their finger rather than just touches. (I use touch in some cases, but it is limited where you can apply this. For example, not in a scrolling list, because then you can't distinguish touch from scroll). With ease-in, you are just piling another delay on top of delay - it doesn't make sense, but I'm afraid it's the default for the built-in jQuery Mobile transitions.

           

          The loss of "physics" from leaving off ease-in is not disturbing or even perceptible to the user. They still get the ease-out which reinforces the physical analogy. They will perceive the starting inertia because of other delays that are always going to be there.

            • Re: Slow animations/transitions in RhoMobile app

              Hello Jon Tara,

               

              That's a lot of intresting information, thanks for your reply!

               

              Removing all the transitions from our tablet application is not an option. We want it to look as close to a native app as possible. Animations and transitions can really give the user experience a boost.

              I will try the iOS suggestions for hardware acceleration. Hopefully that makes the animations in iOS a bit better.

               

              Is Motorola aware of this issue? Will there be any solution soon? Our app is really slow, and has irritating animations at the moment. We would really love to provide our app users a better experience.

                • Re: Slow animations/transitions in RhoMobile app
                  Jon Tara

                  With each release of iOS, it gets a bit better. With each release of Android, it seems to get a bit worse.

                   

                  A lot of developers had been hoping that iOS 6 would bring JIT compilation to Webviews. Alas, it did not. But it did bring some performance improvement anyway.

                   

                  I would urge you to reconsider, and think about what you are trying to accomplish with the transitions. I think that anything that slows the user down is generally undesirable, and transitions intentionally slow the user down. They can be useful to reinforce the user's internal model of data connectivity or workflow, etc. - IF carefully chosen, and IF well-implemented.

                   

                  But transitions on mobile browsers today are NOT well-implemented, so what you are introducing is an unnecessary delay and a distraction. I don't know what kind of app you are developing, but I think in the industrial types of apps that are probably typical for Rhodes what your users will really appreciate is if your app just gets on with it and dispenses with the flash. You can use other cues to reinforce data relationships and work flow.

                   

                  Should you update to jQuery Mobile 1.1 or later, you will discover another issue. The JQM transitions starting with 1.1 are horrible. They need to scroll each page to the top and then they try to hide the scroll with various tricks, and really none of the transitions look good. I have a little "plugin" (really, just a set of files you include in <head>) to restore the 1.0.1 transitions to 1.1 through 1.2. You also need to either be using iScroll or some other scroller, or else keep your pages to device height to use these most effectively:

                   

                  https://github.com/watusi/jquery.mobile.simultaneous.transitions