I’ve frequently said that for web apps to compete effectively in the world of apps, they need to be integrated in to all of the places that users expect apps to be. Inter-app communication is one of the major missing pieces of the web platform, and specifically one of the last major missing features is native level sharing: Web apps need to be able to get data out of their silo and into other web sites and apps; they also need to be able to receive the data from other native apps and sites.
Atishay Jain on CSS Tricks writes about an area close to my heart, linking:
Hyperlinks are the oldest and the most popular feature of the web. The word hypertext (which is the ht in http/s) means text having hyperlinks. The ability to link to other people’s hypertext made the web, a web — a set of connected pages. This fundamental feature has made the web a very powerful platform and it is obvious that the world of apps needs this feature.
This article is over a year late. It was stuck in my drafts for a long time, yet I think the idea is something that we need to solve into 2018. It also turns out that other issues have arisen in the last year that make it a bit more relevant.
I was in Indonesia earlier in 2016 idly chatting with developers and it came up in conversation that the web is screwed (they were the literal words).
Michael Mahemoff taught me a lot about the possibilities of the web. Prior to working with Mike I built on the web and I understood the benefits such as linkability and discovery, but I never really had a full picture of what would be possible.
One thing that Mike said was “the Web is my API”, where he talked about the being able to expose your site and your data in a page via microformats and other structured data and being able to access it directly from another another browser context, using a simple XMLHttpRequest and the CORS API:
I never got over the death of Web Intents. I always felt that there is still a serious problem on the web, we build silos that lock the user into one web site and we don’t connect our apps together to build richer experiences. We have links that allow us to navigate to another site, but we don’t connect our apps to functionality that we can use in our sites.
I was writing about Service Discovery the other day and I have some thoughts about how we can do inter-app communication on the web more effectively than what we can today.
Interactions between web and web, web and apps and apps and web is something that many of you may know that I am passionate about, but it is incredibly hard and using the intent syntax in Android is a great start but has huge problems because it is not portable.
I am passionate about making web apps discoverable and interlinked. It is one of the reasons why I created the very first Web Intents prototype and then worked on trying to get it standarised and implemented as WebIntents.
Web Intents as we know it today failed (it still hurts), yet I still think about it a lot.
In my recent post about SLICE I mentioned that inter-app linking is MIA on the web.
Chrome just got Web Intents support in Dev and Canary builds (18 onwards). This is a huge milestone and I am very excited by this first step along the path of building a more connected web of apps.
A lot of developers have asked me how to get started as it seems some of the demos on http://demos.webintents.org don’t register correctly. I have a good answer for that - in short: Chrome doesn’t yet detect the intent tag, instead applications currently can only register their support for an action such as “share” via the Chrome apps manifest.
As of February 1st I have been at Google for two years! Yay! It has been an amazing time and I am truly honored to work for such a company.A year ago (+1 week) I wrote about my first year experiences, it was pretty crazy in my first year, not only did the scale of the work hit me overwhelm me, but so did the sheer number of excellent engineers and colleagues.
We have a huge problem on the web today. If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye?
About 2 months ago I announced to the world a project called Web Intents (http://webintents.appspot.com/) as a way to allow client to client service discovery and communication over existing supported Web technologies, that is IFRAME's and SharedWorkers. There is a definite problem on the web that if you want to talk to an app, you have to integrate your client and service with 3rd party services. This is bad for the user, your application imposes limits on the services you let the user interact with.
As always, I am a little late getting a blog post out, but here is my year in review (a very quick summary). I am going to post a "Tech Review" of my thoughts next. The most important thing that happened this year for me is the birth of our second boy (Benjamin) on the 28th of June - he is doing well and is a very cheeky chappy. It is pretty amazing watching kids grow up and learn to do things.