There are interesting conversations going on over on Scoble's blog and on Smuga's blog about developing software for mobile devices.
I figure now would be as good a time as any to chime in with what has become my biggest pet peeve in the world of mobile web development: Making poor assumptions about device capabilities and forcing them upon your users.
The most annoying example of this is by far the new Gmail Mobile. Here's a story:
It's New Years Eve 2006. I'm at a party with some friends. One friend asks if he can get into his Gmail on my phone to show us a picture of a dog he rescued. "Of Course", I respond. I've been using the basic html version of Gmail on my phone for quite some time, and I knew they even recently launched a version of Gmail optimized for mobile devices.
So, we pull out my phone, and navigate to gmail.com. We're automatically brought into the new mobile version of Gmail, which displays attachment file names, but will not let you actually access the attachments! Okay, I figure we can somehow access the basic html version of Gmail that I've been using for about a year. Nope. The Gmail team made the assumption that based on my web browser version, I should only be using the new mobile version of Gmail. They did not provide a way to access the basic html version, despite the fact that it works fine on IE Mobile.
It gets worse. If you go to Gmail Mobile with a browser on a PC, at the very bottom of the page, you ARE given the option to view the basic html version:
View: basic HTML | mobile
So, the team has built the functionality, and simply decided not to expose it, stopping the user from correcting incorrect assumptions made by Gmail's auto-detection/redirection.
I'm picking on Gmail here, but there are many many other offenders. Even the MSN Mobile homepage does a detect and redirect - so you can't access the mobile version from a desktop browser (or at least, from what MSN Mobile thinks is a desktop browser). T-Mobile.com does something similar - when you visit it from your mobile device, you're redirected to a PDA version with very limited functionality - even if your mobile web browser supports everything your desktop web browser does. No way to break out of the walled garden.
In designing software, you generally have 3 options when it comes to conditional branches in the user experience (i.e. "if user is mobile, show x" or "if user has an msn passport, do y"):
1. Make no assumptions - One option is to make no assumption, and to ask the user for information. At first glance, this might seem ideal, as it gives the user the most flexibility. On the other hand, if you present the user with every single option you can think up, you'll end up with a horrible user experience. In mobile user experiences (largely due to constraints around interface size, navigation constraints, and slow network connections), you want as few unnecessary steps as possible. An example of a mobile site that makes no assumption is MSN Mobile's weather pages. When the user accesses MSN Mobile Weather, she is told that logging into her passport account will personalize the service, and is asked if she wants to log in. All she wanted was to look up the weather - does she really need to be prompted to log in at this point?
2. Use intelligent defaults - Another option is to use intelligent defaults. If 80% of mobile browsers only support version x, display version x by default. But allow the user to switch to version y, correcting assumptions as necessary. In the above example, do not prompt the user to log in. Show the user the weather information she came to the site looking for, then allow her to log in, contextually to the displayed information, if she so desires. Intelligent defaults are almost always the way to go with mobile development (and oftentimes, with software development in general).
3. Make final assumptions - The 3rd option is to make assumptions on the user's behalf, and make them final. This is absolutely the worst option, in my humble opinion, and leads to the pet peeve described above that bothers me so much. This is the service saying "I know what you want better than you know what you want, and I'm gonna give it to you, and you're gonna live with it, like it or not."
If you're a developer, especially a mobile developer, you should be thinking about these options on a regular basis. Your users will love you for it.
Subscribe to:
Post Comments (Atom)
2 comments:
The reason why the user is asked to log in when accessing weather is because we want to look up weather for the user's location which we can't retrieve without her first logging in. Sure - we could let the user enter a ZIP code without logging in, but the user would have to always re-enter the location. I think both approaches are valid, and we can improve the experience a little bit (maybe show weather for the users location when she's logged in). Also, once you log in you are permanently logged in from that device until you explicitly log out, so you don't have to re-enter your credentials every time you want to access weather.
I understand, and I agree that we can improve the experience a little bit. ;-)
We could, for example, start by accepting inputs other than zip codes. So, if I for example, wanted to find out weather conditions for Whistler, BC Canada (or heck, even Las Vegas, NV), I could use MSN Mobile Weather to do so!
Also, keep in mind that often-times when people are looking for weather conditions, it is because they are away from their home cities, or because they are considering traveling away from their home cities. Home city is generally a good intelligent default. But is prompting for a username/password just to determine home city (which may or may not be relevant) the best design?
Perhaps prompting the user to provide location information OR (or/and, actually) giving them the option to sign in on the same page would be ideal.
And, of course, if you really want to get me started, a great intelligent default would be an educated guess at the location of the device based on ip address or maybe this device has done a local search or requested driving directions and the information provided to those services could be used to determine the location for weather.
Are you going to hurt me on the bus to work tomorrow morning? ;-)
Post a Comment