[dpark]

> Android actually hasn't suffered from tactile UI fragmentation much more than iOS has.

If the apps on this page a representative, I'd say that Android has experienced a lot more UI fragmentation than iOS. These are being held up as examples of best Android interfaces, and they look very inconsistent to me.

In contrast, I just opened up a bunch of random apps on my phone's home screen, and they all look very much like "iOS style". Obviously the native apps match well, but so does OneBusAway, Wikipanion, Skype (though the UI is flatter than the rest), Google Voice, Amazon, OneNote, etc.

These all look like iOS apps to me.

http://itunes.apple.com/us/app/onebusaway/id329380089

http://itunes.apple.com/us/app/wikipanion/id288349436

http://itunes.apple.com/us/app/skype/id304878510

http://itunes.apple.com/us/app/google-voice/id318698524

http://itunes.apple.com/us/app/amazon-mobile/id297606951

http://itunes.apple.com/us/app/microsoft-onenote/id410395246

[KirinDave]

I thought you were talking about the actual meaning of taps and swipes and whatnot... that's what I was referring to the as "tactile" part of it, where things like long presses and swipes mean the same thing between apps. In terms of visual style, there has been significant change over the last 18 months as designers come to grips with the new 4.0 style. Both iOS and Android tend to suffer from the problem of "What the fuck can I press?" with some apps.

But to my eyes as an Android user, I see a lot of consistency here. The ActionBar is firmly in place, so I know where to go for navigation. The visual metaphors vary in terms of actual look, but I get what's up.

For example, compare to very different apps: Catch and doubleTwist Alarm Clock. Both are "bounded" by their top bar (although Catch has elected to add extra app-specific chrome at the bottom, too). The navigation "upwards our out" between panes is consistently in the upper left. The additional actions for the app as a whole are on the top right.

In cases where the apps deviate (e.g., bottom bars in Gmail and Catch), the designers have had the good sense to use the standardized icons as opposed to further customization, helping to signal the user that this app does deviate from pure actoinbar navigation. The share, attach, favorite, and trash icons are all with pixels of standard.

A lot of iOS users first coming to Android (including myself) after the advent of ICS may be surprised once they realize how consistent the presence of the ActionBar is, even if it varies in appearance. I encourage you to play with one to see this in action. I certainly felt that sense of confusion at first because I'm used to unified navigation chrome from iOS for most things outside of games. I think this is just a case of longtime iOS users not being familiar with the visual language of the Android platform.

[dpark]

Well, the meaning of taps and swipes is part of the consistency issue. Interaction is more than just "what does swipe do?". It's also "how do I go back?", "how do I take an action on this item?", "how do I change context?".

I personally don't run into a ton of issues in iOS with determining what swipes vs long-presses vs long-taps do. Swipes in a list tend to invoke the "delete" context. Swipes up/down scroll. Tap to invoke. Long-tap for select in a text context. There's certainly not 100% consistency, but it seems fairly consistent to me with the apps I use. I can't speak to how consistent or inconsistent these are on Android, because I haven't used an Android device enough to really know.

Speaking to Catch and doubleTwist, these seem inconsistent to me. Visually, they're quite different, but there seem to be pretty significant functional differences. Many of the doubleTwist screens do not have the "up/out" chevron in the upper left (how is this not redundant with the global "back", anyway?). On the 4th screenshot in particular, there's no "up/out", but there is a settings cog that appears in none of the other screenshots. It appears that doubleTwist also uses a "slide to reveal" metaphor (invoked by the chevron on the main screen) that isn't in Catch or the other apps. In catch, despite there being an action bar at the top, virtually all of the actions you might want to take actually seem to be in the custom bar at the bottom. I don't see how these at all demonstrate consistency.

[KirinDave]

> I personally don't run into a ton of issues in iOS with determining what swipes vs long-presses vs long-taps do.

Unless you play games or use some of the most popular twitter clients. ;)

> Visually, they're quite different, but there seem to be pretty significant functional differences.

To be expected, they do very different things. I chose them because of their differences. Both apps have deviated from a very mellow Holo standard without introducing a lot of confusion. Evaluate their differences as deltas from the Android baseline (the way a user would), instead of as deltas from each other (which is how someone looking at screenshots on a webpage would).

