App Store Discoverability

While I have some angst about what the app store model means in terms of platform control and openness, it’s clear that Apple’s App Store implementation was a quantum leap improvement in terms of user experience, allowing end-users to finally easily install useful apps on their fancy “smart” phone. Solving that “install” problem has resulted a panoply of apps, which has in turn spawned the new (well, the standard infoglut/attention-scarcity) problem of “discoverability.” This problem is particularly acute for finding the good stuff from the crap (quality), or finding the thing that will make your life better that you didn’t even know existed (serendipity).

This is a problem that affects Apple more-so than it’s competition at the moment primarily because of it’s scale (almost a magnitude greater # of apps than Android’s Market), but one that any successful app store will need to address. I believe that it does affect Apple a bit more because of the lack of a trial or easy refund path, which basically makes the cost of trying out an unknown paid app, well, the cost of the app. Android’s Market, in contrast, has a trial period, which somewhat lowers the bar there (although that’s offset by the insane lack of “Update All” functionality and cumbersome uninstall procedure). In terms of browsing, however, both the Android Market and Palm App Catalog basically otherwise ape Apple’s browse functionality: lists of apps with filtering by category and ordering by recency and global popularity.

This is somewhat surprising to me because it seems that there are tons of pretty trivial ways to make apps more discoverable. This week saw the launch of First & 20 – which is on the right track – but this type of functionality should really be built into the marketplace, and should allow you to see the most popular apps that your friends are using (no offense, but I kinda don’t give a shit about what Dan Lyons has on his home screen). This of course, could be built as a third party app – just recently, I was discussing something similar with a friend about automatically slicing and parsing Home Screen screenshots to programmatically determine popularity (err, someone with some spare time go do that, OK)?

Now granted, social has never been something that Apple has been any good at (or even understood, really), but hey Palm, isn’t Facebook sync BUILT INTO YOUR PHONE ALREADY? (yes yes, having a working store and err, enough apps for discoverability to be a problem probably takes priority). (Note: even if you don’t have a social network, you could do something clever w/ opt-ins based on analysis of your active address book or something like that – it doesn’t have to be invasive, just a one time click to opt into the system either as an individual or even as an anonymous/aggregate fashion.)

The attention network aspect is just one potential solution (albeit, the one that to my mind gives the most bang for the buck). Along the social lines, there are two other paths to explore – the activity stream – having a view to see what your friends have just installed, starred, reviewed, etc. and on the other end, aggregate stats of usage – you’d probably get a pretty good ideas of which apps were worthwhile if you could see what apps were most used during the day (either in opens or in minutes). This could also be applied to other aggregates, like the global population, or to clusters (recommendations: people who used the apps you use also use these apps).

The last low hanging fruit (off the top of my head – I’m sure there’s more but I’m headed to bed now) is in how badly reviews and ratings are collected. Apple beats the competition here by both allowing the easiest removal of apps (by comparison, app removal is pretty painful in both Android and WebOS) which has a rating (but no review) roadblock. While better than nothing, the uninstall review roadblock is still fatally flawed. Because the ratings are only collected on uninstall, and reviews multiple clicks away (also after a search step, since there’s no list of installed apps), you inevitably end up with both skewed ratings (of primarily the people who by definition didn’t like it enough to leave it installed) and skewed reviews (those that loved or hated it enough to go through the huge pain of writing a review).

You could try to mitigate these issues by including options to rate/review whenever you’re updating, or even with an opt-in that might bug you say on the 10th time you opened an app. Hybrid solutions with the previously mentioned approaches could involve having active recommendation/rating requests through your network (to my friends that have installed this app, do you like it?) or, probably more simply by getting rid of manual ratings and switching to showing the aggregate metrics that actually matter: retention rate, opens and minutes used (per day, totals, graphs) as “ratings”. These have the bonus of also being enormously useful to developers and being completely passive to end-users, which is good both for the data quality and for the user experience. (The self instrumentation potential is also interesting.)

None of these ideas are rocket science, but I haven’t really seen much written along these lines, which is just been a bit surreal to me because it seems like no one has been really acknowledging how sub-optimal the current app discovery experience is. (I can’t be the only one that feels this way, can I? Does everyone just discover news apps through NYTimes ads and Lifehacker posts? We’re thankfully past the “have to show all my friends this (not really) awesome new app” phase, right?)

Lessons from Android: Unintended Consequences (or How to Kneecap Your Developer Community)

An interesting clusterfuck has been brewing within part of the Android Dev Community – how serious of a long-term effect and what ultimate spillover it will have remains to be seen, but I thought it’d be worth gathering some notes about this as it develops. It started yesterday as something, that on the surface, only effected an important, but miniscule percentage of Android users, but that over the course of a day, has blown up into something may actually have potentially long-term consequences on the Android platform as the open mobile platform of choice.

Yesterday, Cyanogen, an Android community developer who maintains the most popular (and arguably best) alternate Android firmware, CyanogenMod, mentioned receiving a cease and desist from Google Legal.
Alternate firmwares (or custom ROMs) are along the lines of the custom WinMo firmwares that enthusiasts have been putting together for years (and in fact, there is at least some community crossover, including some shared forums). I only recently discovered CyanogenMod after complaining to the one Android superfan I know about how slow the Android phone I had was, and it was to me a night and day improvement over the stock firmware – performance went from unusably laggy to downright zippy.

Now, while Google is obviously within their legal rights (the C&D was specifically about redistribution of their closed source components), honestly, I’m rather baffled by this. It just doesn’t make any sense from a practical perspective – these apps are distributed with all the phones that the Cyanogen firmwares can be installed on, and are mostly used by a small set of the platform’s most dedicated enthusiasts (low tens of thousands at most, less than 1% of the Android userbase) – and of course, by a select few hobbyist developers putting in an inordinate amount of time in maintaining the firmwares and supporting those users. Not only is there no upside in attacking this community, but I can’t picture any scenario where there would be a net-positive outcome for Google.

As you can imagine, once word spread about the C&D, a community reaction was inevitable. A petition app was quickly put on the Marketplace (not the worst idea, honestly), and there were a few mentions in the more general tech news, although I haven’t noticed a big splash (say on Techmeme)… yet. That may change soon, I believe, as the fallout is now much bigger than inconveniencing a few “modders.”

Earlier today, Dan Morrill posted an official position statement on the issue. His statement about redistribution of closed source components seemed straightforward enough, but the implications are still unfolding. It turns out that by explicitly outlining the legal boundaries for closed-source components, we learned that not only core parts of the Android experience (like the Google Mobile services and Marketplace app), but also parts of the SDK and other base components are also protected. This news doesn’t just kill custom ROMs, but potentially makes Android as an open source project not viable at all. From Cyanogen’s Twitter stream:

@crazywizdom it’s pretty much like a bare bones linux install without the google bits. no contact sync or anything like that. #

From what they explained to me, you are not even allowed to copy the proprietary applications from your device. #

@gacktoh but you can’t distribute the market app. And it relies on the Google Mobile services anyway. #

I’m trying to get clarification now on what can actually be included. There are things in the SDK that aren’t in AOSP. Very confusing. #

Oh yeah, one last tweet before I violate the don’t-tweet-while-drunk rule. Nandroid is probably illegal. Awesome huh. #

All this woe (that’s counterproductive towards Google’s interest even if weren’t a PR, and now full on developer community nightmare – the custom firmware releases brought steady streams of improvements to tide over the true believers to what has been thus far, a somewhat lacking software product), probably set in motion because some PM got wind of the v1.6 Marketplace app being on the phone and got in a snit, setting the legal wheels in motion. And poof, over the course of a day, a cascade of events leading… who knows where.

Which is not to say that this can’t be fixed. The Google folks (even the legal teams) are smarter and more agile than most – if this is a priority, there are many ways to patch things up, from offering some sort of non-commercial redistribution terms, or having the Android team announce that they’re working with the community to make sure that they’re making it a priority to make sure that custom firmwares can be installed w/o touching the proprietary APKs, or that the AOSP is useful as an end-user installation (both of which jbqueru at least appears to already be moving on).

As it is though, it appears that Google has just shat on it’s biggest enthusiasts, and has given a good cause for those who are supporting Android as an “open” alternative to actively consider how far that openness extends (and realize how ostensibly “open source” Android really is). And of course, it’s a shame that there won’t be any more CyanogenMod builds. Still, this has been pretty fascinating to watch unfold, and should be of interest to anyone managing developer communities or trying to create an “open” platform…

(If you’re interested in following the conversations moving forward directly, the Twitter streams of cyanogen and Android developer jbqueru seem worth following.)

UPDATE: To some degree, this will probably blow over, since over the weekend Cyanogen announced he will continue w/ his work (after developing a new backup procedure to allow backup and re-installation of Google apps and with the inclusion of an alternate marketplace). Still, these are the types of incidents that chip away at social capital and reputation (until suddenly one day, the public no longer gives you the benefit of the doubt and any action taken gets looked upon in the worst possible light) – not to mention the amount of ultimately, pointless (or at least, repeated) man-hours that will be spent engineering a technical workaround to a policy problem.