I.e. don't wait for confirmation from the server that the action was successful, before you indicate success the user. This can dramatically boost perceived performance in an app, mobile or otherwise.
However, even if this gain is too tempting to resist for a startup struggling to gain traction, I think it deserves to be mentioned that it's a slightly dishonest thing to do. For example I've been burned a few times after closing the app and going several hours or days, only to learn that my photo never went live. It can be infuriating. For less trivial apps, it can only be worse.
The solution here is to show an error notification after the fact. A good way to handle this is to bake a failed-request queue into the network layer, and to ensure requests are serializable and replayable. Obviously, mobile designers need to consider failure cases and the best user experience to deal with these.
My frustration arises not from progress bars per se, but from progress bars which block further action until the task is complete. I like how iOS shows the user that a message is being sent while allowing them to do other things in the interim. I hate how Google Voice for iOS blocks me until a task is complete.
[+] [-] _greim_|12 years ago|reply
I.e. don't wait for confirmation from the server that the action was successful, before you indicate success the user. This can dramatically boost perceived performance in an app, mobile or otherwise.
However, even if this gain is too tempting to resist for a startup struggling to gain traction, I think it deserves to be mentioned that it's a slightly dishonest thing to do. For example I've been burned a few times after closing the app and going several hours or days, only to learn that my photo never went live. It can be infuriating. For less trivial apps, it can only be worse.
[+] [-] tadfisher|12 years ago|reply
[+] [-] JumpCrisscross|12 years ago|reply
[+] [-] wallflower|12 years ago|reply
https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-mob...