Tonight, I noticed Mike posted about a related issue on his blog:
Mobile WL Mail and screen width
Anyone who has developed software or web pages for mobile devices has run into the challenge Mike discusses. I'll sum it up like this: 80% of mobile devices (think: the free phones you get with a new cell phone service contract) have very limited capabilities. Their web browsers support a very limited set of functionality, can only load pages up to a certain size, etc. You, the developer, need to optimize around this 80% of devices with crappy browsers. The side-effect and problem is that now your UI looks horrible on those cutting edge brand-spankin'-new Smartphone devices.
But I guess I think differently than Mike, Mike, and Tim on the Windows Live Mobile team as to the best way to conquer this challenge.
I agree that supporting the lowest common denominator of mobile browsers should definitely be the highest priority, especially since the large majority of mobile browsers fall into that category. And trying to detect every browser and every device's screen width would be like trying to move Mount Fuji!
But that said, a good compromise might be to detect the most advanced mobile browsers (like, through the IE Mobile, Opera, or other user agent), which you know do support tables and other advanced features, and then doing some work around optimizing for those as well.
But that said, a good compromise might be to detect the most advanced mobile browsers (like, through the IE Mobile, Opera, or other user agent), which you know do support tables and other advanced features, and then doing some work around optimizing for those as well.
That way, you support and optimize for the early/late majority of users carrying devices with sub-optimal browsers, but you also support the small but highly important group of early adopters buying Windows Mobile Smartphones and other 'smart' devices. These early adopters are not only highly vocal, but are also the developers building the next generation of mobile software. There's also a chicken and egg problem here. If you want people to buy expensive Smartphones with x, y, and z capabilities, you need to build software that takes advantage of those capabilities.
So, supporting 80% of the market is important. But the tradeoff doesn't have to be losing the other 20%. You can optimize for both.
And, for what it's worth, I still use Google's mobile search, not Windows Live Mobile's, because it's UI takes advantage of more capabilities of my Windows Mobile Smartphone. How ironic that Google builds a service that is better suited for a Microsoft platform. But Mike says the WLM team is working hard to fix this problem, so kudos to him and his team for that.
Some other interesting reading on this subject:
My previous post on Assumptions and Defaults in the context of mobile development
Mike's previous post: 'PC sites on mobile phones'
Scoble's one wish for 2006
MobHappy on Optimized Sites vs Optimizing Browsers
Russell Beattie Reformatting vs. Rethinking
Popular subject.
As a sidenote, Jill and I faced a similar issue over the weekend in developing Ping, and we're only developing for Windows Mobile devices. The challenge is that even within the family of Windows Mobile devices, each device can have a vastly different resolution and orientation. We settled on dynamically laying out every single UI element as it is loaded based on the width and height of the screen and other UI elements on the page. A bit extreme, perhaps, but necessary to achieve an excellect user experience in the context of a very limited UI framework (albeit one of the best available for mobile devices!).
3 comments:
I think you mis-stated four things in this blog entry:
1. You made it look like we have a one-fits-all solution which we try to preserve at any cost. Your implication is not close to being true. We do a bunch of work to accommodate various browsers. Just to quote an example: We use Openwave’s MIME support to more efficiently transfer all graphics to users phone when they use WL Mail (all the icons download in one chunk, instead of multiple roundtrips. This speeds the download up on the newest Openwave browsers significantly). We have code that does special things for Symbian browsers, pIE browsers, Openwave 6 browsers, Openwave 7 browsers, AU browsers, iMode browsers and I could go on and on and on.
2. Everything is a tradeoff. For instance, in my blog entry I talked about a tradeoff that we’ve made, which causes a fairly minimal extra truncation of subject lines in the inbox view and which is a non-trivial problem to fix. Knowing that every project has a limited timeline and resources to ship, would you rather see “Party at my place tonight” rather than “Party at my place t... “ in the inbox view when you still see the full subject line when you open the message, or would you rather be able to for instance search contacts in your address book ? If our truncation prevented you from identifying what an email is about or who it’s from I would be completely worried. However, the 18 characters (or more) that we usually display are enough to provide you the necessary context to decide whether you want to open the email or not.
3. The argument that we had over the weekend was actually more about overall “usability” than supporting some devices. Since we spent close to an hour talking about it, summarizing it here wouldn’t give it justice ;).
4. Your subject line implies that the early adopters are all running the same device that you are, which is not close to being true. I would say that all mobile browse users are early adopters (maybe with the exception of users in some countries in Asia).
I <3 our exchanges. ;-)
Hello mate niice post
Post a Comment