A Web Of Apps

It is remarkable to think that we’re in the early days of the app era, when there are already close to 600,000 iOS applications and nearly 400,000 on Android (source: Distimo ). The growth of these app ecosystems has been rapid, exponential and shows no signs of slowing down. As well it shouldn’t: the untapped, addressable market for mobile apps involves hundreds of millions of users. And yet, app discovery remains a challenge. Whether in an app store, on the device itself , or via a third-party service. Whoever cracks the nut of app discovery will have the potential to be the next Google: the search engine of the modern age. The search engine for a web of apps. App discovery is a key focus for a number of startups. Off the top of my head: Chomp , Quixey , Xyologic , Appolocious , AppsFire , Kinetik , and  Crosswa.lk  are approaching the challenge of app discovery in new ways. (And yes, you too, millions of companies I neglected to mention). While that’s a rich topic for examination, it’s not one that can be summed up in a single post. So for today, one aspect of building a web of apps: connectivity. Why do I keep referring to a web of apps? Apps are not like the web – they are not hyperlinked creations that allow you to move seamlessly from one operation to another…or are they? Perhaps not yet. But they could be, if more developers chose to implement this functionality. Using something called “app URL schemes,” apps can communicate with each other. For example, on the iPhone, iOS developers can call up the built-in apps, like the Messaging app, Email app and the Phone app. Apple’s URL schemes are published in developer documentation, but all apps have URL schemes available.(On Android, something similar can be accomplished via “intent filters.”) Apps can launch other apps. Apps can connect to other apps. It’s still somewhat rare to see this in action, but it’s starting to happen. Facebook is probably the most high-profile example of this. In the iOS app, on the left-hand side an “apps” section will link to Facebook apps which also exist as iOS applications. Tap the app in the list and Facebook launches the app on your phone. If you don’t have the iOS version installed, it launches the App Store instead. Clever. Facebook as a portal to the mobile “app web.” But there are lesser known use cases, too. For example,  PhotoAppLink , an open source initiative that aims to simplify photo editing by tying multiple photo-editing apps together . Currently, in order to edit a photo in multiple apps, you have to save the edited photo to the camera roll each time as you move in between applications. But with PhotoAppLink-enabled apps, you simply select another app to use from within your current app. Another example (actually, a potential example): the educational startup KinderTown  offers an iOS app that’s a actually a curated version of the iTunes App Store. Designed to help parents discover kid-friendly, educational apps , KinderTown directs you to the iPhone’s App Store for downloads when you tap the app in question. Imagine if it could also help you find, filter and launch the apps you already have installed on your phone instead of just those you’ve newly discovered. Meanwhile, at AnscaMobile, a recent tutorial for developers took the concept of app URL schemes a step further. Being able to launch an app using a URL scheme is great, wrote  Jonathan Beebe   on the company blog , but what’s  even better  is being able to tell your app to  do something  in response to being opened via a URL scheme. “Think for a moment just how powerful this can be,” he says. “You could tell your app to do different things, or start in a different state depending on the URL string that was used to launch your app.” Indeed, powerful stuff. And sadly under-utilized. The possibilities for inter-connected apps using app URL schemes are endless, but actually connecting them together is still a challenge. The problem stems from the fact that there isn’t a simple way to discover the custom URLs for the apps you would want to link to. This summer, a company called Zwapp attempted to address this situation by launching  OneMillionAppSchemes.com , an initiative which aims to open source the unpublished custom URL schemes for iOS applications. Using a downloadable tool, Zwapp scans your iTunes library to locate the custom schemes for your apps then uploads those to the website. The goal, as you may have guessed by the name, is to collect one million of these app schemes. It’s not quite there – only 15,066 have been submitted to date. Despite the Zwapp’s outreach and call-to-action in the app developer community, what it has implemented is really more of a hack – a way to workaround for the fact that there aren’t better tools available. Whether the usage of URL schemes will ever really take off is unknown. While it’s one thing to launch your own app in creative ways, developers seem to balk at the concept of linking out to other apps. (Send my app’s users, which I fought so hard to acquire, to another app? No thank you!) But just like hyperlinks allowed users to begin surfing through what’s now a seemingly infinite number of pages on the web, linking apps could prove to be a way to  overcome today’s app discovery challenges, too. Top image:  Daniel Y. Go

