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