I'm starting a project to document web technologies that didn't become mainstream. For every success story, countless others fade away. I want to explore these untold stories, starting with my own experience with Web Intents. I aim to understand why some projects thrive while others don't, and share these learnings with the community. If you have a similar story, please reach out!
I've been exploring solutions to connect web apps and overcome the limitations of isolated experiences. Web Intents was a good start, but ultimately fell short. The Share API helps, but we need a more general solution for IPC and service discovery. My latest experiment builds on the Tasklets API and Comlink, allowing seamless communication between windows and web workers. It simplifies the complex postMessage API and makes it easy to expose and consume APIs across different contexts. I've created a service discovery mechanism where a 'middleman' site keeps track of available services. Clients can request services based on criteria, and the middleman facilitates the connection. Once connected, the client and service communicate directly, bypassing the middleman. This approach simplifies the developer experience and makes it much easier to build interconnected web experiences. Check out the demos and let me know your thoughts!
I'm excited to share a new, simple API for sharing on the web called navigator.share! It's available in Chrome Dev Channel on Android and allows websites to connect with native apps for sharing. This is a step towards a better inter-app communication system, simplifying sharing and potentially extending to other app interactions. You can try it now on my blog by clicking the share button. I've updated my blog to use it, falling back to my existing solution if the API isn't available. Check out the ChromeStatus page and other linked resources for more information and give us feedback!
This post revisits the UX issues that contributed to the demise of Web Intents. We never adequately addressed the wide array of potential actions and data types, leading to a generic and confusing user experience. Handling data return from a long-running operation in another app proved problematic, especially if the initiating app closed. The lack of an explicit API for expecting returned data, similar to Android's startActivityForResult, further hindered the development of intuitive UI affordances. The open nature of Web Intents resulted in a proliferation of schemas and protocols, making standardization difficult. Users were forced to choose an app for every action, and developers lacked control over how apps launched, leading to inconsistent experiences. Finally, the absence of reliable fallbacks for unsupported intents eroded developer confidence and potentially left users stranded. In short, a combination of UX shortcomings ultimately led to Web Intents' downfall.
I'm still passionate about making web apps easily discoverable and interlinked, even though Web Intents didn't take off as I'd hoped. We web developers boast about the power of the URL, but we're not leveraging it effectively for inter-app linking, which is hindering the web's potential. Recent experiences building a QR code reader and seeing how other apps integrate them highlighted this issue. The web's strength is its zero-install nature, allowing instant access to functionality. However, many web apps erect barriers like landing pages and login forms, negating this advantage. These barriers act like app store install pages, killing the linkability and ease of use that makes the web great. While capturing user data is important, we need to prioritize frictionless usage, perhaps by adopting concepts like "tourist" or "shadow" user accounts. Native apps are exploring app constellations, while we on the web already have the tools but aren't utilizing them effectively. We must allow users instant access if we want truly linkable web apps.
Chrome Dev and Canary (18+) now support Web Intents! Currently, intent registration is done via the Chrome apps manifest (not the intent tag) to allow the user agent to determine available services (including those on the local network or external native apps). The manifest entry specifies the supported action, data types, title, and path. Client-side code remains the same. Future support for declaring capabilities directly through HTML with the Intent tag is planned.
It's been an incredible two years at Google! The first year was amazing, but the second year was even better. I spoke at Google IO, traveled to numerous countries giving presentations, and saw Web Intents become a real project. I even got misquoted on TechCrunch! I also spent more time in Liverpool and worked with developers throughout the UK. I'm excited about the future and continuing to improve the user experience on the web.