Mobile applications, and especially mobile games, are frequently used in short bursts. These bursts could be due to short attention span, short task, incoming call or message, the train arriving, or any number of other things. Thus the user will frequently exit the application, either intentionally or unintentionally.
Once the user exits the application, if you don't want her to use the application again, do some of the following:
- Have an unnecessarily large application footprint. That way, the application will take a long time to load, so the cost of restarting the app is high.
- Phone home with every launch. This technique lengthens the time until the user can start using the application again, prohibits her from using it without coverage, and can run up her data charges. You wouldn't want to set a time stamp for end of license and only phone home when the license has expired - no, that would let people back into the application too quickly!
- Don't save user data. If the user has to re-enter data, she is less likely to use the application again. If she gets interrupted in the middle of searching for an airplane ticket, by all means erase all the search parameters.
- If you have to save user data, save it for a long time. Our fearless user will definitely want to search for a ticket for August 12 the next time she uses the application - on August 15.
- Be oblivious about user context. You know that your user is on that trip to Tokyo ... offer her information about events happening in New York! Especially if she lives in London.
- Destroy user state. A more advanced version of "don't save user data", this will require users to start at the home page or main screen every time she starts the application. You wouldn't want to return her to the news item or video clip she was viewing two hours ago - make her find it again!
- Force a single user interface onto all devices. Especially fun is requiring touch screen users to use virtual hardware buttons, but using one of the softkeys as "Back" on a device that has its own Back button is particularly popular. Couple this with making the hardware back button inert! After all, the user knows how to use her own device's user interface paradigm: you wouldn't want to support that.
- Use a tiny font and subtle colors. This technique increases users' eye strain.
- Don't remember the user. Requiring the user to type a user name and password each time adds to the experience. Advanced: require mixed case, numbers, and symbols in your passwords.
- Expire passwords and sessions after a couple minutes. Those of you in the financial sector know all about this one, but some of the rest of you haven't tried this trick yet. Because somebody might walk away from a computer and expose secure data to prying eyes, keep the session timeout for a mobile device very short, because people walk away from their phones all the time, letting strangers use their connection and services.
There are more methods. Can you give me your favorite? I'll post a new collection in a few days.
Note that when you comment, an error will appear. Your comment has indeed been received and will be unscreened soon. We are working on this.
I loved this
. It complements MobHappy’s “What a Waste” article posted today about content downloading problems perfectly. It seems we in the industry know everything there’s to know about providing good and easy-to-use services to end-users, not. At least it can get better.
Here are a few suggestions of my own, that are more general than just the exit case (that assumes you’ve been able to run the application at least once; I’m more brutal):
Make the application so that it only works on a tiny fraction of the phones available. It’s more important to support the very latest features than that the application can be used.
Always favor the very latest smartphones. Everyone should have a smartphone anyway, as they are more advanced, and cost and weigh more. The market hasn’t understood that yet, but they will eventually. Maybe as soon as next century.
Don’t certify applications. Users want to get a gazillion messages like “Do you want to allow file access?” etc. Not confusing at all.
Don’t design a good-looking application icon, and give the application a crappy non-intuitive name like “Nice Game”. Users want to search forever for the application. Phone manufacturers have done a good job hiding away the application menu, so why not make it even harder.
Wizards as used in Windows and Mac are for cowards. Instead hide important functions in menus, and give menu elements strange names, so that the user gets a chance to explore the application.
If you sell the appliation to an operator refuse to private-label. Your brand is much more valuable to consumers than the operator’s.
Test the application only on one phone. Everyone knows that mobile platforms work exactly the same on all brands and models. Sun, Palm, Symbian and Microsoft can’t make mistakes.
Let’s not forget my perennial favourite: make the application only installable from a website that requires you to have a US mobile phone number. That’s really important because the US is the world’s biggest mobile phone market, with the most sophisticated handsets, cheapest data rates and highest mobile application usage! But it’s easy to forget and accidentally make your application available to consumers in countries outside the US, so always remember that “+1″ country code requirement.
What do you mean? The US is the center of the world, right?
Heh.
On the other hand, assuming that the US is “like Europe, only backwards” is a dangerous assumption all around.
I recomend producing products that are dated by the time they are purchased. Release games/ringtones/images for movies, after the movie has been out awhile.