An Insider's View of Mobile-First Design
1–7 of 7 posts
Re: An Insider's View of Mobile-First Design
#2> Fake It ‘Til You Make It
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.
Re: An Insider's View of Mobile-First Design
#3Instagram was referenced. The original presentation by Mike Krieger is much better in my opinion.
https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-mob...
Re: An Insider's View of Mobile-First Design
#4> Fake It ‘Til You Make It 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…
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.
Re: An Insider's View of Mobile-First Design
#5> Fake It ‘Til You Make It 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…
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.
Re: An Insider's View of Mobile-First Design
#6> Fake It ‘Til You Make It 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…
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.
On mobile, that isn't always possible. If I'm on my iPhone, and I upload something, the app indicates it's done (lying to me), then I close the app... and don't open it again for three weeks... how is it supposed to give me an error message? And replaying a network queue three weeks later might be even worse.
The app can't, because it's been closed. And the server can't e-mail me with an error or anything, because it might never have even known about the action.
At least on webpages, the page can intercept the close action with a modal dialog, then fires when you try to quit the browser or close the tab, warning that you have unsaved data. Mobile apps have no such last-case warning mechanism.
Because of this, I agree that lying to your users about successfully completed actions, on mobile, is bad advice. You're abusing users' trust, and once they discover that (and remember just how unreliable mobile connections are, so they're bound to discover it sooner or later!), don't be surprised if they don't come back.
Re: An Insider's View of Mobile-First Design
#7Earlier quoted context omitted.
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.
On mobile, that isn't always possible. If I'm on my iPhone, and I upload something, the app indicates it's done (lying to me), then I close the app... and don't open it again for three weeks... how is it supposed to give me an error message? And replaying a network queue three weeks later might be even worse. The app can't, because it's been closed. And the server can't e-mail me with an error or anything, because it…
I think you are a little out of date on mobile development. This has always been easy on Android, and many apps show a notification while they are upload large images, like Facebook. Any Android app showing a notification can request foreground scheduling priority for a background process. iOS7 recently caught up as well with background app refresh letting you make requests to a content server in the background without being started, just the system starting you regularly. Not that the iOS4 ten minutes after use background task was usually insufficient and the server failing to see it complete could have been used to send a push anyway...