Asynchronous UIs - the future of web user interfaces

Re:Asynchronous UIs - the future of web user interfaces by fiatpandas on Wednesday November 16, 2011 @02:02PM (#3244513)

For me, when something loads too fast, I think something broke because my brain has been wired to learn than actions through a web browser are generally not instantaneous and take a bit of time. Even if it's just a fraction of a second.

I really like this idea, but for some reason I think my brain would be more comfortable with a ajax spinner appearing for 300ms rather than an instant page load. For instance, I built something recently which loaded images on a page via ajax calls. It happened very quickly, 50ms maybe. The loading seemed way too fast so I actually delayed the images by about 300ms. It seemed a much more comfortable delay, and a few of my non-developer friends agreed.

Is there a sweet spot, or am I crazy? Let's just ignore amazon and google's data for the sake of argument.

[ Parent | on HN ]

Re:Asynchronous UIs - the future of web user interfaces by dgeb on Wednesday November 16, 2011 @02:10PM (#3244548)

My solution (for an app in development) is a status indicator that shows users when they're offline, sync'ing, or sync'd.

[ Parent | on HN ]

Re:Asynchronous UIs - the future of web user interfaces by fiatpandas on Wednesday November 16, 2011 @02:16PM (#3244588)

I think something like this will be key. For me, as absurd as it sounds, the delay is the indicator. That indicator needs to be replaced if actions are to become instantaneous.

[ Parent | on HN ]

Re:Asynchronous UIs - the future of web user interfaces by damoncali on Wednesday November 16, 2011 @02:06PM (#3244537)

I know what you mean, but I think you'd get over it pretty quickly with exposure to the new way.

[ Parent | on HN ]