Episode 176 of The SitePoint Podcast is now available! This week our regular interview host Louis Simoneau (@rssaddict) interviews Paul Kinlan (@paul_kinlan) about the Web Intents API from Google and where it’s going.
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
SitePoint Podcast #176: Web Intents in Depth with Paul Kinlan(MP3, 22:47, 21.9MB)
Episode Summary
Louis and Paul discuss how the Web Intents API is being worked on at the W3C and other groups, what it will mean for web apps and browsers, and how this could even extend in the future to working with other devices in your home.
Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/176.
Interview Transcript
Louis: Hello and welcome to another episode of the SitePoint Podcast. Today in the show, I thought it would be a good idea to delve a little deeper into a topic that we’ve covered in the past. So, a few episodes ago on the podcast, we talked a little bit about Web Intents, which is a new browser API specification. At the time, it had just landed in a release of Chrome, and we talked a little bit about what it was.
But I thought it was a really interesting topic and worth going into more depth. So, today on the show I have with me Paul Kinlan, who’s a Developer Advocate at Google, and who blogs and talks a lot about the Web Intents specification, just to go over this a little bit in more detail. Hi, Paul, welcome to the show.
Paul: Hi. Thank you for having me.
Louis: It’s a pleasure to have you.
Paul: Yeah. It’s good to be here. I’m currently in L.A. I normally am based in London. So, yeah, my time zones are all pretty crazy.
Louis: Yeah, well L.A. is a little bit easier actually for us here in Australia to coordinate with. GMT is the worst. It’s always exactly the middle of the night whenever we’re awake in Australia. Well, it’s great to have you on the show. So, before we dive in maybe for anyone who hasn’t heard the previous episode – or even people who have because my understanding of Web Intents was, at the time, fairly limited, so I probably butchered a few things. Do you want to talk a little bit about what the Web Intents specification is and what its role is in the modern browser?
Paul: Yeah. Web Intents is a specification that we’ve been working on with kind of partnership with the W3C. It’s still kind of in a very kind of early, experimental stage at the moment. It’s by no way an official standard just yet. But it’s something that we’re working on to try and make it easier for developers to build connected web applications. Kind of the thing that we find at the moment is when people build applications they’ll talk to another web app, they do a whole load of server work to kind of get two apps talking together, or they use kind of JavaScript widgets. There’s no consistent API to kind of connect those two services together. But also at the same time, there’s no kind of one consistent way of being able to plug in your own preferred service to talk to another application. So, if you were on a website and you wanted to share a link to, say, Google Plus and it wasn’t on the page – but only Twitter and, say, Facebook or some other social networks are on there – right now, there’s no other way than getting the developer to actually implement that integration to, say, Google Plus into their site.
Web Intents is designed to kind of mediate that problem away from getting the developers to have to build those complex integrations in, and rather replace it with a service, which delegates to the browser the list of services which the user might want to use for common actions across the web. I think the most common ones are Share, Edit, Pick, Save, and those types of things. So, if you want to save a link to your preferred social network, then it’s just one common action. In theory, it’s one button, rather than, say, 20 buttons on the web.
Louis: Right, so whereas at the moment, if I as a user want to pick a photo to use for my avatar for a new web service, my options are pretty much, either the developer has already integrated with, say, Facebook to get my avatar from there? Or I go rummaging around my home folder, find the file, upload it myself? What Web Intents is supposed to do, for the way I understand it is provide a way for the developer to say, “All I want to do now is allow the user to pick a photo, and anything else that says it can provide a photo, we can integrate with that as long as it provides it in a predefined format.”
Paul: Yeah, exactly. That’s exactly right. Pick is actually one of the strong and kind of unknown Web Intents we’ve got. Pick and Save are quite complimentary. You might have a Cloud storage solution, whether it’s Google Drive, Dropbox, box.net, all these types of different services. When you want to pick a photo, you might have it on Dropbox.
So, you want to bring into your profile page on Facebook or different types of services, right now, unless the hardcoded integration has been done to those services, you download the image to your home directory. Go back to the other application, go and find the image, and upload it through. So, yeah, that’s a really good example of what we’re trying to do with Web Intents, is trying to solve that whole kind of set of steps of trying to get either the integrations in or having to download data into an intermediate place on the user system to upload it again.
Louis: Right. So, the idea obviously is to try and allow different web applications to communicate with each other via some common actions without necessarily relying on the developers to integrate with every possible service out there.
Paul: Yeah.
Louis: That relies on the idea that you have this set of common actions that are defined. Does the Web Intents specification – is it limited to a certain number of actions, or is it open? Are there new ones being added all the time?
Paul: Yeah. So, this is actually kind of quite interesting, really. The actual Web Intents specification doesn’t kind of mandate a specific set of types of actions that can be performed. The Web Intents specification is really just purely about the conduit, the way that the browser will mediate services, and then deliver the data between the client and the service application. So, what we’re trying to do is that we’re trying to document and kind of manage a set of actions, common verbs, things that people do on the web on webintents.org.
So, the idea is that the specification on the W3C is kind of basically saying, “This is how the data will be delivered.” It doesn’t care about the actions and those types of things at the moment. What we’re trying to do is webintents.org is trying to be a little bit more open and easier to manipulate in the sense of defining new actions and common verbs, and that’s where that’s documenting those actions. So, on webintents.org we have Share, Save, Edit, Pick, Subscribe, and View as our kind of six core actions.
There’s nothing saying that there won’t be any more actions. It’s just that we think we’ve got six really good kind of high level things that people do on the web, quite on a common basis from common use cases. If people want to try and define some more, then we’re trying to do that around the webintents.org process while on the full standards process, if that makes sense, via the W3C.
Louis: Right, and within each of those actions, are there different ways of dealing with different kinds of data? For example, sharing a photo versus sharing a link how does that handle?
Paul: Yeah. So, that’s actually kind of diving a little bit more into the spec, I suppose. So, what normally happens is the client application will ask the browser for a list of services that support their ability to share something. By default, you could just say, “I want to share anything,” and any service that supports the Share action will be listed. What we’re trying to encourage, and we’re trying to push developers to implement is be very specific about the types of data that you want to, say, share or edit, or pick from another service.
What you have on the Intent specification is a data type. At the moment it’s a mine type, so if you say, “Well, I want to share an image to your example,” you don’t want Twitter.com to potentially be in that list, because it doesn’t… Well, it does now, but in the past it didn’t support the ability to directly share an image. It was like really text and links. So, you might say, well, TwitPic or different types of image services, well they support the ability to share images, but they don’t support the ability to share text or videos and those types of things.
So, by specifying the data type of data that you want to be able to perform that action on, you can kind of get a list of services which are much more able to handle the user’s intent essentially. So, inside each action we’re going to try and document, especially on webintents.org, the best practices for kind of manipulating the data individual types. So, the way that you handle and the types of data that you pass for an image will potentially be different for an audio file or a video file or a link, or a PDF document and those types of things.
There might be some core common attributes, name, file size and all those types of things. But when you think about a link there’s no point in specifying a codec, for instance. But if you had a video file or an audio file you might want to pass the type of codec in through that extra piece of metadata that you send through to the service.
Louis: Right.
Paul: So, we do have those types of options available. It’s kind of a completely open system, which means that we have to be quite diligent in the webintents.org best practices and the best practices documentation to tell the developer exactly what to expect on either side of the story. So, the clients on what to send to the services and what services should expect to receive from the clients.
Louis: Right. I guess it’s interesting because it’s open-ended because you don’t necessarily know what types of applications or what types of data or user content are going to be shared between applications. It’s hard to predict in advance, so you have to fall back on this more. It reminds me a little bit of the way micro formats work, in sort of – it’s more of an agreement between the application makers trying to make things work together than a formalized standards process.
Paul: Yeah, exactly. I think when you get into a standardization process it gets a little bit more complex, a little bit more longwinded. You get very precise semantics, but what we’re trying to say is that we’re going to have a common set of things that are probably going to be quite common across all types of data that we want people to try and do and use to pass across. Then as we see the ecosystem grow and people use it we can have the flexibility to go back and say, “Well, we didn’t include dimensions in the image file.”
It’s quite an open-ended format in the sense of when you’re sharing a type of data we’re trying to describe best practices for the types of data that you’re going to pass across the wire, between the browser applications. We think we’ve defined a good set of attributes that you will want to pass across. We’re just preparing some documentation to go to the W3C group just to kind of, right now, basically tell them kind of where we’re thinking of going with the data types that we’re going to pass.
Because originally, the very first draft of the Web Intents specification we were literally just passing raw blobs or URLs between two applications. A lot of the feedback that we’ve got from developers is actually, we need more information than just the raw data. So, when you pass a blob between two applications it doesn’t actually include things like the file name or any codec information and things like that.
So, what we’re trying to do is we’re trying to be a little bit more open-ended in the sense that when we have these two applications, we’re going to define some basic common attributes, the URL to where the data is, or maybe the actual raw data itself inside a blob. But then inside the webintents.org documentation, also describe some best practice attributes that users and developers should expect to be on the data payload.
For instance, if you’ve got an image you might want image dimensions inside the actual data payload outside of the actual data body itself because the application might want to inspect the data before it actually has to load it and pass it and do some of the stuff with that. Well, actually inspect the data type attributes rather than the data first. So, yeah, it’s kind of open-ended. It’s quite open-ended in that sense.
The great thing about this is that we can take a lot of the feedback from the developer community as this is building and people are starting to implement it inside their web applications and then integrate that back into the best practice documentation. The actions and the types themselves are definitely outside of the specification process at the moment.
Louis: Right. That leads on perfectly to what I was going to ask next. You were just speaking a little bit about it starting to be used and adopted by web developers. What are some examples of sites that have sort of taken the lead and started implementing features using Web Intents?
Paul: Yeah. So, it’s actually kind of easy to have a look yourself. If you invoke an action via Web Intents inside Chrome you get a list of applications that either you’ve got installed or are suggestions from the Chrome web store itself. So, we’ve got a couple. I mean, we’ve got WordPress in there. I’ve written a whole load of bridges to services. So any service that has an API if they don’t directly implement the Web Intents specification you can actually build an API that might integrate with the Web Intents API to integrate with their service.
But if you actually invoke an intent from Chrome, what happens is you get a list of services that you have installed. You’ve also got a list of suggestions of services that the Chrome web store knows can fulfill this action. So, let me just jump into the Chrome web store and we can get a little list out, which is kind of cool. WordPress is probably the biggest, people we know so far. Psykopaint has got some edit integration as well, which is pretty cool.
Then we have RSS Feed Reader, which is a developer. I think he’s from Yorick. A little bit of backstory about RSS feeder. We recently integrated the ability to view RSS feeds inside Chrome in your preferred applications rather than just view in the XML. The RSS Feed Reader guy, he’s got 189,000 users now from his application, which I think is up 100,000 users from the time that we implemented and kind of deployed the View Web Intent to Chrome.
Louis: Right.
Paul: So, he’s got some good usage out of that. It’s pretty good. Then we’ve got a couple of other people going on. But because this is experimental at the moment and because we haven’t got all integrations inside Chrome that we want just yet, I’ve kind of been doing some of the integrations to things like Blogger via an extension, Instapaper, Gmail and those types of things. But that’s because they open and offer a third-party service, an API that you can integrate via Web Intents.
They don’t necessarily support Web Intents directly, but because they’ve got an API you can build that yourself. So, as we get more applications more and more people are going to come through and start to integrate, build web applications that support Web Intents. So, yeah, it’s going quite well so far.
Louis: Right. On the browser side outside of Chrome, is there movement or interest from other browser makers in implementing this?
Paul: There’s a lot of talk at the moment going on in specification groups and because this is kind of quite early on I think a lot of it’s going to be led by the success of implementations and things like that as well. We’re actively working on the groups with the WATWG and the W3C themselves to actually make sure that we have a common consensus and standard that other browser vendors can implement.
We’re actively talking to them and we’re all going through, I suppose, the motions of finding out kind of what the requirements are for each individual vendor’s needs for connecting applications together.
Louis: Right.
Paul: So, right now it’s Chrome. The interesting thing about Chrome is that it’s built on the back of Web Kit and all the work we’ve been doing has been going into Web Kit. So, feasibly it’s possible for another browser who’s based on Web Kit to implement Web Intents because it’s common code across multiple browsers. But those vendors have to choose to implement it. It’s not going to be on by default and available to Web Kit straight away. They have to do some little work in the back end to kind of store the registrations and things like this. But it’s in Web Kit so feasibly other browser vendors who implement the Web Kit interface can actually support Web Intents if they choose.
Louis: Right, and in the case of Chrome the idea of Web Intents is, as you mentioned, a little bit sort of backed onto the Chrome web store. So if I don’t have an application registered to handle a specific intent it’s easy for Chrome to provide a list of suggestions from the Chrome web store?
Paul: Yeah.
Louis: But in the event where you look at another browser that doesn’t have an app store sort of attached to it, how would that work? Is it, you would go to a website like Gmail and it would provide a link to tell the browser that it’s capable of handling a type of intent, and once that’s registered then the browser remembers it?
Paul: Pretty spot on, actually. When we did the first proposal for Web Intents we basically said we believe that the biggest benefit that we’ll get from Web Intents is not just the ability to connect two applications together and deliver the data. It’s actually to be able to understand on the web openly the capabilities of applications.
So, we proposed an intent tag, which basically describes the action type, the verb essentially, the thing that the user wants to do – share a link, edit things, and the data type as well. So, the idea is that a user agent or a browser or a search engine could come along and aggregate web applications’ functionality, which they can’t do at the moment. There’s really no way to discover the capabilities of applications, like kind of at a semantic level.
Louis: Right.
Paul: So, the interesting thing is we have this intent tag, which we’re still talking with the W3C and kind of all of the browser venders at the moment to try and work out their semantics. Because there are thoughts that it should in link rel or meta tags, and we’ve got very set reasons why they shouldn’t be and we think a succinct tag that just is there to define the capabilities of applications is a better solution. But that’s the goal, is we want browsers, search engines, all these different types of people to be able to understand the capabilities of applications and not really just to be siloed in the Chrome web store.
The reason why we use the Chrome web store right now is because it’s already got a whole set of applications in there. Developers inside the Chrome web store, they want to be able to find other applications that support kind of capabilities that they need themselves. It’s great in that it’s at the Chrome web store, but ideally we would have it inside another search engine, or it doesn’t matter.
Because I know Mozilla are quite big on having their own stores and having kind of the ability for a user to say, “Well, I’m going to start up a web store and you can kind of deploy your applications in here.” If you can understand the capabilities of applications, then there’s absolutely nothing stopping you from doing that inside those types of stores as well.
Louis: Right. That’s actually really interesting.
Paul: Yeah.
Louis: So, what you’re saying – correct me if I’m wrong here – is that maybe in some way I mentioned earlier that some aspects of Web Intents reminded me of micro formats and this is perhaps another point in the same way that the Google search engine can use micro formats to provide things like rich snippets in search results. If a web application provides an intent that it’s capable of handling in a common specification, then there’s nothing stopping search engines from finding all the sites on the internet that are capable of editing photos via Web Intents?
Paul: Yeah. I think that’s a key point is if you search on any search engine for image editing applications, you don’t get a list of applications that can support image editing. You get kind of reviews and a whole load of things like that. So, if you can start to understand the capabilities of applications, you’re quite right. You can do those types of things.
Louis: That’s a really interesting point, and one that I had not considered before. That’s really definitely not only as a way of allowing applications to integrate, as you said. But also just to allow them to describe their functionality in a machine readable format, as it were.
Paul: Yeah, exactly. There’s also talk about, do you want kind of accessibility engines to be able to understand that they’re interacting with an application and not just a website, and things like that as well. So there’s the opportunity for it to kind of just go beyond search engines and you go into different types of user agents that need to understand that they’re interacting with applications.
Louis: Right. That’s a really interesting point. So, I want to close just maybe stepping back and getting sort of a bigger picture of you. You’ve been working on Web Intents for some time. What are you most looking forward to in the world of Web Intents and what’s most exciting to you in this space?
Paul: So, my whole goal behind Web Intents, and it’s a relatively long story and it’s kind of interesting. I was on a plane two years ago and I was going between Moscow and Prague, I think with Mike Mahemoff at the time. We were talking about the ability to try and connect applications together. It turned out there were a couple of people in Google as well, also kind of trying to think about the same thing as well, which ultimately led into this idea of, “Well, we think we can build this into the browser.”
The ultimate goal for me was I just want to make it easy for applications to be able to connect to each other. Right now we’re starting with web applications. So we have two applications inside the browser and the only way that they can easily talk to each other at the moment is going through a server. What we’re saying with Web Intents is, “You have these two things in the tabs and they’re right next to each other on the user’s machine. Why can’t we send the data between application and service and then send it back without even having to really touch the server if we don’t want to?”
That’s kind of cool and that’s what we started off with when we were talking about Web Intents. If you look at the discussions that happen on the public Web Intents group, and the W3C specification, the members of the W3C group, they’re kind of interested in going a little bit beyond just kind of the web browser, if that makes sense. So, what they’re trying to say is that if you have an image or a video inside a web page, why can’t you interact with the devices around your computer, around where you are right now?
So if you’re on your home network and you’re connected to an internet connected TV, why can’t you just send the video that you’re looking at on your webpage directly to the TV? Those types of integrations which we can enable through the discovery mechanisms of Web Intents and the ease of being able to deliver data between two services. That would be really cool. I mean, there are a whole lot of things I can’t even think about at the moment which we could potentially enable around the house.
So, you can stream music to your home media center. You can send a video to your TV. There are a whole lot of things that we’re looking at on kind of the internet of things at the moment which could be, in theory, kind of hooked up with and UPnP and the Web Intents kind of working together. So for me, the kind of jumping outside the browser is really exciting and kind of one of the areas where I’m not very experienced in.
But some of the guys who’ve been talking about it on the W3C, it could be a game changer and a complete step change from the way that we’ve developed applications that interact with our surroundings. So, there’s a good potential around that, I think, at the moment and it’s quite exciting to see.
Louis: That is, indeed, very exciting stuff. I really look forward to seeing what the future holds in this space and I want to thank you very much for taking the time to come on the show and sort of clear up some of these concepts for me and for the listeners.
Paul: Yeah. Thank you.
Louis: If listeners want to keep up with Web Intents or with your work, where should they go?
Paul: Cool, so we have a couple of places that you can go to find out what’s happening. I try to do it on my blog Paul.Kinlan.me or my Twitter account or my Google Plus page. My twitter account is @Paul_Kinlan. I think the best place to go is, if you’re really interested in the nitty gritty of the specifications it’s Public Intents on the W3C. If you just want to know how this can help you build applications and kind of see examples and other applications, and all this type of thing, we’ve got a Google Plus page, +Web Intents, where we try and post a couple of items a week which are interesting to developers as well.
So, if you’re really interested in what’s happening there, hit us up on the Web Intents. The biggest thing for me is this isn’t about kind of us thinking, “We’re going to get this right to start off with.” We need developer feedback and developers building on this application API, testing it out, telling us what works, telling us what doesn’t work so that we can help refactor the API. The thing that’s happened with Web Intents right now is that if you’re actually on the specification group there are some changes going through that have been directly fed back from real world usage from web developers, not standards implementers, web developers to make this API better.
So, the more feedback we can get from people building on top of this API, the better it will be for developers in the long run. Just get in contact with us however you can. That’d be good.
Louis: Absolutely. Well, thanks again Paul, it’s been great having you.
Paul: Well, thank you very much.
Louis: Thanks you.
And thanks for listening to this week’s episode of the SitePoint Podcast. I’d love to hear what you thought about today’s show, so if you have any thoughts or suggestions just go to sitepoint.com/podcast and you can leave a comment on today’s episode, you can also get any of our previous episodes to download or subscribe to get the show automatically. You can follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m, and you can follow me on Twitter @rssaddict.
The show this week was produced by Karn Broad, and I’m Louis Simoneau, thanks for listening and bye for now.
Audio Transcription by SpeechPad.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Karn Broad