> (how is this not redundant with the global "back", anyway?)

Oh, because back goes to the last thing you were doing. The chevron goes up in the app. Any Android user figures this out and why it is this way very quickly, but I can see why an iOS user probably finds the distinction weird.

Apps share functionality in Android. So unless the app has hijacked your back button (very rare, only games, browsers and the keyboard tend to do this now), it generally goes where you expect. It took a LONG time for the Android devs to get this right, but for the most part it works surprisingly well now.

> On the 4th screenshot in particular, there's no "up/out", but there is a settings cog that appears in none of the other screenshots.

This is DoubleTwist being cute, for them they have their chevron animate down with a backpane. The navigation has traveled to the lower left. This is confusing in screenshots, but not in practice since it is essentially a snazzy modal dialogue and the user has just spent 160ms or so watching the pane slide down. It's essentially a backpane dialogue.

> In catch, despite there being an action bar at the top, virtually all of the actions you might want to take actually seem to be in the custom bar at the bottom. I don't see how these at all demonstrate consistency.

The ActionBar generally speaks to navigation aspects of the app, not specific screen actions. In this, it's very much like iOS's topbars and clearly there was some inspiration there. It's not unusual in an iOS app to see a novel piece of chrome with fixed position for "add" and "remove" and other actions core to the app.

[dpark]

> Unless you play games or use some of the most popular twitter clients.

I haven't noticed any weird issues in games, but it's true that I don't play much, nor do I use twitter with any frequency.

> To be expected, they do very different things.

I agree there should be differences. My point is that with these two apps I see almost no actual similarities in the UI. If you'd told me that one of these was an Android app and the other was from, say, Meego, I'd totally have believed it.

> Evaluate their differences as deltas from the Android baseline (the way a user would), instead of as deltas from each other (which is how someone looking at screenshots on a webpage would).

Ok, but the question was whether there was more fragmentation in Android than iOS, and from what I can see the answer still appears to be yes. The deviation from the "baseline" seems higher in Android.

> Oh, because back goes to the last thing you were doing. The chevron goes up in the app. Any Android user figures this out and why it is this way very quickly, but I can see why an iOS user probably finds the distinction weird.

Maybe I'd understand this more if I used an Android device for an extended period of time. It seems that these have a ton of overlap, though. Most of the time, in my experience, up/out is the same as back, because I got to my current location by drilling down through the content. Unless back is only between apps now.

> This is DoubleTwist being cute

I get what they're doing. My point is that it's inconsistent with the platform.

> The ActionBar generally speaks to navigation aspects of the app, not specific screen actions.

Someone should tell the Google+ team. On their ActionBar, I see "write" (new post?), "refresh", "reply", and "upload picture" (I'm guessing).

[mayanksinghal]

> I can't speak to how consistent or inconsistent these are on Android, because I haven't used an Android device enough to really know.

They are pretty consistent. Swipe to delete in a newer action, but other than that most things tend to have similar functionality. I have mainly used 2.3 and I think I never had issues with finding UI elements. Options button helps when nothing else does.

Back button does have issues at places (browsers mostly) but it eventually takes you where you want to go. I shifted to ICS 4.0 very recently and experience is even better.

[MatthewPhillips]

That might be because you have subconsciously (or consciously) installed apps that have similar UIs. Your other comments here indicate that you value consistent UIs strongly, so that's not suprising. The author of this blog is only targeting "beautiful" apps. I personally agree with you, most of my apps are in the ICS style. I find apps that I used to think were attractive (like DoubleTwist and DoubleTwist Alarm) to look dated now and out of place.

However we also know that normal users don't necessarily value consistency as strongly. Many developers have reported that their iOS apps do better with an in-your-face UI.

[dpark]

Could be. I think it's more that iOS has had a relatively consistent UI style since day 1, while Android's style has been changed more. Additionally, most Android apps have traditionally come after their equivalent iOS apps, and so have often been the victim of bad UI ports (as evidenced by the large number of Android apps that look distinctly iOS-esque).

I wonder if Window Phone will suffer from the same as it (hopefully) becomes popular. I assume the vastly different UI style will probably prevent some of this, though.

[KirinDave]

Android's UI history is about as checkered as you can get. It's only just stabilizing with the last major rev.