views:

532

answers:

2

I recently did the Chris Coyier tutorial from the css-tricks.com weblog #38: Basics & Tips on Designing for the iPhone. Needless to say I got very excited and suggested to a guy that I do some code monkey work for that we could now offer iPhone websites to his clients. He said cool, but what about other mobile devices? good question. So what is the low down on designing websites for Android, Blackberry, WindowsMobile, etc? Are people bothering with the other platforms? Thanks.

+9  A: 

Recent Webkit and Opera:

For iPhone Safari, Opera Mobile, and Webkit on Android development are similar (but not identical), and development for those is quite simple.

You can rely on CSS2.1 and JavaScript+DOM (but be careful with UI events). You might get away with serving your regular website with just few changes to stylesheets.

The trick is in serving of these stylesheets. Don't use User-Agent string.

Because some mobile browsers read handheld media, and some insist on screen styles and pretend to have 960px-wide screen (iPhone :/), you'll need to serve mobile stylesheet with both:

<link media="handheld" ...>
<link media="screen and max-device-width:480px" ...>

The latter is CSS3 Media Query – very useful and works with other mobile browsers too (you can use it in stylesheets with @media {}).

Don't rely on :hover or onmouseover because these events don't work on touch screens.

onclick is delayed, mousemove may not work. Custom DHTML widgets (dropdowns, sliders) and drag'n'drop won't work on touchscreens, unless you use Apple's custom touch events.


To test page in Opera Mobile, get some older version of desktop Opera and choose View → Small Screen.

For Opera Mini it's almost the same as for Opera Mobile, except CSS is re-formatted a bit and DHTML is executed on server-side, which doesn't always give results you'd expect. There's simulator available.

Pocket IE:

PIE is not (yet) the same engine as IE on Windows. It's mostly as primitive and buggy as IE4 was, but supports some suprisingly advanced properties like display:table.

It reads both handheld and screen stylesheets at the same time, violating the standard and shooting itself in the foot. If you're going to suppot PIE, then put link to handheld stylesheet last and reverse/override all the rules from screen styles in it.

There is simulator for PIE, but it's split into dozen installers, drivers, middleware, plug-ins, firmware and OS images scattered all over Microsoft's site, and you'll find that most of them are outdated, broken or incompatible with each other. And that's just a warm-up before ActiveSync configuration...

BlackBerry, OpenWave, Blazer, etc.:

Before the BB Storm, it's a nightmare. Only basic HTML works. CSS works on some models, but is primitive and broken. JavaScript works only on some models and it's incredibly slow and lacking (forget about even basic DHTML).

There's free BB simulator availble from RIM. If you're unlucky, it'll launch properly once and then you'll have to completely reinstall it :)

The same thing is with hundreds of other mobile browsers on low-end phones (powered by likes of OpenWave, which has decent simulator) . You'll have to prepare 1-column basic HTML stripped down website for them.

Google Wireless Transcoder

Even if you create nifty (X)HTML optimized for every mobile device out there, users of Google Mobile Search will never see it! Instead, every page will be proxied through "Wireless Transcoder" which brutally chops the code, stripping all stylesheets and scripts (regardless whether browser supports them or not), and even <font>.

The end result is absolutely awful and there is no opt-out for page authors!

If your page is better on low-end devices than Google's automatically stripped version, then AFAIK there's no other way to direct users to the better version than to look for "Google Wireless Transcoder" in User-Agent and display "Please follow 'View in HTML' link below" instead of your pages' content (note: this doesn't block access to content, just directs user to load content directly).

porneL
Outstanding info. Thanks.Makes me kind of conclude that simply coding for the iPhone is almost acceptable as they are offering the best user and programmer experience?
portalpie
But don't limit it to iPhone (it's just as lame as IE-only). There are other browsers as capable as iPhone Safari, and there will be even more of them in near future.
porneL
Some users intentionally use Google's transcoder because their browser doesn't support JavaScript or CSS well and won't render some pages in a readable way otherwise. Others use it because they don't have unlimited data plans and want to reduce their data usage. And others use it because they have low bandwidth connections. Showing no content instead of ugly content is not nice. There's a way for users to opt-out: don't use Google Mobile Search. Besides, Google's transcoder makes it clear to users when it's molesting the page, and it's easy to see the original version for users that want it.
jamesdlin
@jamesdlin: I've meant opt-out for page creator. I wouldn't mind if it was on by default only on sites that aren't mobile friendly. However, Google forces it even if I make page that doesn't require JS/CSS and works in low-end browsers *better* than Google's version, and that's not beneficial to users.
porneL
A: 

So am I correct that there seems to be 3 main players in the mobile browser market excluding browsers that have support for little more than html? The players being Mobile Safari, Opera Mini and The Android Browser which is using webkit anyway.

Are they the main 3 that should be taken into consideration?

What about the viewport? For example, this is what I used on my first little site:

Is the viewport iPhone specific? If so and you were trying to support more than just the iPhone would you have to leave the viewport out? I like the way viewport works.

Thanks

portalpie
On the viewport meta tag. I am now guessing that it would just be ignored by browsers that don't support it?
portalpie