[wp-hackers] AJAX and responsiveness

[Tom Armitage]

Updating UI immediately is, imho, not optimal - users in a hurry are
likely to click away, assuming things are complete. And it's not
enough to say "even though the visuals may have updated, the action
might not have happened, so wait a bit". If you want users to wait
until an action completes, wait for the visual element to update.

This is a downside to Ajax, but imho it's a necessary one - you can't
have the complete desktop metaphor. At some point, you have to give in
to basic HTTP.

On 17/08/06, Robert Deaton <false.hopes at gmail.com> wrote:
> On 8/17/06, Matt Mullenweg <m at mullenweg.com> wrote:
> > Part of the perceived speed of WP has nothing to do with execution, but
> > how it feels. Some of the new AJAX, for example deleting and approving
> > and unapproving comments, does save pageloads but I think under high
> > latency situations (ie, dialup) it actually makes WP seem slower and
> > sometimes broken. (But dangit if I don't love the approve/unapprove blinky.)
> >
> > I don't think there's anything wrong with updating the UI immediately as
> > a result of the user's actions, and then queuing up the requests to run
> > in the background. (And queuing them, not breaking if more than one
> > lines up at the same time.)
>
> I think updating the UI immediately is fine, if we watch _very_
> carefully for any condition where a user might be shown the UI for
> something they're not allowed to do. This involves a very fine-toothed
> comb and much testing, and if everyone is willing, then I say we
> should go for it.
>
> > Anyone have any proposed solutions or patches for this?
>
> /me points the finger at mdawaffe. :)
>
> --
> --Robert Deaton
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>