
Don't mimic UI elements from other platforms - tbassetto
http://developer.android.com/design/patterns/pure-android.html
======
ge0rg
"Don't use right-pointing carets on line items" "Avoid them to stay consistent
with the platform and in order to not have the user guess as to what the
meaning of those carets may be."

Instead, let the user guess if an entry is just an entry or opens another
screen full of interesting things.

~~~
demallien
Yup, that line jumped out at me as well.

Another one was complaining about people putting labels on the back button.
Heaven forbid that you should actually inform your users as to what is going
to happen when they press a button who's action depends on context.

I can understand that they don't want people simply copying the interface from
another platform, but complaining when people steal ideas from another
platform when your own platform is deficient? That's just stupid.

~~~
Kudos
There's a built in back button in Android, sticking another one on the
interface looks completely wrong. It is invariably cheap iOS ports or webkit
wrappers tuned for iOS that do this.

~~~
ge0rg
As the guidelines outline, the (physical) _Back_ button has a different
meaning from the _Up_ button in the top left corner of your app.

------
jerfelix
We're designing web apps using jQuery Mobile. We have been using a theme that
looks very much like iOS - with the right pointing carets, for example. I
hadn't really considered that it'll look foreign to the Android user.

Are there toolkits for designing Web apps that automatically switch themes,
based on the User Agent?

It'd be very cool to design it once, and then have the site rendered to look a
little more native, depending on the platform. But maybe that's a dream.

~~~
masklinn
> I hadn't really considered that it'll look foreign to the Android user.

Only to ICS users (if that) since consistency between applications has not
exactly been a forte of Android before ICS (hence TFA). And you'll still
likely end up with issues due to vendor-custom themes (Motoblur, Sense,
TouchWiz) which may very well look nothing like Holo.

> It'd be very cool to design it once, and then have the site rendered to look
> a little more native, depending on the platform. But maybe that's a dream.

It's hard to pull for "native" toolkits to start with (see e.g. wxWidgets or
Qt, they often get close on "look" with a lot of efforts, they usually have
big issues on "feel"), but for web applications? Yeah we're not in the realm
of "hard" anymore but way beyond.

------
Steko
Is that red checkbox from the comparison example actually used anywhere in
iOS?

~~~
falling
Yes, but I don't know whether in the same context as the other checkboxes. The
red one is used when deleting multiple items in a list, for example in Mail.

~~~
masklinn
Not just deleting, they're general-purpose selection, after the mails are
selected you can delete them but also move them (to an other inbox), flag them
or mark them (as read/unread)

------
cmicali
And by "other platforms" we mean iOS.

------
rix0r
> Don't carry over platform-specific icons

Not in the least because they may mean different things!

As far as I can tell, all icons shown side-by-side for the different platforms
perform the same actions, except for the back-arrow.

The Android and Windows icons are for "going back", while the iOS icon shown
there is used for "reply".

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

~~~
masklinn
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
> 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
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
> 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.

~~~
masklinn
> 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.

------
wgx
Of course the reverse of this is that by adopting conventions across
platforms, users may actually get familiar with controls and learn to use them
across devices.

~~~
Symmetry
Wait, how many users do you have that use mostly your app but on multiple
platforms, versus users that use multiple apps but mostly only one platform.
I'm thinking the first case is pretty much non-existent.

~~~
wgx
I was talking in a general context. A typical user has a desktop PC at work,
maybe a laptop, a phone and maybe a tablet. They shouldn't need to learn
different visual UI metaphors across devices. 'Sall I'm saying.

------
fredley
I like how the iOS screenshots are tiny compared to the Android ones. Making
up for much?

~~~
CrazedGeek
I think they're actually right, relatively speaking -- the iPhone 4/4S's
resolution is 960x640, while the Galaxy Nexus's is 1280x720. (Alternatively,
the Galaxy Nexus has a 4.65" screen and the iPhone has a 3.5" screen.) Making
the screenshots the same size would add confusion to UI elements' proper
scaling.

~~~
alttag
Yes, there are _some_ models that have larger screens. Just because there are
models with larger screens doesn't mean "Android has larger screens." (From
article: "Remember that your app will run on a wide variety of different
screen sizes.")

To the GP's point, the author is taking advantage of hardware variance and
picking larger images.

~~~
maggit
> the author is taking advantage of hardware variance and picking larger
> images.

I think an even more honest way to look at it is that the author uses the
Galaxy Neuxs as the Android reference device in all examples, including the
screenshots.

This can be defended as a part of Google's effort to try to lead the way for
other Android makers with their Nexus series and is probably not motivated by
any comparison to iPhone.

------
ges
"Please, don't try making stunning Android apps. Just respect our crappy
design patterns." Thanks Google!