User-Generated URLs: SE...

Avoid a PR nightmare by protecting your website before someone maliciously decides to put a campaign together that generates links to an incorrect form of your website's URL. ...

Libellous URLs Are Hila...

An interesting story today from Nieman Journalism Lab, pointing to the dangers of URL spoofing. The danger, according to Neiman’s Andrew Phelps, stems from the fact that many news organizations include the text of headlines in their URLs in order to improve SEO. In many cases, the headline text is superfluous, and the URL works just fine without it. The result? A story from the UK’s Independent newspaper that started out with this URL… http://www.independent.co.uk/life-style/food-and-drink/kate-middleton-jelly-bean-2269573.html …went viral, after a prankster tweeted it out as… http://www.independent.co.uk/life-style/food-and-drink/utter-PR-fiction-but-people-love-this-shit-so-fuck-it-lets-just-print-it-2269573.html (Both URLs work just fine.) Embarrassingly, and amusingly, several news organizations including Slate and Nieman itself, fell foul of the prank, assuming that it reflected an error at the Independent. Finally realizing his mistake, Phelps wrote his follow-up story, describing “How URL spoofing can put libelous words into news orgs’ mouths” Well, yes. And no. For a start, the problem isn’t a new one. I remember, almost ten years ago, laughing my ass off when my friend Tim Ireland noticed that the website of British Member of Parliament, Ann Widdecombe could be sabotaged using a really fun URL hack. By changing the text in the URLs of Widdecombe’s photo gallery, the on-site photo captions themselves also changed; with potentially obscene consequences. Secondly, Phelps talks about the “recipe for confusion — and maybe legal issues, if someone can insert a libelous URL into one of your stories and spread it around” but he doesn’t clarify who is at risk from those legal issues. In fact, it’s highly unlikely that a news organization could be found liable for a URL that is hacked by a third party. Generally speaking, you can’t be held responsible for a libel you neither wrote or published. (News organizations can, of course, be liable for URLs they create themselves, as I explained last year ). Really, the biggest risk from URL spoofing lies not for the news organizations but for the pranksters themselves, and anyone unfortunate enough to fall for the prank and retweet a libelous link. This I know from bitter experience. Back in 2003 – still a young, smart-ass columnist for Media Guardian, and editor of a satirical ezine called The Friday Thing – I stumbled across what I thought was a great piece of gossip. A very famous British sportsman – who should definitely not be named here – had apparently been conducting a sordid affair, and had secured a legal injunction to prevent UK newspaper from writing about it. Being a smart-ass, I wrote a column for the Guardian pointing out the ludicrousness of the injunction system, given that foreign newspapers were free to write about the story with impunity. Thinking myself far cleverer than I was, I then wrote a follow up story in The Friday Thing, linking to the foreign coverage of the story. It was at this point I made an idiotic mistake: I decided to include the sportsman’s name in the short URL linking to the foreign coverage. Less than 24 hours later, I received a letter from a very large London law firm informing me that I was being sued for libeling their client, and that they would be pressing the English High Court to charge me with contempt of court (maximum sentence: about ten years in jail) for breaching the injunction. It took a year, and thousands of pounds in legal fees, to convince them to drop the case, on the grounds that I had no money for their client to win in damages. Lesson one: URLs can be libelous too. And it gets worse: in most jurisdictions repeating a libel is considered almost as serious (if not actually as serious) as the initial publication. In theory, anyone who retweets or quotes or simply links to a libelous URL could also find themselves on the receiving end of a libel suit. Lesson two: if a URL seems too funny to be true, it’s probably a good idea not to forward it around.

Google AdWords Display ...

News of this puzzling modification to AdWords has been greeted with a negative reaction from the search marketing community. It's hard to believe the display URL change can possibly benefit Google or advertisers. ...

Designing an SEO Friend...

The proper URL structure helps paint a picture of hierarchical importance on your site as well as your intended keyword focus on pages to the search engines. Oh, and it aids the user, too! ...