Search the site
What we do
Little Springs Design is a mobile product, research, design, and usability testing consultancy. We help wireless operators, associations, manufacturers, and application & website providers with product and UI design, patterns, training, research and strategy.
Contact us today.
Downloads
Sign up to get a free copy of our Mobile Widgets Whitepaper or almost-monthly newsletter. Or buy mobile Java or web design guidelines.
Recent blog entries
Blog topics
Blog archives
What’s wrong with the mobile web? (part 2)
The browsers are a major problem with the mobile web.
In the previous installment, I talked about the problems associated with sharing information between screens. But the problem runs deeper. Issues include:
- launch times for content are too long. The user starts the browser, goes to the home page, and navigates to the desired site. This isn't too bad when time-filling, but it is bad when the user wants to see her agenda for today or download that song she just heard. Of course the network is a major contributor, but the browsers themselves slow things down.
- cookies are broken. I've posted on this before, but it bears repeating: cookies are the primary mechanism web sites have for saving user input, managing sessions, and in general making the web page act more like an application. Without cookies or work-arounds, web sites do not have any personalization.
- password management is awful, especially with broken cookies. Add a password manager, automatically filling user names and passwords into all sites. This can be protected by a simple 4-digit passcode, or any other mobile-friendly password, to be entered to allow the password manager to fill in the form.
- repeated text input in general is too difficult. At a minimum, the user should be able to enter commonly typed information, such as a physical or email address, and have the information automatically filled while typing. Perhaps some more advanced predictive text input schemes can do this, but browsers should be able to do it too.
- context is lost whenever the user exits the browser or goes to another page. If the user has to go check the phone's address book to get a bit of information to enter into a web form, many (all, in my experience) mass-market phones require the user to exit the browser. The browser then starts at the home page (and since cookies aren't working ....). The user might navigate to the page again, or might quit entirely.
- standards support is inconsistent. When I wrote a detailed user interface design guidelines document, I devoted ten percent of the document to listing what each browser did and did not implement in CSS. This was a few years ago, but many of the smaller bugs remain. This issue just exacerbates the alphabet soup of WML, XHTML MP, XHTML Basic, CSS, WCSS, SVG, and so forth.
Opera Mini is great, but still suffers many of the above problems. It also suffers from being a Java ME application, without ready use of the native text input mechanisms. Controls for changing input mode on my phone, for example, are typically found on the right softkey. I almost failed at discovering that the * key would control it instead.
Opera Mobile has a good user experience, and I suspect that Nokia's high end browser does as well. They suffer the problems from the previous posts, but are pretty good. I can't comment on their issues in detail since I focus on mass-market phones.
Not to leave anybody out, my next post in this series will address carriers.
No Comments »
No comments yet.
RSS feed for comments on this post.