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

Reply via email to