One important point is how much misinformation there is out there over fragmentation - a lot of it written by people who don't know (and usually don't care to know) much about the actual issues.
One common meme is the Multiple Resolutions Problem - you know, the onerous problem a developer faces when he has to support both HVGA, QVGA and WVGA resolutions. Except, if you actually do write an app that works well across all those, you find out that managing multiple resources for multiple resolutions is trivial, and that correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios.
That is not to say there aren't actual issues - one pain point comes up if you wish to target 1.5 so you can get the widest distribution possible, but are forced to use 1.6 as your target during development.
But just to illustrate my point, try a google search for the fictitious resolution "fragmentation" problem, then try one for the real 1.5 vs 1.6 problem.
correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios.
Slightly different sizes, yeah. But the problem for some people / designs, and ultimately for end-users, is that it makes super-designed apps like you see on the iPhone more difficult to make.
Not that that should prevent people from programming for / using Android. I personally plan to code a bit for it. But high degrees of polish are significantly more difficult than for a single screen size, and the iPhone has pretty much demonstrated that it does in fact matter to the average user.
Maybe it's my web-dev background, but Android reminds me a lot of that. When designing a web-app, styling it using CSS is such a fundamental part of it, that it shouldn't be considered a different activity. No one would seriously put up a webapp that relied on the browser's native rendering of lists, input boxes etc.
With the iPhone you do get a lot of that polish for free, whereas with Android the basics won't get you as far. How much more difficult is it? Depends, it's somewhere between an iPhone and a webapp. IIRC, I probably dedicated about 1 week on my last project to this kind of work, which was around 10 weeks.
Another thing to consider is how much of that polish is simply due to timing - many iPhone apps have been out there much longer and until it's recent stellar rise, Android was seen as a second-rate platform with far fewer resources devoted to it (for example, the Facebook apps).
I see a ridiculous amount of fixed-width webpages, which would imply that using even fairly simple, standard components in a fluid way is far more difficult than many developers are interested in doing. Many, not all by any means.
Ask an average phone user if they think of the UI as a webpage. Given that nearly all are menu / button based, not links-in-content based, I'd imagine nearly all will say "no". The expectations differ, so their perceptions of the same app differ.
Ultimately, which do you want: ubiquitous Android, or geek-only Android? And guess which the average users (and thus hardware makers) want. The push will be to make it ubiquitous, thus successful apps must compete with the iPhone directly in usability and "feel", or people will always feel they've got a second-rate device / application, which is degrading to the whole ecosystem.
(for clarification: different devices on the hardware don't bother me for programming - use them or don't, it's your app. The many screen sizes however imply fluid layouts, or huge amounts of fixed + minor fluidity... and clearly nobody wants to make those if they've got careful design (see: webpages). In time with a good library or ten, this could definitely change, as would more focus on design for Android apps. But until that happens, it's fairly damaging to highly-polished apps, which tend to make money more effectively.)
martythemaniak said Android UI development is similar to doing HTML + CSS, he didn't say it's the same. The Android UI layouts are significantly less broken than CSS, even before you include the clusterfuck that is varying browsers support for CSS.
If you've ever tried doing a UI Layout for Android, you'll find it's actually pretty damn easy to support multiple resolutions. If you're actually interested, here's the canonical resource on supporting different screen in Android: http://developer.android.com/guide/practices/screens_support...
BTW dealing with multiple resolutions is a problem that's rapidly heading to the Apple ecosystem. The iPad is 1024 × 768, the current iPhone is 320×480, the next iphone is rumored to be some multiple of the current iPhone resolution, etc.
Thanks for the link, hadn't seen anything for Android yet. But it does nothing to alleviate the problem. Re-post of my other comment:
You still need to make a ton of resolution-specific images if you want the sharpest possible image, which - again - matters for perceived value. And you're royally screwed if you do pixel-art instead of something easily resized.
The issue here isn't for all applications, it's for highly styled applications, which are kicking ass lately and are important for perceived value of a device. Resolution independence and fluid-ish layouts do indeed make basic UI extremely easy. But basic UI evidently can't compete equally with a more stylized UI, as the iPhone shows pretty clearly.
But basic UI evidently can't compete equally with a more stylized UI, as the iPhone shows pretty clearly
Support that. I can name several apps on my iPhone that are hardly high-style, yet useful and well received (Quickoffice, iFitness, Yelp!... just to name 3 on my home screen).
Larger than this. This is something that vector graphics solves extremely well. You want really nice images at multiple resolutions? Illustrator is your friend.
Highly styled apps have taken a while to arrive on Android, but they definitely are arriving. The new Twitter app for Android, for example, is might nice looking. (here's an article about it: http://blog.twitter.com/2010/04/twitter-for-android-robots-l... , and another here: http://android-developers.blogspot.com/2010/05/twitter-for-a.... One thing not readily apparent from the screenshots is the way the whole app is animated. The little bird and cloud backgrounds are animated and move on almost every screen.
Top 20 selling apps in the Apple store[1]. A quick perusal will convince most people. I didn't check all of them, but I saw ONE which used standard display components at all in the screenshots (the guitar one), and it only does so for setting preferences.
This is hardly a problem that's unique to Android. Like I mentioned before, the i* platform already has 2 resolutions to support and almost certainly will have a 3rd shortly. If the i* platform is offering a better long term solution than what the Android API's currently offer, I'd love to see a link to more information about it.
The whole "fragmentation" thing, at least in terms of API's and developer issues, is more of a talking point than a reality.
If you consider rotation, the iPhone currently has 4 resolutions and will soon have 6. There's also the expanded green status bar during calls, a red one during voice recording, and another color for background VoIP apps in 4.0 -- so it'll really be 12 resolutions.
The real difference is that with iPOS, Apple doesn't expect developers to automatically handle new device resolutions, and no developer expects to not be informed of new resolutions. Android developers are expected to use fluid layouts, and don't expect to be able to keep up with the release of new and customized devices by a bevy of semi-incompetent manufacturers.
Widescreen monitors killed the fluid layout. It's extremely difficult for a website to look good at both 800px wide (typical netbook) and 2560px wide (27" imac).
Very true, though not restricting me to 800px wide would be nice sometimes. Say, cap it between 800 and 1024 or a bit higher. Too wide is too hard to read anyway.
Given the amount of reading I tend to do, and the infinite-scrollability of webpages, I'm often a portrait-mode fan. It just sucks when you need a bunch of applications open for comparison / parallel development.
edit: hm. widescreen / horizontal Android devices exist (ODROID). So we're back to the same issue...
1. You rather missed my point. I brought up web development from a developer's perspective, not a user's perspective.
2. Take the typical case right now - accommodating the Nexus One and a typical large-screen HVGA device - the difference would be about 0.5-0.8cm in extra vertical space. Coming up with a design to work on both screens isn't going to ruin your application, neither is it so exceptionally hard as to not be worth it. As you've demonstrated, its a very popular piece of Android FUD right now.
1) which is why I pointed out the relative lack of fluid layouts on the web. Developers not doing what's best for users, because it's a pain. Granted, I spent more time in user-land.
2) so if you've got a background image which you want a button to appear over, you either need bottom buffer space on one, and is weighted off the bottom, or it gets cut off on the other. Or you need two images and two layouts. Same issue, and this is for highly styled apps, not for basic stuff (which is legitimately easy).
As to the resolution independence, you still need to make a ton of resolution-specific images if you want the sharpest possible image, which - again - matters for perceived value. And you're royally screwed if you do pixel-art instead of something easily resized.
re:1 - No. If the page is primarily content based rather than app based then a fixed width design may well be the best thing for the user; the readability of a design is heavily effected by the interrelationship between factors such as type size, line length, line height etc. Changing the line length without effecting any other aspect of the design can easily have an adverse effect on readability. If your user's primary task is reading, you have just done your users a disservice.
While some fixed width designs are because the designer went nuts with the rasters and making it scale is hard, many designers are doing it for good reason.
1) It's far more of a pain on the web, which unlike Android wasn't designed to easily deal with this issue from the get-go.
2) Having different resolution renderings of 3D images or tile/patterned images is not a problem. Think of Bejeweled on the iPhone (it is a stylish app that uses a bg image as per your example) - minor cutoffs (ie showing more sky) and different resolutions would not be a big issue.
Given the new iPhone 4G (2x the resolution) and the iPad (different resolution and different screen size) these are issues iPlatform developers face too, and they'll get around them the same way.
Re: the Multiple Resolutions Problem, it's probably less of an issue if you're writing a utility app. But for games, which frequently make use of resolution-dependent assets, it is far from trivial or fictitious. A larger developer might be able to eat the cost of maintaining multiple sets of assets, but smaller developers frequently can't. Nor can they typically afford to own a comprehensive set of devices to test on, which is necessary if you're trying to figure out things like how many sprites or particles you can display at a given resolution and framerate.
The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets.
Incidentally, this is what iPhone developers will have to start doing this summer. The new iPhone's screen is 2x the resolution. Assuming Apple wants to keep the iPhone forward-compatible and run OS3-based apps, that means image resources will be upscaled by the phone and look fuzzy, or developers will have to update their apps with higher-res assets.
As for framerates, you'll never get away from dealing with different hardware, no matter if you do Android, Web, Desktop or iPhone development. I have a first-gen iPhone and you have no clue how frustrating (ie slow) it is running many apps on it.
The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets.
This technique doesn't work for pixel art, which can only be scaled up by whole number values. In certain cases where a display's resolution isn't a whole number multiple of the base resolution, you can get away with slightly shrinking or extending the viewable area. But 480x320 to 800x480 is a particularly inconvenient shift, as assets cannot be scaled up without incurring a large loss in viewable area, and they cannot be kept the same without requiring a large increase in viewable area.
Incidentally, this is what iPhone developers will have to start doing this summer. The new iPhone's screen is 2x the resolution. Assuming Apple wants to keep the iPhone forward-compatible and run OS3-based apps, that means image resources will be upscaled by the phone and look fuzzy, or developers will have to update their apps with higher-res assets.
Not true at all. It would only look fuzzy if the screen size were significantly larger. But in fact the screen size is roughly the same, only with a much higher PPI. Because the new resolution is a whole number multiple of the old, all apps can be trivially scaled with 2X nearest-neighbor scaling and look exactly the same as they would on a 480x320 screen.
As for framerates, you'll never get away from dealing with different hardware, no matter if you do Android, Web, Desktop or iPhone development. I have a first-gen iPhone and you have no clue how frustrating (ie slow) it is running many apps on it.
I actually do have a first-gen iPhone. In my experience, it hasn't been that slow for the majority of apps I want to use. But that's sort of irrelevant. As far as a developer is concerned, they only need to own two devices (three after the new iPhone is released) to capture the significant variations in hardware: a first-gen or 3G iPhone, and a 3GS. (Alternatively, and more cheaply, a first-gen and third-gen iPod touch, if you have no need for camera, GPS, etc.)
And it's true that you can never get away from dealing with different hardware, but the whole point is how much different hardware you have to deal with. Apple has been very careful about keeping that to a minimum while satisfying demand for better hardware.
they look fuzzy compared to native resolution apps.
apple has also, by denying the problem, failed to provide good APIs for multiresolution. android as faced and addressed the problem from the get-go and has a better solution.
Sorry, but how on earth do you know pre-iPhone HD apps look fuzzy on the iPhone HD?
iPhone apps on the iPad look fuzzy because (A) it does not use nearest-neighbor scaling, and (B) the screen is way larger, with a much lower PPI. It would be surprising if the iPhone HD doesn't use nearest-neighbor scaling.
And Apple hasn't denied a problem because it hasn't created one.
To me the key point of this post was:"And in the long term, as the mobile industry gets more accustomed to the idea of upgradeable phone software, more and more devices will be be upgraded."
Google is doing a fantastic job with Android, it's just that the carriers and OEMs are dragging their feet at properly supplying their handsets with updates. To make matters worse they continue to fiddle with the Android system (see HTC's Sense UI) for no apparent benefit to the consumer other than to make their phone 'stand out'.
I'm currently very angry with HTC and T-Mobile for their last century attitude to mobile devices. It's ridiculous that they have promised to upgrade my Hero to 2.1 since March and still nothing - also the last firmware update also conveniently disabled all possibility to root the phone. Say what you want about the iPhone, it is at least supplied with updates for a reasonable amount of time (~3 years?) and older models don't get their update months late.
I agree that's the key part. However, perhaps the reason upgrades are so slow is that Google is moving too fast for OEMs. Their profit margin on these Android phones is lower because they're more powerful and costly than the typical Symbian phone. No other phones (Blackberry, Sidekick) require them to be as involved in updating software. Apple ships iPhone OS updates via iTunes, not AT&T or Samsung.
I think we'll see a fundamental testing of the limits of Android fragmentation this year as OEMs have to support so many different phones, starting from various points on 2.x. At what point will they cut off a phone as too old for updates? Will it be similar to Windows where you have an extended support period with only security fixes? Who patches security flaws in your browser on a G1 running 1.6 in 2011? HTC?
Why? Sense seems to work just fine for me. Every app I've downloaded (I've tried ~100 or so) works great. Sense integrates well, and seems to work perfectly with any integration points it has with 3rd party apps. It really seems to be a thin layer that really dresses up (in my opinion) the overall experience.
thats the problem though, traditionally most of the time phones don't get major upgrades in their software. A few firmware fixes here and there maybe, but rarely do they get major updates like android. What benefit do HTC stand to gain in upgrading your old device to new versions of Android?
It may be a symptom of Googles quick development cycles, but its still a problem. It may be one Google cannot solve but this blog post to me didnt address that issue, rather it said this is what we think fragmentation is, look at all the things we do to fix it. But in reality, for me, the fragmentation is mostly about the varying versions of android around.
Perhaps if HTC were to charge you for the upgrade, in order for them to prioritize the development of it? Would you pay $50 for the upgrade if it meant it would happen in the next month as opposed to ages down the track?
Nice to have some actual information in one of these posts. I'd be interested to hear the experience of android app developers who have had to deal with different phone models. Android's biggest marketing challenge is the disinformation.
I'll give my opinion as a designer. I want to be able to have control on what my user will be. That's why Pantones exists in print. That's why designers love spending hours to polish their iPhone apps, because they want them pixel-perfect. That's why I curse every time a client of mine tells me he can't see the site well in IE6. Will I start developing for Android as well? Of course, I'd be stupid not to, but I hate the fact I know the UX won't as near as the one iPhone users of the same app will have.
iPhone devices will see fragmentation soon too. iPad has a different resolution, the next iPhone will too. The problems you see with Android today are just problems that Apple is holding on but that will have to be faced in the future - it won't be the same 320x480 device anymore.
The solution - proper placement, scaling, different layout flow methods - have been around for ages, and it's up to developers to employ them.
And because Android devs had to deal with them already, I can't wait to see the barrage of shit that will happen when devs unprepared for it have to deal with the new iPhone resolutions.
Well, it'll be 640x960 which is a nice integer multiple of the current iPhone resolution, allowing older apps to remain visibly unchanged without and code changes. As for the iPad, it's distinguished from the iPhone and iPod touch not by its resolution but by its size, necessitating new UI for that reason alone. I expect Apple to continue along these lines, requiring UI designs tailored to a few physical screen sizes, using integer multiples of existing resolutions to insulate developers from these changes.
No-one seems to mention the downside of this approach. The iPhone is going to jump from what has always been an okay resolution but is now becoming low resolution, to what is going to be a high resolution but not for very long because very similar phone resolutions have been available for about a year now. Newer devices will continually increase the resolutions available but Apple can't improve on theirs until they double height/width, and quadruple pixels again.
Similarly the iPad doesn't have steller resolution, and unless they want the dreaded fragmentation, they'll not be able to do anything about it until they can double/quadruple the screen from what it is now.
By locking themselves into these resolutions they wander far from the display screen sweet-spot either shipping cheap, low-res displays or expensive, high-res displays. They can't even go to triple current resolution, as that would still look grubby on the middle device without a separate image which defeats the point.
And, apart from certain types of apps, it doesn't buy them anything. When displaying video or images, no difference as it's just scale to fit regardless. When displaying text in books or websites, they take the quality hit whenever they're not at the top of the resolution cycle. In return they get app UIs that are basically hand-drawn pictures and grid-fitted pixel art.
It's an engineering trade-off, and for my particular uses, it doesn't really pay off.
One common meme is the Multiple Resolutions Problem - you know, the onerous problem a developer faces when he has to support both HVGA, QVGA and WVGA resolutions. Except, if you actually do write an app that works well across all those, you find out that managing multiple resources for multiple resolutions is trivial, and that correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios.
That is not to say there aren't actual issues - one pain point comes up if you wish to target 1.5 so you can get the widest distribution possible, but are forced to use 1.6 as your target during development.
But just to illustrate my point, try a google search for the fictitious resolution "fragmentation" problem, then try one for the real 1.5 vs 1.6 problem.