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]> 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
