Recent Blog Posts

A comment to a previous post reminded me of the inclination of all of us to succumb to anecdote and personal experience, even when we should know better.

While I've been complaining about the way that, say, Opera Mini operates, only about 15% of mobile subscribers currently have browsers with the "full web" experience like this. And only a bit over 60% have internet access at all. Yes, its trending up, but pretty slowly.

So, mobile subscribers are three times as like to have a simple WAP browser as a "full web" browser. Transcoding and other trickery aside, these are very, very limited browsing environments. If a desktop-intended page loads at all (doesn't crash, restrict access due to cookie or javascript needs, etc.) it is often going to be difficult to use (most do not support sideways scrolling or selection, for example). So, what to do?

• Site designers and developers should keep good general design principles in mind, like designing for accessibility
• WAP browser manufacturers need to work on making their browsers less likely to crash (or worse, lock up so the user has to power cycle the whole device); note I'm not at all demanding they process everything as intended on the desktop, just that the browser recognizes there is a problem and abandons that process without excess drama
• Site owners should invest in mobile-specific sites, mobile-specific style sheets, and testing to assure the site works on all targeted devices and browser; at least assure that none of the technology used on the desktop site will specifically not cause failures in lowest-common-denominator WAP browsers
• Search providers should consider the browser being used; even if full-web results are shown, indicate how likely it is that the result will work on that browser
• Be very, very careful with your own site's metrics; if almost every mobile user is viewing from "full web" style browsers (Opera Mini, iPhone, etc.) that could well just be due to its difficulty to use -- or inability to even work -- on many WAP browsers

Next: what about all those subscribers with absolutely no mobile internet access?

Apparently I have nothing better to do over the holidays than catch up on back reading. In this case, I had downloaded the Nielsen Norman Group's research report, Beyond ALT Text: Making the Web Easy to Use for Users With Disabilities (currently free). It is a useful report, providing 75 guidelines for accommodating users with vision and motor difficulties. The guidelines are summarized starting on page 35.

I point you to this report not because I expect many readers of this blog are designing web pages for computer users, but because I know many of you are designing mobile web sites. Designing for accessibility by all users includes designing for accessibility by mobile devices, and the majority of these recommendations apply.

• Very important to mobile: 1, 2, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 27, 28, 30, 32*, 33, 34, 35, 36, 41, 43, 44, 45, 46, 47, 50, 51, 54, 57, 58, 59, 64, 65, 67, 68, 73, 74
• Useful for some mobile users: 3, 4, 5, 6, 18, 20, 21, 22, 25, 31, 39, 40, 42, 48, 49, 60, 62, 69
• Won't hurt a mobile site: 23, 24, 26, 29, 37, 38, 52, 53, 55, 56, 61, 63, 66, 70, 71, 72, 75
• Don't do on your mobile site: none

* More relevantly, make the page title element be meaningful. Users use that information in history and bookmarks; if they can't tell the difference between your home page and a specific story page they won't be able to find you again easily.

The reason why there is so much crossover is that using a small screen to view a large page is a very similar experience to using a screen magnifier, and using a very small scroll-and-select device (mass market phone, no touch) is very similar to using a screen reader. Even the vision difficulties can be replicated by phone use: phones are frequently used in less than ideal lighting conditions, or in vibration environments. Motor problems are replicated by trying to use touch screens with fingertips and operating the device in vibrating environments. Cognitive problems are replicated by slow rendering and download speeds combined with environment distractions.

This logic applies both to designing assuming the browser will shrink your "full web" down to a phone as well as designing mobile web sites from scratch.

As I was investigating the most popular entries in our blog, I discovered that Designing J2ME MIDP Navigation continues to be our most popular blog entry. In the past 6 months, it has double the hits of any other entry.

The content in the article remains good, but I certainly understand why so many people left the page as well. And designing for Java ME (previously J2ME which has always been annoying to type), we still have a oldie but goodie: User Interface Design Guidelines for J2ME MIDP 2.0. It’s a self-published book we put together after MIDP 2.0 came out, and contains a number of patterns, design recommendations, gotchas and so on. It’s dated, but the fundamentals are still accurate.

One of my favorite features of a modern desktop OS is the ability to kill threads, and abort applications that have become unresponsive. Ideally, the OS would work this out for me, but it doesn’t so I am okay with doing this myself.

The S60 platform is clearly a tiny little computer. And it seems to have a health monitoring system in place. I crashed the hell out of all my browsers the other week playing with some embedded flash on mobilized web pages, and after a while the phone restarted all by itself. It was clearly some sort of “I am crashed, better restart now” system, as it was much faster than usual, and there was none of the “3G” meteor animation that AT&T installed for the normal startup.

Neat, but not universal. The other day the Gmail app crashed. The protected memory worked great and I could run all other apps just fine. But I cannot quit the crashed application. Finally, after three days, I decided last night I had some spare time (I do use the phone constantly) and restarted.

The S60 even has an application switcher; offering running app management would be trivial in teh GUI, and I suspect (due to the auto-restart) is relatively easy from a function perspective as well. Smartphones are complex enough now that this sort of non-happypath function needs to be addressed today.

NPR's Morning Edition this Boxing Day morning had a nice summary of how the U.S. mobile market is so far behind some foreign markets. Using Japan as an example they walked through a series of services: synching video and music on the cradle and a mobile wallet system to buy products and subway tickets.

There is some feature listing, and even one consultant quote, that says U.S. phones and networks are not as good and that's why the Europeans and Japanese are ahead of us. I personally see a lot of well thought out services, and ease of use, adding to this level of adoption of advanced services like mobile TV; the combination of landscape presentation and good display quality, along with a recognized TV brand (in Japan) have certainly driven this mobile TV market.

John McChesney, NPR's technology guy, also made good mention of the fact that the mobile web is generally available to US consumers, but not that useful due to "the fact that most internet websites haven't tailored their page to that small screen."

We're wrapping up for the holidays; I won't be writing again for a week or perhaps two.

To keep you folks working through the holidays engaged, check out the MEX conference 2008 Mobile User Experience Manifesto. There's lots of good stuff for thought and discussion in there, as each point is at least somewhat right and all are important. We'll be talking more about these points next year.