So, Facebook actually decided to improve their mobile application experience after going to Africa. It’s nice of them. Except they didn’t really need to go to Africa, just go to a bad coverage area. Or look at an overage charge from AT&T. And hey, suddenly US mobile life is not that great.
But I digress. I’ll re-iterate the rules of pleasant user experiences that applications should (but probably don’t) follow. It will make the mobile world waaaay better.
1. The most important rule: don’t be a hysterical princess. Crappy connections happen, so you should expect your internet connection to be abruptly yanked out. Or slow down to a crawl. It may disappear at any moment. No, user can’t wave a magic wand and make it re-appear, so don’t ask.
1a. Cache everything. All successful calls should be stashed into a local cache (ideally configurable as to how large it should be, with some reasonable default, say, no more than 1% of available storage). You have internet? Refresh. No internet? No biggie — show last successful data set (with date of refresh, if you’re nice). When nothing is available (first run, for example) show a calm and polite message, saying that data will be right there, as soon as stable internet connection appears and stays on long enough. You can even offer to show a notification when initialization is successful (“Let me know when initialization is complete). It’s nice to think that user is very interested in your app, but if they have something else to do, it’s even nicer when your app is polite and doesn’t make user stare at an empty/broken screen.
1b. No “internet connection lost!!” alerts. User doesn’t care. He/she is probably annoyed as-is at everything dying on the phone and your app having hysterics about lost connection, popup and all, is not going to make their day better. If you want to show that connection is lost, add a status icon? A plug, perhaps, or a tiny indicator light (green solid circle — everything is okay, red square — no connection, yellow triangle — crappy connection, color and shape for users that have color blindness).
1c. All outgoing operations should be stashed into queue and executed whenever connection re-appears. User wants to post? No problem, here’s local copy, once everything is back to normal, re-send the post. You should not do the classical “Can’t post right now, try later!”. No. You “try later”. Save it, send it later. Unless this app controls live-by-wire robot performing surgery, sending data later is not a problem (if you do write robot-controlling medical app, you probably know all this already). It’s okay to show “blah posts pending” somewhere. A good way would be to say “saved, will post as soon as internet is available” when having issues, and “posted successfully” when/if everything is fine.
2. Always make sure you support incremental upload/download. Google Drive suffers from it, for example (probably because engineers live in ever-connected utopia). If something has to be uploaded, we should be able to do it half-way now and half-way later. Because connection could be so unstable, that you can’t push that whole 13 megapixel photo in a single setting. Sorry, but that happens. So to avoid updating file over and over and over again, just re-stitch together bits on the server. I know you’re smart enough to do it.
3. If you can limit data amounts — degradable image quality, different amounts of downloads — do it. Things like compression probably should be turned on by default. Whatever the amount of energy required to unzip things is probably going to be well compensated by running active data transmission 30% less.
4. Please respect user’s privacy. I know your marketing department demands to have email right now, as well as all user’s contacts, mandatory right to post onto Facebook and all other totally “essential” (and completely irrelevant from the user’s point of view) things. Resist. If you do require a registration, allow it to be delayed? User probably trying out your app in a not very convenient location and forcing a total profile write-up at the moment of installation is a bad idea. Ask one question at a time, allow delayed answers. And please allow user to edit/enter stuff via desktop — tiny phones are tiny. And you won’t believe what auto-correct does to some fields
5. If you are writing operating system, please keep in mind that “free/open” WiFi can be a fake internet connection. Phone sees it, grabs onto it and… everything is dying because that provider demands you to click “I agree!” on a page of legalize nobody ever reads. But until that happens you’re in a limbo — WiFi is present but it’s not working. So resilience is very important, and ideally until WiFi interface is up and running reliably everything should be still using wireless data. Android was very good at showing if WiFi was connected and if it was actually working (different color of indicator).
6. Ideally your app should allow turning on and off background sync (with frequency of synchronization). Even better if you also allow option to sync more over WiFi or when connected to a charger.
7. If you do allow signing up for some sort of an account via “third party authentication”, such as Google or Facebook, or Twitter do not require additional info. You allowed Twitter auth? That’s it. No, you should not show “okay, and now also enter an email and password” because why the hell would I want to give you a twitter auth if I still need to enter an email. And a password. If your marketing department demands email, just don’t use email-less auth.
And that should be enough for data/connectivity experience to be much better