Thanks for your feedback. That screenshot is pretty old; iTunes Preview has newer ones which reflect our newer, more attractive refresh. As always, we are hard at work at awesome new stuff.
That's what I thought, too. I don't think I've ever seen anyone say that it's flat out impossible to make something look good on Android, just a bit more difficult than iOS because the Android SDK doesn't have the UI/UX helper methods that the iOS does.
Actually I'd say the difference is MacOS/OSX/iOS has a culture of ultra-criticism of UI decisions, meaning developers for other platforms don't have the same pressure to produce fantastic interfaces (just read Pierre Igot or Gruber's early works). Of course this isn't universal - there are many iOS apps with terrible UIs. But the overriding principle remains.
Apple also provides very detailed human interface guidelines for all their OSes. They are all more than 100 pages long, and describe how every single UI element should act and what the user should expect. When designing a UI using Apple's provided graphical tools, it actually guides the programmer to follow those guidelines, in terms of button sizes, spacing, etc. Apple cares about UI/UX, and it trickles down.
Google should at the very least keep the same aspect ratio when allowing manufacturers to use other resolutions.
They currently allow (split by 10 for better comparison):
320:240 (13.3:10), 480x320 (15:10 ratio), 800x480 (16.6:10), 854x480 (17.7:10/16:9), 960x540 (17.7:10), and then 1280x800 on tablets where 48 of the pixels are for the bottom bar, so it's more like 1280x732 (17.4:10).
I would be easier to do "pixel perfect" design if Google would at least not use all these resolutions that have little to do with each other. It goes to show that Google doesn't put much thought into these kind of design details.
This is the kind of "standardization" I'd like to see Google bring to Android. Would it be that bad to deny a manufacturer the use of a 854x480 resolution over a 800x480 one? or whatever they choose to be the standard? I don't think so, but they don't seem to care much about it.
The 960x540 resolution was probably unnecessary, too, considering we're about to see 1280x720 resolutions coming into market just 6 months later. If a manufacturer decides to make a 1366x768 display later, should they allow them to do it? They shouldn't because the improvement is marginal and developers have to support one more resolution with little benefit, but they probably will allow it.
It goes to show that Google doesn't put much thought into these kind of design details.
Maybe Google thinks, as I do, that designers should be able to make their stuff look good in a variety of resolutions. Desktop/laptop computers have a range of resolutions and aspect ratios, but people have been making UIs look good on them for years.
The problem is that desktop computing is based on mouse interaction, and the precision unit is the pixel. On touch-based devices, it is the human finger. The actual physical dimension of the buttons and other UI elements, including spacing, start to matter a lot more. When you allow for a huge range of resolutions all at different physical dimensions, it's nearly impossible to craft a good UI for all of them. It's going to be a lot of work (too much for most devs) to verify that their flexible layout is going to work from 320x240 to 960x540 and remain usable and readable. Because it's so hard to craft the perfect experience for all, most just don't bother and just settle for good enough. In the end, there are huge benefits to the way Apple is doing things from a UX perspective.
There are two things that make it less of an issue with Desktops/Laptops.
1. There aren't really that many native ratios. Realistically, you're looking at 4:3 for CRT's, 5:4 for non-widescreen LCD's, and 16:9 or 16:10 for widescreen LCD's. So that's not as bad when creating a full-screen application, because you can also letterbox the 16:10 to 16:9 for full 1080p video.
At this point, if I were a developer, I wouldn't even care about 4:3 resolutions, and just have 5:4 and 16:9.
2. Desktops and laptops, in general, have a lot more pixels to deal with, and are usually farther away from the user's face, so there is a bit more leeway when scaling your UI.
There was time, when desktops had 640x480, 800x600 and 1024x768 (heck, the currently most sold 1366x768 is not that different), which is similar to today's smartphones. They had also much bigger diagonal/lower dpi, so there was actually less leeway and every pixel counted.
All of which were 4:3 ratios. 1366x768 is also 16:9.
My point is that it's easier to scale any given UI when you have known pixel ratios. While the actual number of pixels may be different, it's easier to scale a UI from 640x480 to 800x600 than to scale 640x480 to 1600x1024.
OK. There were also 640x400, 640x350 (EGA) and 1280x1024. Under Windows, also "Small fonts" and "Large fonts", which changed size of controls, but not bitmaps.
Each of these options gives you something. Focusing on single resolution (or fixed-number multiples) is short signed, almost like basing your's OS binary API on soon-to-be obsolete and unstable C++ ABI (I'm taking shots at BeOS - they took the easy solution at the beginning and what problems it caused).
Especially when the system has the tools to handle the differences.
Android being open-source, there's probably an expectation from Google for the community to provide a range of solutions to a 'boring/inconsistent/shit UI' problem, be it through providing boilerplate code or UI component libraries or whatever.
I'm going to say though that if anything is at fault, it's not necessarily the learning curve but the base assumption of expert knowledge applied to every bit of documentation Google produces.
For a purely technical piece of writing they'd win many awards, because they can get down to the nitty gritty for sure. To the guy who's new to it all who wants somewhere to start, he's fucked. It's documentation for people who already understand it (personal experience: the C2DM doc, maps API, their PHP library that makes it harder to use their APIs than rolling your own code, etc.).
So thanks to that those fabled UI solutions turn up in the form of PhoneGap, jQuery Mobile, Sencha Touch, etc. All of which abstract the concept of app development to merely be a case of designing a website for a small screen. With HTML and JS and CSS. (Of course the other reason is platform agnosticism but application homogeneity is another thread entirely.)
And, thanks to the point raised in the article ('Android UI design is easier coz it's XML so you can do it programmatically!'), the people who do know how to create an app are the developers who may or may not be very good at working the UX side of things and may settle for the utilitarian solution.
> Android UI design is easier coz it's XML so you can do it programmatically!
That is absolutely not the point raised in the article. XML based declarative UIs help to keep your view code separate from the application's logic allowing for faster iterations. I don't think anyone manipulates XML views in code except in corner cases.
The simplest way to get a big picture idea about Android's XML based UI is to think of them as HTML+CSS with the addition of good layout managers.
A lot of Android Apps look nasty because they were created by individuals with the intent to solve a problem, and that problem is rarely - that Android Apps look bad.
Then, when they have solved the problem, why not put it in the Market.
Any Android App can look great. It's just a matter of taking the time to make it so.
I couldn't detect a value judgment either way from your comment, but I agree, and I think that's a feature, not a bug. I've got plenty of utility apps on my Android phone that I interact with very rarely to change some setting on the phone or run some background service. I'm glad that the developer of each of these didn't feel the need to divert resources to making a beautiful UI before releasing or improving the functionality.
Not to say I don't appreciate beautiful UI design, but I think there's room for beautiful apps and ugly but functional apps.
If you use a non-standard UI, your app does not look good. Nobody wants to learn a new interaction paradigm for every application they touch; that simply doesn't scale.
Yeah, and its a pain in the arse. While native widgets aren't perfect, I'm much happier to deal with them instead of a reimplementation of one. Even when the web guy tries, they never work exactly the same, and they hardly ever try. The browser is a box where users have to throw away all the assumptions they have about the way controls behave because everything is done wildly different everywhere.
Users are forced to return to figuring everything out as they go, and then start over again at square for the next website. Visual cues are frequently sacrificed for the visual mess someone called a "design". For people highly familiar with native widgets, they just can't navigate around as easily in a webapp as they can in a first-class gui citizen. Not only because everything is different, but because the extended functionality that comes baked into real toolkits just isn't present in the web reimplementation. Things like the history api are even further eroding what assumptions can be made about gui behavior on the web.
I think the belief that Android apps have been less than well designed grew from earlier generations of Android. That current versions have built better UI tool sets, that more UI/UX level testing packages are becoming available, and builds using web technologies have made some apps equal to the iOS levels of design is clear.
However, a purely native approach (without titanium or phonegap for example) still has many issues in developing well structured UI.
It is clear however, that BUMP's application, while better than their previous design, does lack something. Android design is not particularly easy and I personally think that the various screens, disparate versions of the OS, and capabilities of the phones make development that much more complex. In a very real sense we need UI testing that automates this as much as possible. It really is too much work.
Still I think that there are UI frameworks coming out for Android that will alleviate all this complexity and allow us to build consistently well designed apps. Just not right now.
Yes, many Android apps looks bad (a lot of them appeared in the beginning of Android, made by hackers that dont care about design or poorly ported from other platforms) but this is not the case anymore.
Add to that Foursquare, GroupMe, Spotify. Maybe it's not fair to include Google apps, but YouTube, GMail, and the current incarnation of the Market app are great.
Which ones in particular do you feel are bad? Most of everything is crap, and there's certainly no lack of it in the app store. In my experience the "top-tier" apps tend to look good on both platforms, often identically so.
So what iOS apps in your experience have "ugly" Android equivalents?
I haven't compared apps with their iOS equivalents, but facebook for android isn't great. The android market app itself is bad.
Honestly, now that I think of it, I don't know if I would stand by my initial claim that they actually look bad. I may just have that impression because Android's performance is (again, in my opinion) very clunky and inconsistent. It may be that the general bad user experience I've had with Android phones has tainted my entire view of the ecosystem.
Apple. They spent the time to "get it right" with iOS, and when Android came along they had to settle for second best in most areas to avoid looking like an iOS clone.
I agree with you mostly. Android is slooowly catching up in the looks department, but Apple is still way ahead. My first impression of Android was that they desperately copied Apple UI, but failed to make it as good either because of lack of skill, care or not wanting to look like an iPhone.
If you want examples of how well Android can look try the MIUI rom. These guys built mostly everything from scratch to create a pleasant, unified look (contacts, phone, messaging, browser, music player etc. and they all are best Android apps I've seen). Sadly, it does look much like what would Apple do.
Disclaimer: not a fanboy, I have both, iOS and Android powered devices and I actually develop on them both.
There are three painfully obvious reasons Android apps do not look as good as iOS apps. iOS has UIKit and Android has fragmentation along with a myriad of devices with different resolutions.
1. UIKit - Apple made it easy for developers to implement consistent navigation, views, and transitions. Android Ice Cream Sandwich is providing a new UI library which will bring this much needed iOS advantage to Android. Is it possible to mimic UIKit on the current Android devices? Yes, but it's a pain in the ass and not practical for most developers on a deadline.
2. Fragmentation - Device Android version lock has caused problems with development. You are only as strong as your weakest link which unfortunately rings true with some developers who choose to develop on an older version of Android to remain compatible with as many devices as possible. Google has addressed this issue by obtaining agreements from many manufacturers to update their devices on a consistent basis.
3. Screen Resolution - Any web developer will tell you it's much easier to create a beautiful and consistent website if the site is fixed width. This is especially true for mobile development because you dont have to concern yourself with repeating tiles, resolution detection, and adjustable spacing when you know the exact dimensions of the device. There are only 2 iOS resolutions (not counting retina) making it easy to utilize space and perfect the UI in the most efficient way possible. Can it be done on Android? Sure, but without a UIKit to handle many of the little nuances it will yet again be a big pain in the ass and will take up time that the developer does not have.
Consumer apps used to compete on functionality - now everyone can mostly do that part.
Design (both graphic and interaction) is where companies will compete for consumers.
Bump has needed a TON of help in the past and even does tdoay (even with their iphone app, http://www.iwebsnacks.com/wp-content/uploads/2011/02/Bump-2....).
Please - start with a new logo.