Blog Post

How the Email Inbox Can Become An App Platform

Google (s GOOG) recently opened the floodgates for business services to integrate with its Google Apps platform — enabling them to get broader distribution and offer single sign-on integrated services within Google’s corporate hub. One aspect of the announcement flew under the radar: Google’s future plan to allow apps to embed themselves directly into email messages. Google calls this “Gmail Contextual Gadgets,” and promises a limited group of tester developers will get access “soon.” That previews a future where email is rich, dynamic and integrated with services across the web — AKA an app platform. The implications could be pretty huge.

YouTube embedded in Gmail

Google has already enabled similar functionality for some of its own services within its free consumer Gmail product. So when someone sends a Gmail user a YouTube URL, they see an embedded video rather than just a link. Imagine if the same thing could be true for other services. The email message itself becomes a mini browser window rather than a static block of text and images.

Instead of getting another annoying reminder to click through to RSVP to an Evite, the email could pop to the top of your inbox, load time-sensitive information dynamically, and allow you to respond directly without opening another page. Instead of getting piles of separate alerts from Facebook alerting you additional comments on some random post, you could load up the site right there in the frame of a message and respond.

That vision of an inbox that actually makes sense of Evite and Facebook isn’t what Google is after — yet. This is less about making email social and more about making corporate email rich and dynamic. Contextual Gadgets will be available for only “business-related” developers and only for users of the Google Apps product, said a Google spokesperson.

This isn’t a new concept. Om titled a post in 2007, “Is Email the Ultimate Social Environment?” after meeting Xoopit and Xobni, which added things like context and better photo viewing to email, respectively. Back in the bubble era, a company called Zaplets that made “email a platform for interactive applications” raised more than $100 million. Xobni later acquired the Zaplets IP. (Xoopit was later bought by Yahoo for about $20 million and now it’s a widget within Yahoo Mail.)

Xobni sidebar in Outlook

Google going to business users first “is not a mistake,” said Xobni founder Matt Brezina in a phone interview. “Context becomes really important inside the enterprise.” Xobni has been long an Outlook-only product, a little piece of software that runs as a sidebar inside Outlook with a bit of Internet Explorer to bring in contextual information about email contacts and trends from the web. (It recently added support for the BlackBerry.)

Brezina’s justification: “Outlook has 500 to 600 million users who haven’t seen much innovation but have a lot of engagement. Those people’s time is worth a lot of money.” So it makes sense that Google, which is facing off against Microsoft’s (s MSFT) business suite, would want to go for that market first.

Startups like Gist, Rapportive and Etacts are taking the same business-centered approach, with their context-for-email products falling into the category of “social CRM.”

Appirio PS Connect in Google Apps

One company that’s already been able to play around with Gmail Contextual Gadgets is Appirio, which built a demo that shows how you can manage employees and customers with a solution built on Salesforce’s (s CRM) cloud platform. Watch the screencast here.

It basically looks like a live attachment appended within the body of an email. (The Google spokesperson said that if developers want to learn more they should come to an instructional session on Contextual Gadgets at Google I/O in May.)

I know, I know…do we really need another app platform? With every last square inch of turf declared to be a platform, the appstorification of technology inspired by Facebook and Apple is almost complete. But email still deserves to join the party.

Still, this isn’t wide open space. Email will be a bit tricky to innovate around, given how dependent and immersed we are in it. For instance, messing with linear, chronologically ordered messages in order to bring relevant ones to the fore might do more harm than good. Making messages contain dynamic information might confuse our dependable search and foldering habits for organizing information. But I’d be happy to have an inbox that understands and integrates the world around it.

Related content from GigaOM Pro:

Email: The Reports of My Death are Greatly Exaggerated

