3 ms·

"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 them

by buff-a 15y ago

"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!)

Steko 15y ago
The whole point of the design guidelines is to help solve these problems. Should Google do nothing and let the fragmentation fester?
- masklinn 15y ago
  > 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.
masklinn 15y ago
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.
- king_jester 15y ago
  > 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.
  - masklinn 15y ago
    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.
    - king_jester 15y ago
      > 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.

by buff-a 15y ago

Steko 15y ago

The whole point of the design guidelines is to help solve these problems. Should Google do nothing and let the fragmentation fester?

masklinn 15y ago
> 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.

masklinn 15y ago

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.

king_jester 15y ago
> 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.
- masklinn 15y ago
  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.
  - king_jester 15y ago
    > 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.