5 ms·

Don't mimic UI elements from other platforms

33 points by tbassetto 15y ago

cmicali 15y ago
And by "other platforms" we mean iOS.
ge0rg 15y 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.
- babebridou 15y 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 15y 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.
    - babebridou 15y ago
      I agree. I'm not defending my decision to do it that way, it comes down to a habit from my Swing days, a good one then, and probably a bad one now that I'm working to correct. I'm just stating the plain fact that I have my way of doing it, Apple have their way of doing it, and Android has no way of doing it. I believe the right way to be something else, though: Never display a list that mixes data and actions. Even better: never display a list at all. Lists are bad for the user. Scrolling is bad. That's my honest belief.
      - dquigley 15y ago
        "I believe the right way to be something else, though: Never display a list that mixes data and actions. Even better: never display a list at all. Lists are bad for the user. Scrolling is bad." - Interesting, I'd love to know if there is more of a reason for this, specifically why scrolling is bad? Either way, it's an interesting idea, and I'm tempted to agree with you. I would love to see the open source community, Android included, expand on what is done on this one site, and continue testing, discussing, and demoing theses types of user experience and interface questions, so we can all benefit from it.
        babebridou 15y ago
        I've tried to reason my belief. It's hard. The only really earthly reason why I don't like scrolling is that (don't laugh) touch interfaces hurt my fingers. I actually feel pain whenever I touch the iPad or Xoom's screen, or my macbook pro's touchpad. I gave my magicmouse to my sister no more than a couple hours after I had purchased it, because I knew I couldn't sustain the mix of friction & electrical pain for more than a minute at a time. I honestly don't know what came first, the pain or the repulsion for scrolling in general, but the association is fierce. Then I started reasoning on why people would prefer a world without scrolling. The first thing that came to mind is that scrolling does not exist a lot in real life, apart from a few instances: using binoculars, using a magnifier, going forward/backward on some sort of static security camera looking at traffic or something like that. For everything else, we naturally use paging. Paging is strange: using two or three fingers, you can page by any amount you see fit, and every time, the entry you're looking for is on display at the exact same place on your eye. Items can be specified with their page number (324), then a 2D position (fifth line, seventh word). At some point you can even use muscle memory to reach the correct page while you position your eye for receiving the info. Scrolling also has an interesting attribute: it's entirely a computer concept. You have a buffer of information and you increment the offset. But as an end user, using only scrolling, you can't easily perform things such as dichotomy - everyone knows dichotomy even if they don't know the name of it. Go forward a bunch, go backwards half a bunch, go forward half of a half of a bunch, find the entry. Another thing that I don't like with scrolling is how it messes up with the "5-7 modulo 2" rule of thumb for decision making (1). It's not that there are more elements than needed, it's that they get pushed up & down when you scroll, so they never appear to be a fixed point in space where you can go in a subset of 3-9 destinations. As a result, you can't select a subset from 3-9 subsets, and you can't select an item from 3-9 items, you actually have to scroll all the way and parse all elements in order to make an informed decision from, say, 15 or 150 possible ones. All these questions (and more (2)) itched me since the day I realized that there could be a computer world without scrolling and maybe we could start dreaming/having nightmares about it... Anyway this is a belief and I'm generally a man of reason - it's tough to put it into words what you know you definitely can't prove :) (1) : http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_... (2) : mouse wheel fatigue when browsing websites or expanding trees, why isn't a newsfeed or a time related search result on a logarithmic scale so I can see it all, always, since the start of the century, why did we mix UI and content on webpages when we could simply remove the navigation panes...
  - roel_v 15y ago
    Yeah, that's more or less what the Windows UI guidelines say too.
- demallien 15y 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.
  - Kudos 15y 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.
    - ge0rg 15y ago
      As the guidelines outline, the (physical) Back button has a different meaning from the Up button in the top left corner of your app.
  - myko 15y 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 15y 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_jester 15y 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 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.
  - 15y ago
fredley 15y ago
I like how the iOS screenshots are tiny compared to the Android ones. Making up for much?
- dquigley 15y ago
  I believe it's just recognizing resolution differences.
- moe 15y ago
  I think that's just the respective screen resolutions. iPhone is 960x640, Nexus is 720x1280.
- CrazedGeek 15y 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 15y 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.
    - Kudos 15y ago
      The _only_ model running Android 4.0 has a larger screen.
    - maggit 15y ago
      > 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.
wgx 15y 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 15y 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 15y 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.
  - wgx 15y 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 15y 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".
Steko 15y ago
Is that red checkbox from the comparison example actually used anywhere in iOS?
- falling 15y 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.
  - masklinn 15y 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)