21 Responses to “How the Email Inbox Can Become An App Platform”

  1. Isn’t it strange that functionality is still defined around transport protocols: the battle between XMPP and SMTP. Absolutely laughable. Why can’t we create a single interaction point and let the system “under the hood” sort out what transport to use to glue that together. “Just imagine it is wave and nobody goes there”. What is needed is a universal inbox. If new protocols emerge (like Blog APIs or Twitter or [insert-your-favorite-protocol-here]) the inbox assimilates it. Wrote about it a while ago:

  2. It sounds promising, an intelligent inbox, with no links but direct connections to sites and programmes, but is this really going to work? I am not quite sure about that. The best time-saving plug-in I know is lookeen for Outlook, searching everywhere you want. An intelligent inbox only works when developped by intelligent human beings…

  3. The Q&A portion of the SxSW 2010 panel “Email: The Next Frontier” [1] was lively. The panelists from Gist, Yahoo, Threadbox, and Cisco (Postpath) all weighed in on inbox problems during the panel itself (feel free to search back channel arcives) but were light on solutions… and plentiful on suggestions.

    My question was simple:

    What would you do if you took a Wave Protocol (~XMPP) approach instead of continuing to muck around with SMTP, MTA’s, and MUA’s (including the snazzy web ones)?

    The responses were fascinating. Most of the panel was heading towards XMPP. It was just really hard to get them to say “Wave Protocol”..

    Ah, details…


  4. An important part of making this work is going to be integration between email apps, similar to what Harmony does. For example you can be working on Outlook and assess all your Google docs at the same time, in the sidebar.

  5. Hey Liz, I think you’ve really hit on a growing trend here. As some commenters mentioned, there were grumblings of early innovation in this space 10 years ago. However only 4 years ago (not coincidentally when we were starting Xobni) were the first of the Facebook Generation joining the professional workforce. That did a lot to influence the acceptance of this technology (and influence the people building it). I think this time it isn’t going away as is evidenced by MSFT, Google and others joining the game.

  6. Think the most interesting challenge will be to provide useful info & tools across all email (& other comm) platforms vs. just Outlook or Gmail. Looking forward to the day when platforms are truly open, and it’s not necessary to provide 20 different plugins, altho browser add-ons go some way to solving this.

  7. Zaplets was awesome and it has never really been resurrected. I remember the polling and scheduling items which just stayed right there in a “live” email message. We need more solutions that are delivered straight to the Inbox without having to go poking around the web on additional links, opening attachments in other apps, etc. Understand the security concerns but would hope there is a way to work around them.

    • Zaplets was cool. But with a crazy burn rate. If I recall correctly what really killed them was that they relied on


      iframe> in the HTML of the email and Outlook removed support for that for security reasons.

  8. Microsoft built this functionality into Outlook years ago, and the result was everything we hate about e-mail: SPAM, phishing, distribution of malware, you name it. This functionality has brought down major corporate networks, extorted large sums of money, and caused general havoc.

    We want no part of this until EVERY such message is authenticated, authorized, and encrypted.

    • Agree with you Andy.

      However, I think if we adopt an opt-in approach (ala Labs in Gmail) we should avoid most of these pitfalls.

      Universal adoption is definitely dangerous until we’ve given the proper guardrails for consumers.

      • In the way Google is proposing it, apps will be able to embed in email only if corporate administrators install that specific service on their company’s Google Apps account. I’d like to see broader availability than that but it’s clear that Google is cautiously heeding the history that Andy’s talking about.

      • (responding to both Stuart & Liz, Liz’ comment didn’t have a reply button)

        Then this is a gmail-only offer, and it’s “just” additional functionality on a web page. At least that contains the damage that can be done.

        I’d much rather see an interoperable messaging system with complete authentication / authorization / encryption that can be used by itself or integrated with other tools. Think in terms of being able to use your Facebook identity and friends list to be able to send secure messages to LinkedIn users. Facebook will only allow authenticated and authorized friends to send you messages. That kind of functionality needs to be extended across tool boundaries. But none of these sites will sign up to use anyone else’s authentication and authorization lists. The user lists are too valuable.

    • For certain markets, such as education, this would be ideal. Being restricted to the domain a combination of directed and social functions could be built on top of communication.

      While our product has significantly changed, what we have on the site is an approach to providing a platform for social sharing in education. We looked at textbooks, then eBooks, and wondered why educational content needed to be restricted to the idea of a book. Other powerful capabilities would be implicitly included, calendars for example.