Pixel-perfect Android web UIs(designbycode.tumblr.com)
designbycode.tumblr.com
Pixel-perfect Android web UIs
http://designbycode.tumblr.com/post/1127120282/pixel-perfect-android-web-ui
2 comments
This doesn't apply to all cases, but in the example given... why are you using images at all? The button style could easily be created using CSS3 and allow you to sidestep all this inconvenience.
I believe rounded corners do not render nicely with CSS3 on Android's implementation of WebKit. At least on my device, if you create rounded corner buttons using CSS3, they end up looking jagged in the browser.
Android's WebKit implementation lacks anti-aliasing for border radius prior to 3.x.
I'm going to be honest and say that as a developer my policy toward Android web users is similar to the one I have for Internet Explorer users. It goes something like, "Eh, they're used to the web looking shitty."
This is all barring those specific users and/or cases being called out in my site requirements documentation, of course...
This is all barring those specific users and/or cases being called out in my site requirements documentation, of course...
Well, that's a shame for you. It's really not difficult (when compared to IE <=7 compatibility) to ensure that the site looks great on phones that ~50% of smartphone users own.
Yes, 50% of users, but from various posts with statistics of actual web use, it iOS is still heavily favored. Same can be said about actual app purchases. iOS users seem to use the smartphone more than Android, at least for now.
I suppose the question is how you have defined "heavily" or "favored," or where you get your data at all.
Mobile browser statistics from Oct. 2010 through Oct. 2011: http://gs.statcounter.com/#mobile_browser-ww-monthly-201010-...
And mobile OSs: http://gs.statcounter.com/#mobile_os-ww-monthly-201010-20111...
Mobile browser statistics from Oct. 2010 through Oct. 2011: http://gs.statcounter.com/#mobile_browser-ww-monthly-201010-...
And mobile OSs: http://gs.statcounter.com/#mobile_os-ww-monthly-201010-20111...
I work for isohunt.com, we get ~4 million visits a day and Android is at 44% while iOS is at 43% with Android growing ~1% each month. What's important is the visitors to your site, are their using more iOS or more Android or are they both at the same level more or less?
As a non-smartphone user, I don't get it: why would the web when on Android look shitty (or shittier than iOS)? They even use the same engine, shouldn't they be very similar by definition?
As a mobile app developer who has several Android phones, and several iOS devices, I can verify that the Web does in fact look the same on Android devices as it does on iOS.
Except when the page uses Flash, of course, at which point it looks better on an Android 2.2 device, since then I can at least see it. Not that I think Flash should ever be used to put up a normal web site, but it's going to be a while before we get rid of Flash from the web. If it ever happens. Some sites from the '90s are still up, complete with heavy use of the "blink" tag, after all...
And to be fair, the zoom pinch "feels" better on iOS than on some Android devices, probably because their touch screen works a bit better than some older Android touch screens. Apple's hardware quality control IS good for something.
Except when the page uses Flash, of course, at which point it looks better on an Android 2.2 device, since then I can at least see it. Not that I think Flash should ever be used to put up a normal web site, but it's going to be a while before we get rid of Flash from the web. If it ever happens. Some sites from the '90s are still up, complete with heavy use of the "blink" tag, after all...
And to be fair, the zoom pinch "feels" better on iOS than on some Android devices, probably because their touch screen works a bit better than some older Android touch screens. Apple's hardware quality control IS good for something.
As mentioned above, prior to 3.x border-radius was visually broken.
Hmm...on my 2.1 test phone, I just rendered this page:
http://www.red-team-design.com/wp-content/uploads/2011/09/aw...
here:
http://imgur.com/FDsdZ
and here:
http://imgur.com/WoMOf
It looks substantially similar on my 2.3.3 phone, too.
I see that when it's small, it's messed up. Bummer. I guess I wait for >=3.x to be the dominant platform before using CSS for my WebView buttons. :(
http://www.red-team-design.com/wp-content/uploads/2011/09/aw...
here:
http://imgur.com/FDsdZ
and here:
http://imgur.com/WoMOf
It looks substantially similar on my 2.3.3 phone, too.
I see that when it's small, it's messed up. Bummer. I guess I wait for >=3.x to be the dominant platform before using CSS for my WebView buttons. :(
The Android browser has a couple of limitations compared with Mobile Safari: no hardware acceleration (pre-Honeycomb) and no overflow scrolling.
The first simply means lots of lag navigating around pages with many elements, the second really pisses a lot of people off: http://code.google.com/p/android/issues/detail?id=2118
The first simply means lots of lag navigating around pages with many elements, the second really pisses a lot of people off: http://code.google.com/p/android/issues/detail?id=2118
In this particular case there are issues like the lack of anti-aliasing for border-radius and hardware acceleration prior to 3.x.
Also while this isn't strictly the same thing, there's a lot more to the browser than just the way the DOM is rendered. The way many of the different browser APIs behave between implementations is drastically different. Off the top of my head orientationchange events, xhr with app cache, (replace|push)State, touch events, and the list goes on.
Also while this isn't strictly the same thing, there's a lot more to the browser than just the way the DOM is rendered. The way many of the different browser APIs behave between implementations is drastically different. Off the top of my head orientationchange events, xhr with app cache, (replace|push)State, touch events, and the list goes on.