Don't mimic UI elements from other platforms
developer.android.com
developer.android.com
Instead, let the user guess if an entry is just an entry or opens another screen full of interesting things.
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.
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.
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_...
(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...
I see touch scrolling as a great implementation of the wrong solution.
2. Paging and scrolling are different things. Paging can works well when you're dealing with things that don't need compared (like a list of names in a phone book) but it breaks when you want to compare things.
Consider a spreadsheet or log file: you might want to compare any two given rows, and if they're split across a page break, it's a nightmare.
2. I agree with you, but by itself a list is not any better for comparing rows. It's only better in the edge case where you can display the two rows on the same screen in the list but not on a pager, and even then it's visually hard to get the job done.
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.
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.
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.
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.
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
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".
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!)
Should Google do nothing and let the fragmentation fester?
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.
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.
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.
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.
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.
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.
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?
To the GP's point, 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.