

An Insider's View of Mobile-First Design - joemir
http://www.wired.com/opinion/2013/09/designing-for-mobile-means-ditching-deeply-ingrained-pc-instincts/

======
_greim_
> 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.

~~~
tadfisher
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.

~~~
crazygringo
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.

~~~
lnanek2
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...

------
wallflower
Instagram was referenced. The original presentation by Mike Krieger is much
better in my opinion.

[https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-
mob...](https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-mobile-
design)

