(apologies for the top post) Mounir and I did some experimentation last week with a ZTE device. We made a simple news reader app with a "splash screen" (full screen div, basically) that fades away once some RSS content is loaded:
http://marcoscaceres.github.io/playground/splashscreens/ Or: http://tinyurl.com/krs6bb9 I don't have numbers for how quickly the page loads and plays the animation, but seems ok on the device (installed as a bookmark to the home screen). Having said that, we experienced a few issues (which we haven't escalated to bugs yet): 1. Using an animated GIF (e.g. a spinner) can cause CSS animation to become choppy: See - http://tinyurl.com/nyry2wq 2. More seriously, adding a CSS transition delay causes content in the background to flash into the foreground during the animation delay. See - http://tinyurl.com/m9lmr56 The bugs above can make HTML splash screens a bit impractical today - but these are bugs that need to be fixed in FxOS. Adding a splash screen to the manifest will not address the issues above, which will need to be fixed regardless. Despite the issues above, I'm personally of the opinion that HTML pages in the application are the right place to do splash screens (i.e., we should not need to add anything to the manifest). However, it would be good to see other examples where doing something like my example application above is completely impractical. -- Marcos Caceres On Tuesday, 9 July 2013 at 18:40, Josh Carpenter wrote: > Hi Marcos, agreed on the points re: Games. The preceding performance points > include the caveat that I have not been able to follow this thread closely > and am not advocating one screenshot solution over another. > > — > Josh Carpenter > UX Lead, Firefox OS > Mozilla > > > > > > > > > > > > > > > > > > On Jul 9, 2013, at 6:21 PM, Marcos Caceres <[email protected] > (mailto:[email protected])> wrote: > > > > > > On Monday, 8 July 2013 at 10:29, Josh Carpenter wrote: > > > > > One important addition: if the user can see it, they should be able to > > > interact with it. > > > > Sure, but there may not be any elements to interact with on the screen: for > > a game, users don't generally expect to be able to interact with a > > 'loading" screen with a load progress indicator (not in a meaningful way). > > Same with a user who sees a company logo and a spinner underneath the logo > > - the expectation is there that something is happening in the background > > and stuff is loading … so long as the wait is not excessively long - at > > which point they may attempt to interact with the app to see if it's > > responsive or quit out of frustration). > > > Scroll, open, etc. That's key to responsiveness. > > > > > > I agree - but in addition it's about contextual expectation and > > responsiveness in relation to feedback from the application to the user > > with regards to what is going on… that is, at no point should the user feel > > that the application has stalled for a significant amount of time. > > > It's very frustrating when an app renders it's content and "looks" alive, > > > but does not respond to touch, or (almost as bad), exhibits extremely > > > choppy animation performance, unusual button press delays, etc. > > > > > > Exactly. This is why having good control over the transition between states > > (pages) is important, and developers are usually in the best position to > > control that (so long as the runtime is performant). For example, choppy > > animation because CSS transitions are crappy is more of a hardware problem > > than a developer problem (unless the developer has done things that are > > known to degrade performance, like transitioned drop shadows over > > transparency, or tried do do animation using a for loop or setTimeout > > instead of requestAnimation frame, etc.). > > > > In any case, my impression is that developers are in the best position to > > control the user experience of their applications. Our focus should be to > > make sure that the runtime supports this by executing JS quickly, animating > > smoothly (e.g., good CSS hardware acceleration for things like CSS > > transitions), and rendering the page as quickly as possible + providing > > good documentation on most performant ways to develop applications … mostly > > things we do pretty well today - but if not, we should focus energy on > > those. Adding explicit splash screen support might actually be a band-aid > > solution to some other underlying problem. _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
