Live data from Hacker News

Android can be beautiful

androidniceties.tumblr.com

81–90 of 163 posts

Re: Android can be beautiful

#81
post #54

I'm bit surprised by all the comments about "Consistency". All of us use the web every single day and every single website looks completely different, all with their own styles, layouts, color schemes, etc. I would think that web designers, and designers in general, would be happy with the flexibility to create their own thing rather than having something that pretty much looks like everything else. The web used to h…

>I, personally, don't see the problem with lack of visual design consistency. I prefer to not have every app on my phone look the same.

I see a problem with that. It's that many(most?) apps have 1 or 2 developers with hardly any design experience, and no designers. So it's important for the default look and feel to be usable and stylish which iOS and Windows Phone do. This does not mean that they all look the same, because the developers with resources can do additional design work(perhaps by hiring a designer for the next version) on top of the default UI and UX to make the apps look more beautiful and with even better UX.

Having used a tablet with Gingerbread, both the OS and the apps were pretty much terrible(in some part because the OS many apps were designed for phones and not tablets). ICS improves the design in the OS quite a bit and some apps(like the ones featured in the article) have great design, but the vast majority of the rest of the ~500K apps in the Store don't look good still, because you can't expect free or 99c apps to hire expensive designers upfront or spend too much time on design because of a very real and common scenario that it won't make any revenue worth the design cost and time. Similar apps on iOS and WP may look the same as each other, but atleast the UX and the UI look decent if you stick to the defaults.

Re: Android can be beautiful

#83
post #45

Earlier quoted context omitted.

> 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 li…

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…

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.

Re: Android can be beautiful

#84
post #77

Earlier quoted context omitted.

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 t…

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…

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

Re: Android can be beautiful

#85
post #83

Earlier quoted context omitted.

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…

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 (hope…

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

Re: Android can be beautiful

#88
post #78
post #54

I'm bit surprised by all the comments about "Consistency". All of us use the web every single day and every single website looks completely different, all with their own styles, layouts, color schemes, etc. I would think that web designers, and designers in general, would be happy with the flexibility to create their own thing rather than having something that pretty much looks like everything else. The web used to h…

I'm a bit more surprised by the lack of comments about openness. You would think, that being a site for hackers, being able to install whatever you want on your mobile hand held computer would be a big deal. I mean, most people here would likely not even think of buying a laptop or a desktop that restricted them in the ways that iOS does. Consistency and looks are good and important, but to me, secondary to control.…

The secret to understanding HN is that it's not actually a site for hackers. The word "Hacker" in the title bar is written on a board that was nailed up over the word "Startup".

Re: Android can be beautiful

#89
post #57
post #48

Earlier quoted context omitted.

It's not because design talents are focused on iOS, it's that design talents are focused on the Android users that are worth targeting. Namely, people on 2.1 or 2.2+. Android generally monetizes/converts worse than iOS, so those who want a presence on Android can't afford to take advantage of any of the new stuff until old devices are retired sufficiently to make the tradeoff really worth it. It's been really tough t…

Not true, actually. Google has released a compatibility library to allow developers to target old versions: http://developer.android.com/tools/extras/support-library.ht... So older Android versions can use modern apps. Both the examples I gave (Foursquare, Spotify) work with both newer and older versions.

There are some pretty gaping holes in the compatibility library. Luckily the most important of these (ActionBar support) is covered by a great 3rd party library (ActionBarSherlock).

If anything, I think the existence of the compatibility library and ABS show that Google is dropping the ball a bit on the core Android framework. Why even have these be extra (and in one case 3rd party) libraries? Where possible why not just write the core SDK in a way such that it can fall back to 1.6 or 2.2 without having to worry about fiddling with compatibility libraries?

Re: Android can be beautiful

#90
post #57

Earlier quoted context omitted.

Not true, actually. Google has released a compatibility library to allow developers to target old versions: http://developer.android.com/tools/extras/support-library.ht... So older Android versions can use modern apps. Both the examples I gave (Foursquare, Spotify) work with both newer and older versions.

There are some pretty gaping holes in the compatibility library. Luckily the most important of these (ActionBar support) is covered by a great 3rd party library (ActionBarSherlock). If anything, I think the existence of the compatibility library and ABS show that Google is dropping the ball a bit on the core Android framework. Why even have these be extra (and in one case 3rd party) libraries? Where possible why not…

Precisely. Furthermore, the older platforms have major problems with stream poisoning for HTTP requests, include an incomplete beta version of Apache's HTTP classes, have old SQLite libraries which don't support upserts, and so on.
Post reply on HN