Don't mimic UI elements from other platforms

http://developer.android.com/design/patterns/pure-android.html

by tbassetto • 15 years ago

33 48 15 years ago

developer.android.com

cmicali• 15 years ago

And by "other platforms" we mean iOS.

ge0rg2• 15 years ago

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

babebridou6• 15 years ago

I use the following rule of thumb: "if you're going to display a new screen from touching an item with a label, append '...' to the label".

mef• 15 years ago

So you're effectively reproducing the caret by appending text to the label. Why wouldn't Android just use a caret or some other indicator by default? It's small UI details like this that can mean the difference between a sexy interface and a clunky one.

roel_v• 15 years ago

Yeah, that's more or less what the Windows UI guidelines say too.

demallien• 15 years ago

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.

Kudos3• 15 years ago

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.

myko• 15 years ago

The platform isn't deficient. Android users are familiar with the way the ActionBar works - any design that explicitly labels their back button is deficient and wasteful (on Android).

pja• 15 years ago

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

If it's just an entry, then it will either have a checkbox or a text box whilst inactive list members which do nothing are grey instead of white (at least on Gingerbread, I don't have an ICS device to hand).

So there's no ambiguity. You can argue that a caret or ellipsis might convey the affordance of expanding the item by selecting it and I wouldn't necessarily disagree, but the Android UI as designed is at least unambiguous.

king_jester3• 15 years ago

The example shows a ListView of items where each entry responds to a click and does something. In that context, you should never ever use indicators on the rows of the ListView as the list selector highlight when clicking an item signifies that an action will happen (if you want a list with no click actions, disable the list selector so nothing happens when a row is touched).

buff-a• 15 years 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!)

Steko2• 15 years ago

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

Should Google do nothing and let the fragmentation fester?

masklinn7• 15 years 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.

masklinn7• 15 years 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_jester3• 15 years 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.

fredley• 15 years ago

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

dquigley2• 15 years ago

I believe it's just recognizing resolution differences.

moe• 15 years ago

I think that's just the respective screen resolutions. iPhone is 960x640, Nexus is 720x1280.

CrazedGeek• 15 years ago

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• 15 years ago

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.

Kudos3• 15 years ago

The Galaxy Nexus has a resolution of 1280x720, the 4S has a resolution of 960x640. I would say the screenshots are accurate to scale.

wgx2• 15 years ago

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.

buro9• 15 years ago

But whose conventions to adopt?

With the three platforms mentioned, adopting any 1 of them over the other two will lead to the other 2 having confused users.

Adopting elements of all of them will create confusion everywhere.

I've used all three platforms and developed for 2, the UI is different enough that you really shouldn't mimic one on the other. The best I found was the Windows Phone 7 guidelines which were extremely well thought out and consistent. Would you have me use those on iOS?

Symmetry• 15 years ago

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.

wgx2• 15 years ago

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.

rix0r• 15 years ago

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

Steko2• 15 years ago

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

falling• 15 years ago

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.

masklinn7• 15 years ago

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)

masklinn7• 15 years ago

It's used when selecting items in an editable UITableView (list views).

Most well-known in Mail[0] (in a mailbox, tap the top-right [Edit] button), can also be found in Instapaper ([Edit] within a list of articles) or in iBooks's books list (although iBooks uses a blue checkmark, not red).

Not a commonly seen checkmark, though.

[0] http://0.tqn.com/d/ipod/1/0/G/H/-/-/using-iphone-email-4.jpg

ges• 15 years ago

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

jerfelix• 15 years ago

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.

masklinn7• 15 years ago

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

Don't mimic UI elements from other platforms

Related Stories