Android can be beautiful
androidniceties.tumblr.com
androidniceties.tumblr.com
UPDATE: koko775 raises a good point: the large installed base of pre-ICS Android versions may also be a factor. See http://news.ycombinator.com/item?id=4533819
I think the mobile OS market is going to end looking somewhat similar to the PC OS market, but changing Windows for Android. The market share race is impossible for Apple to win with their current pricing and model range. It's normal to see a lot of activations if the cheapest phone is $50
I also wish they mandated everyone has at least 512 MB of RAM in their phones, and at least 2 GB for the OS and 2 GB of app space. That way upgrades can be ensured for years, and people, especially regular people, can actually install more than 5 apps without running out of space (and no, App2SD doesn't count, and it's almost useless). And while they are at it, they should also stop supporting the ARMv6 architecture, now that the ARMv7 Cortex A5 and next year Cortex A7 are going to be used.
If Google wants to bring down the hammer on manufacturers, it should be for stuff like this, that ensures users of Android devices, even at the very low-end, get a pretty good experience, otherwise they'll always think Android devices are crap, after their first cheap Android smartphone. They don't want that kind of perception to affect the Android brand in the long term.
Eventually they will upgrade to a nice Android phone, and will enjoy the enhanced user experience. But cost does matter to some people, and although browsing at 320x240 is hardly ideal, it's probably better than not being able to buy food for a week.
(I personally use very few apps aside from the default Google apps. I mostly want to receive text messages, make phone calls, and browse the web. Apps, to me, don't add much value when the app-maker already has a perfectly fine website.)
I would disagree - I've heard quite a few non-technical people say they are never getting another android because they are so frustrated by their gingerbread/froyo handsets. They envy the iPhone simply because they never hear people swearing at them (whereas their phones prompt a tirade of profanity)
Anecdotally I know people who had cheap Android phones and then upgraded to an iPhone because their experience with Android was terrible.
That being said I don't really think it's Google's job to protect Samsung's future profits from being eaten into by people's poor experience with a crappy LG phone. It's just one more case where Apple's total control model is beneficial to them.
Wouldn't that be worse for (1) customers, (2) android's reputation and (3) Google?
The grandparent's desire is isomorphic to wanting Google to force users to spend more on their phones so she has to spend less on her software. That's not a good business tactic.
Warning massive derail... One thing the tech commentariat has slacked off on is better labels for different Android flavors. I'd suggest:
AOSP = "Opendroid" (forkdroid?)
stock Android (Opendroid + Google services/ecosystem) = "stockdroid"
Android + Touchwiz/Sense = "Samdroid"/"Sensedroid"
Opendroid + Amazon services/ecosystem = "Amazdroid"
Samsung Galaxy Chat B5330 http://www.gsmarena.com/samsung_galaxy_chat_b5330-4866.php
ZTE Style Q http://www.gsmarena.com/zte_style_q-4602.php
A couple of more devices which are reportedly coming soon: http://goo.gl/F411K
These are cheap phones, though I imagine you'd get a much better deal if you spent the same amount of money on a used Android phone.
The problem with android is that it never had any design language like iPhone and the Windows Phone have. They give a framework for an app developer to work within. It inspires them to make consistent beautiful designs. Android has always been this free-form thing which I think caused many ugly apps to be developed for it.
Windows Phone market place for one is full of such beautiful apps, thanks to the detailed guidelines about the metro design.
Also, the Google guide is much nicer to look at itself than MS's.
Who are those big dogs? Google? :) Microsoft? :)) Apple? :)))
Are you saying there's a general appreciation for Android, so it's higher priority nowadays?... or are you saying Android is actually being prioritized over iOS? The latter would be surprising imo.
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 have some consistencies, like <A> tags rendering as blue with an underline and always loaded a new page, but that's long since gone. Nowadays designers are free to make links look and work how they want.
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.
iOS is an appliance, Android is a computing platform. I want my phone to be a computing platform.
Or else they've migrated somewhere else, and I haven't been able to find them...
Any ideas?
It is also possible to run any standard app without unlocking the boot loader. You only need to unlock or root your phone for non-standard apps or modified versions of the operating system.
This is not at all the same thing as iOS jailbreaking and the level of control iOS exerts. It might be nice to support a stock way of using root, but the fact that I can run any program developed according to the standard OS apis is enough for me to consider it a proper computing device.
My definition would have at minimum:
(1) Be able to run any app designed for the system. (2) Be able to buy or receive apps from any source.
I just have the feeling that Google gets too much praise for their "open" Android. It's not my definition of "open" (especially in the light of their current threat towards acer http://marketingland.com/google-acer-android-aliyun-21631 )
I think I agree with you it's a computing platform (if talking about the Nexus brand). Yet, the kindle fire for example is not a computing platform (also running Android). iOS feels more like an appliance (although with the $70 developer program bonus you can do mostly anything you want with it... until Apple revokes your dev certificate :). Yet, I would love to have a really open computing platform (like Maemo was) for my phone.
edit: clarifying that I mean the nexus brand concering the computing platform.
But people that don't care about computers the way most readers of this site do aren't happy to be surprised by every new application. Consistency means comfort; even for websites, many of those aimed at general consumption (think newspapers and magazines) aim for simplicity and consistency.
And every day hundreds of millions of people waste some of their time and intelligence making sense of said inconsistent designs.
This is why Safari's reader and Readability are so popular.
The consistency of the web is very important. That consistency is exactly what lets us look at a new web page and immediately start making sense of it and websites that don't conform to this consistency are the websites that we immediately label "terrible" and "unusable".
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.
I see that as a bad thing and I get irritated every day especially on sites where I need information real fast, like the DMV, police, car insurance website, company careers page or address etc. Mystery meat navigation, especially on hover abounds on the web.
Especially when I am on a phone, quickly getting the info I need for websites and apps is much more important than some slow loading website with 800KB of slow Javascript and retina sized images wrapped in byzantine navigation.
http://www.webpagesthatsuck.com/mysterymeatnavigation01.html
We just need the app makers to catch up. Foursquare, for instance, has been redesigned and looks great. However, their widgets haven't been touched and look awful by comparison. Spotify has done a far better job of updating everything at once.
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 to see all of the improvements, because Google is addressing user upgrades so poorly (even though the fault lies mostly with the manufacturers) that the upgrade problem is such a big deal for developers.
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.
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?
Example 1: Fragments.
Introduced with Honeycomb. Android supports these via the "support" library back to 1.6, but the APIs you're using are slightly different (eg. getFragmentManager() vs getSupportFragmentManager()) and the classes you use live in different packages (eg. android.app.Fragment vs android.support.v4.app.Fragment). If the support library were more tightly integrated with the mainline SDK, you wouldn't have to worry about all these splits, but it isn't so you do. You have to decide up front if you want to code to the mainline SDK classes or the support versions and then this gets worse when you implement other classes which use Fragments in a library meant for other developers -- should your classes assume those developer's Fragments derive from android.support.v4.app.Fragment or android.app.Fragment? It gets really messy really fast.
Example 2: ActionBar
Not even supported via the regular support library, you have to go get ActionBarSherlock which itself extends the Android support library. Kudos to Jake Wharton on this great library, but why didn't Google just make their ActionBar backward compatible to earlier versions out of the gate? It is clearly possible to do this as ABS does it.
I'm sure there is some specific reason the Android devs could give for why the support lib and the main SDK are so increasingly fragmented and it may have a very good legacy reason for existing, but having them work this way is harmful in the long run, IMO. Maintaining this split makes things much harder for devs just trying to get into Android who are very confused by all the different decisions they have to make just to get basic app functionality working across a decent cross-section of Android devices.
Granted, I'm not saying any of this makes Android development impossible or akin to rocket science, but it does make it needlessly complex which is bad given that Android is already seen as a bit of a red-headed-stepchild to iOS development even despite the overall marketshare advantage Android has.
So yes, Android could use a better/cleaner visual style, but that's not it's biggest problem. Also, if a new visual style would be adopted, it should be universal. Right now it's a mess of apps trying to do their own thing because the default style is ugly, and these examples demonstrate that perfectly... Android 4 has shown some improvement but I still don't like it.
There are also quite a few iOS apps that don't necessarily respect the general look&feel of iOS, but some of them succeed in having a distinct style without clashing badly with the rest of the interface. Hell, Google showed that it is capable of doing just this, just look at the Google+ and the new YouTube app, they are pretty neat.
I think Android UI designers should use iPhones and Windows 7/8 phones as their daily device, or switch at least once every week. Then they'd see what's wrong, what irritates them about every OS and find a way around some of the moronic decisions were made in some of these OS's, and all are guilty of this to some extend. Android at this moment however gets the crown in usability WTF's.
Disclaimer: I own an iPhone and iPad, but mainly develop for Android/BB/WinMobile.
Yes, that is true, but only for a screen with a back button, otherwise that spot on the screen is probably an "edit" or something else you don't want to do. And after you realize its not "back", you're off hunting around the rest of the screen for the "done" or "cancel" button. Unless of course, you came from a different screen on the same logical "level", where to go back to the screen you came from means picking from one of the row of tabs at the bottom of the screen. Unless you're in an app with a row of tabs at both the top and the bottom of the screen. In that case, the tabs at the top might belong to the page selected at the bottom, or the tabs at the bottom might belong to the page selected at the top, hopefully the UI has been designed with a visual afforance to give you a hint.
Disclaimer: I've been using an iPhone for about 2 months after 2 years of android ownership. They both have their own way of doing things that you can get used to one and think the other feels foreign. FWIW, After time and familiarity, you forget to look at it critically; iOS UI is clunky and unintuitive, its just that us iOS owners have been tossing eachother off about just how great iPhones are for years. And you can't pretend like this isn't true, now that I'm in the club, iDevice owners try to get me to join in some collective pursuance-rationalization quite frequently.
I think this is more of a personal preference thing than something that is broken. I use an android phone, and used to use a honeycomb tablet. When i replaced the tablet with an iPad, the thing i hated most about iOS was the back button behaviour. In iOS back takes you back to wherever the application developer thinks back should take you. In Android, except for very rare cases, back takes you back to the previous screen you were on, which might be up one level like on iOS, or it might be a different app entirely. One isn't better than the other, they're just different functions.
None of these general aesthetics are bad, but the inconsistency seems to be an issue. (Actually, a few of them do look bad to me, like Rdio, with the very dated "app home screen" that looks like it was copied from the old Facebook iOS app.)
Yes. Consistency between apps is what allows you to start up a new app and intuitively know how to use it. You shouldn't have to re-learn how to interact with each app.
> Distinctive styles are just a nice reminder of what app you're in.
Distinctive style up to a point is useful and pleasant. Gratuitous differences make interaction more awkward. Even at the purely aesthetic level, a reasonable level of consistency improves the feel of the device. When an app looks completely different from all the apps that come with the device, it looks less distinctive and more out-of-place.
I'm not sure why you'd say this. 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
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.
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.
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.
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).
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.
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.
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.
http://gadgetix.com/wp-content/uploads/2011/08/Uber-Music-fo...
It's important to distinguish "looks pretty" and "beautiful".
>> As it stands, If you design a great app for Android and people say 'hey, that looks like an Android app', that means you've failed.[1]
iOS, on the other hand, is supremely superior in this department. The cohesiveness of the experience is second to none. I value that over custom configurations any day. My android phones have been wonderful hack-fests, but at the end of the day, the one thing I can't hack into them is a consistent experience.
Streaming has nothing to do with UI consistency. It's a battle, because the APIs are very high level and you're limited in the amount of control you have without a ton of work, and it seems like manufacturers are screwing with the stack somewhere. Doesn't matter, though, because we're talking about UI consistency.
The podcatcher app is sort of ripe for some good competition in this space, with Google Listen no longer available. I am working on something. http://imgur.com/RtG8e , but someone else should get in here too.
https://play.google.com/store/apps/details?id=com.snoggdoggl...
I'm now both an iOS & Android dev and designer (and owning quite some devices from both sides), but I'll choose an iPhone anytime over iOS. There is no Android experience. There is only a Galaxy Nexus experience, an S3 experience,... But there IS an iPhone experience, and I know that my phone won't restart on me when I want to show my ticket to the train conductor.
The issue we've seen is that people build an iOS app and then port it over to Android.
We designed Catch 5.0 apps for Android and iPhone in parallel. This let us keep consistency between the platforms when it made sense, but also let us tweak the design early on so it could take advantage things unique to the platform, e.g. Action Bar on Android.
The team is incredibly proud of this release, and it is nice to see folks taking notice. Both Google and Apple have also featured this release, everybody is beaming here. =)
I just wish I had more than one friend actually using it. Heh.
I mean, it is pretty (well, arguably, most of them are), but, the buttons are all over the place and everyone seems to have it's own UI plastered on top of more or less "android ui compliant" stuff.
Look closely though. You'll notice the ActionBar is extremely prevalent in these. The ActionBar is actually one of those few Android teachable moments; I wish Apple did this as well, as consistently, or as themably. I've used a lot of these apps (and I am sad to not see Pattrn up there!) and it's very much the case that they have a fairly consistent set of "touch semantics" that screenshots don't reveal. E.g., Tap upper right corner to configure; long press for edit; swipe horizontally to navigate; long press on text fields to engage c/p editor bar.
For better or worse, Android's toolkits offer a lot more guidance to the programmer on "the right way" than Apple's do (a great example of this that bleeds into UI is how Android has a ton of Loader patterns and iOS doesn't have anything nearly so sophisticated in its core lib). So in some respects, Android is actually slightly better off; the bigger toolkit means you get some superior consistency. The recent iterations (and backported support) framework strongly encourages you to do things like support long presses and swipe navigation and backpane navigation.
So let's just pretent this isn't a shitty genetic fallacy post and address your challenge head on, "Back up your example and prove to me Android's APIs give more guidance than Android's in how to do ______." I specifically mentioned the Loader pattern.
Compare: Google's Loader pattern: http://developer.android.com/reference/android/content/Loade...
A concrete and common example, doing an async task: http://developer.android.com/reference/android/content/Async...
Compare this to the equivalent API for doing async task usage in iOS: http://developer.apple.com/library/ios/#documentation/Perfor...
In iOS There is no concept of a "Loader", so the community has come up with stuff like AsyncUIImageView and friends (code here: https://github.com/nicklockwood/AsyncImageView) which still doesn't entirely solve the problem, because solving the problem takes a lot of framework support.
Sadly, fragmentation is at play again in this; and many Android developers don't use Loaders because they're intimidated or confused or can't use them for their entire panoply of supported devices; so there are a fair share of Android apps that do not use them. You can usually catch this if you change orientation and see things reload from scratch.
Given the rapidly increasing velocity of deployment of 4.0 devices, I think this issue with framework fragmentation is transient.
I'm surprised that so apps look WP metro style
I'm guessing this was designed by someone with a multitouch trackpad. I know I tend to forget not everyone else has 2 finger scroll at their fingertips, I've had to get into a habit of having a test run using a mouse when I put together pages.
Those of us using multitouch trackpads can scroll by just swiping on the page using N fingers, like scrolling on a touch phone by dragging the page with your finger.
Flipboard set a standard for beautiful news applications. Path reimagined what social could be on mobile and made numerous UI innovations. Instagram took a novel concept and made photosharing exciting to a new audience. Square showed off the increasing real business viability by making payments accessible to anyone with a phone. All these apps weren't available on Android for some time. Sure they are now but this far more a matter of increasing market share than a change of opinions and it continues to hold true as we see well-designed apps like Paper start iOS only. Android is by no means the epicenter of creativity on mobile and though beautiful, the ports largely still have substandard experiences than their iOS counterparts.
In my opinion this is a result of equal parts hardware and audience. Android may be on more devices as a whole but many of the devices are not even remotely competitive with top-tier smartphones. They are sold with the intention of being budget friendly and thus it becomes a hassle to acquire the additional devices, adapt interfaces to the numerous screen sizes on them, and adjust for performance limitations. I also believe that the design of the iPhone naturally attracts great designers. Android has a reputation of throwing good hardware into poorly designed phones with cheap materials and inferior build quality - the future is just not as cool when you need to interact with plastic buttons. Lastly, I believe the iPhone audience is naturally more in tune to seek out great designed products. The openness that appeals to Android customers creates an expectation that applications should be free. There is a decreased interest in browsing the marketplace and many of the most popular apps are just free copycats of popular iPhone applications.
Oh, and their theme locks up Firefox, however I'm willing to blame that on FF rather than the designer(s).
If anybody has any questions feel free to email me at a@catch.com
Kind of meta but IMO the screenshots on that site are too big and should be scaled down a bit.
The XL is the actual size (pixel-wise) that you would see on a phone such as the Galaxy Nexus.
(and yes, these apps look fantastic)
As others have noted, plenty of these apps are using the ActionBar (which is a default widget starting with 3.0, with an unofficial, open-source compatibility library) and plenty are using Fragments (also standard starting with 3.0, with an official compatibility library).
Moreover, many of these apps (e.g. Boid, Pocket, Papermill) are explicitly Holo-themed, so, at a minimum, they're using the default widgets for design guidance even when they're not using them directly (for compatibility or other reasons).
Flagged.
Now that I can see the examples, they are actually pretty decent.