That's a great insight, to think beyonds the bounds of the app ecosystem itself. In a lot of ways the mobile is a tool to deliver a service. However, a company has to prioritize and nowadays the app is the first foot forward. It's important to realize the constraints of the system that you're operating in so that you can properly gauge expectations and strategy.
More importantly than 'crushing their innovation brand' (which seems like a small consequence), he headed off a potential competitor who might enter the personal device ring. Well done.
Just a plug because I built it, but branch.io gives this service away for free. We open all the 'black-box' fingerprinting parameters (like match duration) for you to tune as well.
I work at Branch (referenced in the NYT article) which tries to make it way easier for mobile devs to leverage better deep links to stuff in their apps.
Making the analogy to desktop apps is fair, but I think the better question would be why not? The URI scheme registration mechanism in Android and iOS allow the dev to create a new OS level namespace for his or her app and all 'pages' inside. For example, http:// is the scheme for browser app based addresses just as venmo:// is the scheme to address all payments or user profiles in the Venmo app. Why not leverage this technology to make app content more open and easier to access?
Now, if we could just get rid of the app store enforced install process and have apps automatically retrieved and cached, things would be a lot smoother...
> Now, if we could just get rid of the app store enforced install process and have apps automatically retrieved and cached, things would be a lot smoother...
I feel the lack of linking in apps is done partially because of laziness, and partially on purpose. Most apps that are neither games nor utilities seem to be made to control the viewing experience and/or help the authors trick the users into parting with their money. Increasing interoperability seems to be counterproductive if the only reason for your app to exist is to earn a quick buck from the less savvy users.
We just discovered that one a few weeks ago - It was then we realized that we had just dedicated our lives to the premise of an xkcd comic
I disagree with your last comment as you could make the same argument for websites in general - there will always be spectrum of usefulness/scamminess. Utilities or games might not have the concept of 'pages' as a news app or a social photo upload app, but imagine being able to link to specific constellations in the star chart app, the various calculator faces of some popular calculator apps, or a user's city in Clash of Clans. It's going to be awesome.
"imagine being able to link to specific constellations in the star chart app, the various calculator faces of some popular calculator apps, or a user's city in Clash of Clans. It's going to be awesome."
I'm imagining it, and in most of those cases I'm imagining the horrible fragmentation clusterfk that will have to be solved in Yavascript - linking to "some popular calculator apps" (plural) means either providing a mess of links for the user to decide, or somehow guessing which one to show.
Two alternatives that both land in the "NAH GANNA HAPPEN" category:
* "everybody agree on a standard prefix for basic things like calculators" HAHAHAHAHAHAHAHAHAHAHA
* "allow client JS to detect installed apps" see also the detect-visited-sites-with-CSS info leakage for why this would be terrible...
I was actually going to reply something along the same lines. These sorts of services exist on both iOS and Android (can't speak to Windows Phone). Not for the provided example, but for Android, the Intents like you mentioned, and iOS has a similar concept for things like "Apps that are capable of routing/mapping" and possibly other things. Neither of these are done through the example "standard prefix," but both are through by adding some standard permission or key to your app.
I'm familiar with the linking capabilities of apps, at least for iOS (haven't played with Android). I think it's a bit limited, as it currently stands, but I feel like the intent of the url schemes is somewhat different from the idea of linking on the web. On the web, you typically link to open content, whereas I feel like apps tend to be more personalized; seems like linking wouldn't work quite the same. Interested to think more about that, though.
With any group of people, you always have a spectrum of talent and usefulness. I've worked with Stanford CS grads who would shock you with the inability to produce anything useful without handholding and worked with Stanford MBAs that I was surprised could even get their pants on in the morning. The problem is that the admissions process for most of these programs is less about the numbers and more about your ability to network or tell a compelling life story. If you can tell a story that impresses the admission folks, you're likely to get in. Sometimes this is reflective of actual talent, sometimes its a reflection of great story telling.
That being said, there a few incredibly talented and intelligent people in each class that will continue to allow these types of institutions hold the prestige that they do.
Alex with Branch here. Let me try to explain how it works. Basically, we use different technologies in different scenarios with the goal to deliver the user to the app as fast as possible.
First off, the most basic case is where we know the user has the app installed. In this case, we use the standard URI scheme based deep link which opens the app up right away and passes the link data. We also handle the case where they had uninstalled the app, by taking them to the app store.
If we have never seen a user before across our entire network of apps based on our first party cookie, we use a mechanism called fingerprinting. It's commonly used for mobile app install attribution to tell a marketer how many installs were generated from a particular advertisement shown in another app or on a mobile site. Basically, we collect as much information as we can in the browser (time, OS, screen size, IP, etc) before redirecting them to the app store. When the user opens up the app, we generate that same set of information inside the app and send it back to our service to match up with a pending browser fingerprint. In the case of a match, we know that new user came from a particular link and pass in all the data associated with the link. This can happen across install and open. If we have seen the user before, we just match up our cookie to the unique device ID once the user shows up.
The service also comes bundled with a free text-me-the app service which helps pass the link data from a desktop click to the phone and eventually the app.
It's everything that we've always wanted as a linking service for our own apps, plus all the accompanying analytics to measure the performance of your various features. Try it out as it's free. We'd also love recommendations or feedback on how we display the data on our dashboard.
Unfortunately, there is a very low probability of the mismatch until we have effectively seen every device. As our linking service expands, that percentage gets lower and lower. In our experience, the user experience and analytics insight benefit far outweighs the consequence of a mismatch because they are so rare. We encourage our developers not to bundle sensitive data into the links if they use this base case.
If a developer does want 100% match, we have a separate option that can be used with a slightly degraded user experience which pops the browser open really quickly to check the cookie, then returning to the app with the URI scheme.
Dmitri from Branch here. When a user has already had a fingerprint matched once, we can do future matches with much higher certainty, so as more and more users click links and are matched, the chance decreases.
Additionally, as Alex said, though most uses of the links don't require a 100% match rate ("any growth is good"), we do have an option for links which require a 100% match.
I just released an android app to the market last week which I believe will be extremely helpful to those trying to deal with the high gas prices. There have been quite a few studies about how the average driver can save on gas. A study by Edmunds summarizes the results best in an easy-to-read article. Basically, by altering your driving habits to reduce breaking, hard accelerating and speeding, you can see some serious fuel use improvements (one study saw 45% improvement, although Edmunds finds 35%). This is like Weight Watchers for your car, turning that 25 MPG beast to 34 MPG dieter.
The application, known as Open Road: Fuel Economy Assistant will track those behaviors for you so that you can actually measure your results. All you need to do is select your car from the database (or build you custom car) and press Start before you leave on your trip. As you drive, you will see live and trip averaged fuel economy. There is also a display for how much that individual trip cost you.
Check it out and give me some feedback! I love feedback and look forward to incorporating your awesome suggestions.
PS. The iOS version will be released in a week or so. Like the facebook page to get news about its release.