- masklinn 15y 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 http://0.tqn.com/d/ipod/1/0/G/H/-/-/using-iphone-email-4.jpg
ges 15y ago
"Please, don't try making stunning Android apps. Just respect our crappy design patterns." Thanks Google!
jerfelix 15y 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.
- masklinn 15y 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.

33 points by tbassetto 15y ago

And by "other platforms" we mean iOS.

ge0rg 15y 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.

babebridou 15y 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 15y 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.
  - babebridou 15y ago
    I agree. I'm not defending my decision to do it that way, it comes down to a habit from my Swing days, a good one then, and probably a bad one now that I'm working to correct. I'm just stating the plain fact that I have my way of doing it, Apple have their way of doing it, and Android has no way of doing it. I believe the right way to be something else, though: Never display a list that mixes data and actions. Even better: never display a list at all. Lists are bad for the user. Scrolling is bad. That's my honest belief.
    - dquigley 15y ago
      "I believe the right way to be something else, though: Never display a list that mixes data and actions. Even better: never display a list at all. Lists are bad for the user. Scrolling is bad." - Interesting, I'd love to know if there is more of a reason for this, specifically why scrolling is bad? Either way, it's an interesting idea, and I'm tempted to agree with you. I would love to see the open source community, Android included, expand on what is done on this one site, and continue testing, discussing, and demoing theses types of user experience and interface questions, so we can all benefit from it.
      - babebridou 15y ago
        I've tried to reason my belief. It's hard. The only really earthly reason why I don't like scrolling is that (don't laugh) touch interfaces hurt my fingers. I actually feel pain whenever I touch the iPad or Xoom's screen, or my macbook pro's touchpad. I gave my magicmouse to my sister no more than a couple hours after I had purchased it, because I knew I couldn't sustain the mix of friction & electrical pain for more than a minute at a time. I honestly don't know what came first, the pain or the repulsion for scrolling in general, but the association is fierce. Then I started reasoning on why people would prefer a world without scrolling. The first thing that came to mind is that scrolling does not exist a lot in real life, apart from a few instances: using binoculars, using a magnifier, going forward/backward on some sort of static security camera looking at traffic or something like that. For everything else, we naturally use paging. Paging is strange: using two or three fingers, you can page by any amount you see fit, and every time, the entry you're looking for is on display at the exact same place on your eye. Items can be specified with their page number (324), then a 2D position (fifth line, seventh word). At some point you can even use muscle memory to reach the correct page while you position your eye for receiving the info. Scrolling also has an interesting attribute: it's entirely a computer concept. You have a buffer of information and you increment the offset. But as an end user, using only scrolling, you can't easily perform things such as dichotomy - everyone knows dichotomy even if they don't know the name of it. Go forward a bunch, go backwards half a bunch, go forward half of a half of a bunch, find the entry. Another thing that I don't like with scrolling is how it messes up with the "5-7 modulo 2" rule of thumb for decision making (1). It's not that there are more elements than needed, it's that they get pushed up & down when you scroll, so they never appear to be a fixed point in space where you can go in a subset of 3-9 destinations. As a result, you can't select a subset from 3-9 subsets, and you can't select an item from 3-9 items, you actually have to scroll all the way and parse all elements in order to make an informed decision from, say, 15 or 150 possible ones. All these questions (and more (2)) itched me since the day I realized that there could be a computer world without scrolling and maybe we could start dreaming/having nightmares about it... Anyway this is a belief and I'm generally a man of reason - it's tough to put it into words what you know you definitely can't prove :) (1) : http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_... (2) : mouse wheel fatigue when browsing websites or expanding trees, why isn't a newsfeed or a time related search result on a logarithmic scale so I can see it all, always, since the start of the century, why did we mix UI and content on webpages when we could simply remove the navigation panes...
- roel_v 15y ago
  Yeah, that's more or less what the Windows UI guidelines say too.
demallien 15y 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.
- Kudos 15y 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.
  - ge0rg 15y ago
    As the guidelines outline, the (physical) Back button has a different meaning from the Up button in the top left corner of your app.
- myko 15y 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 15y 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_jester 15y 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 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.
- 15y ago

fredley 15y ago

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

dquigley 15y ago
I believe it's just recognizing resolution differences.
moe 15y ago
I think that's just the respective screen resolutions. iPhone is 960x640, Nexus is 720x1280.
CrazedGeek 15y 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 15y 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.
  - Kudos 15y ago
    The _only_ model running Android 4.0 has a larger screen.
  - maggit 15y ago
    > 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.

wgx 15y 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 15y 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 15y 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.
- wgx 15y 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 15y 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".

Steko 15y ago

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

falling 15y 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.
- masklinn 15y 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)
masklinn 15y 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 http://0.tqn.com/d/ipod/1/0/G/H/-/-/using-iphone-email-4.jpg

ges 15y ago

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

jerfelix 15y 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.

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