Hacker News Reader

Comment by buff-a | Hacker News Reader

"Sampling of UI elements from Android, iOS and Windows Phone 7." should read "Sample of UI elements from one specific version of Android, with one specific theme which is likely to be completely different from any other version of Android, iOS and Windows Phone".

Basically your choices are:

a) don't do any styling or branding at all and allow the users/carriers/manufacturers theme to do its thing, or

b) make an app that looks nice and has branding, or

c) realize you're spending too much effort try to make a nice UX for a fragmented platform whose users don't buy things anyway, and switch to a platform that does.

Ok, that last one was a little bitchy. Thing is, of the three UI styles shown in the article, does an app like Path or Facebook use any of them? (Yes, I know facebook is totally borked on iOS, but it looks nice at least!)

View on HN

FWIW, with Android 4 you should always be able to get the "base android" theme by specifying it. It will probably clash with the carrier/manufacturer's own theme, but it'll work and be consistent.

And b is a nice option, but freaking hard to pull off correctly (even more so in — as you note — a pretty fragmented platform). Tapbots does that very nicely on iOS (they've built their own "Bots" aesthetic and conventions — such as robotic sounds and drawers opening when selecting "list" items — and use that consistently in their own applications), but these guys are completely insane.

> It will probably clash with the carrier/manufacturer's own theme, but it'll work and be consistent.

This isn't how themes work in Android. When manufacturers make a theme for their custom UI (TouchWiz, MotoBlur, etc.) they often override the base assets for certain UI elements like Buttons, ListViews, and TabHosts. The end result was that your app would inherit those styles if you used those widgets without changing their look at all.

With ICS, Theme.Holo will always be available without any of the base assets overridden, which means if you target that theme or use that theme as a base for customizations, your app will not inherit those elements that the manufacturer may have overridden for their custom UI theme. This is what the change that ICS brought in regards to this issue, by having an unspoiled copy of Theme.Holo always available.

I don't see how you can assert that "this isn't how themes work in Android", nothing you stated conflicts with what you quoted.

Clash != conflict. When your application uses an unmodified theme.holo, it may (and likely will) look "out of place" in a heavily customized manufacturer theme.

> When your application uses an unmodified theme.holo, it may (and likely will) look "out of place" in a heavily customized manufacturer theme.

Your app would only look out of place in the sense that your app has a different design and UI compared to other apps using the manufacturer theme. I don't really consider that an issue as it is common to have apps use different themes and styles for UI widgets. The important point is that within your own app, you can enforce a theme that hasn't been tinkered with by the app manufacturer, giving you a stable theme to work with or modify as you write your app.

As an example of this, recent versions of the Motorola theme have altered ListViews such that any empty space after the last list item in the view uses their custom off-white background and ignores what background you may have set on the ListView itself. For me, this is a very annoying, inconsistent change that clashes with the design of some apps, so I would target Theme.Holo to make sure that I am working with the standard ListView theme and my modifications work as I expect them.

This is the great power of this change for ICS, as now I can opt-out of carrier customizations and stop having specific work arounds and hacks for some devices to avoid their custom theme from the manufacturer.

> Your app would only look out of place in the sense that your app has a different design and UI compared to other apps using the manufacturer theme.

Well yes, that's kinda what "looking out of place" means, and the point of themes is originally to have a consistent look and feel even when that l&f is customized no?

> I don't really consider that an issue as it is common to have apps use different themes and styles for UI widgets.

Stop me if I'm wrong, but isn't fixing this issue the whole bloody point of TFA?

> The important point is that within your own app, you can enforce a theme that hasn't been tinkered with by the app manufacturer, giving you a stable theme to work with or modify as you write your app.

1. as I noted, and 2. as I also noted this is at the cost of risking that your application clash with the customized vendor theme.

> This is the great power of this change for ICS, as now I can opt-out of carrier customizations and stop having specific work arounds and hacks for some devices to avoid their custom theme from the manufacturer.

From my having written this in response to buff-a's comment, you could have inferred I am aware of it.

The whole point of the design guidelines is to help solve these problems.

Should Google do nothing and let the fragmentation fester?

> The whole point of the design guidelines is to help solve these problems.

You can't really solve these problems when there is no assurance that the theme (and its conventions) on your user's phone will match those of these guides though.

That's definitely an advantage of iOS and WP.

Reply on news.ycombinator.com