Agree that its a really big deal. Mobile support is huge.
We actually built the inboxsdk that you are referring to. There are a ton of extensions built using it and >10M end users using apps built with it. We've worked really hard to make sure apps built with the SDK are compatible. If you have any examples of 2 extensions not playing nice, def let me know.
Looking at it now, it's actually mostly InboxSDK extensions that are conflicting with Gmelius and some other custom extensions.
Having 10+ extensions all trying to modify the DOM of one site at the same time is bound to give some problems :).
Curious to see if Streak will switch to this new official way, although it seems that a lot of the stuff you're doing won't be available to Add-ons.
Gmelius is actually using parts of the SDK. But they are really aggressive and do some DOM manipulation. In general we hope that users of the InboxSDK never need to actually touch the DOM ever. The SDK handles coordination across extensions. Ofcourse extension don't have to abide by this and hence the conflicts.
As for Streak, we're planning on a mixed approach. The add-ons from Google support very few UI entry points (at least for now). Streak's entire UI only lives in Gmail so we need a lot more integrations. We'll use the Google sanctioned way when possible and fall back on the extension as we currently have now for the other cases.
First of all, big shoutout to InboxSDK / Streak folks. Our extension, Fyle (http://www.fyle.in) would've been ridiculously more difficult without it.
We're having an issue with Gmelius interacting badly with our extension. Basically, we never enter our messageViewHandler code when Gmelius finds a tracker. Have reached out to them as well.
I also hope this will improve the privacy/permissioning story for gmail add-ons. I believe currently any extension has full access to the page meaning they could read all your emails. For some of them that's obviously required as part of the functionality but it would be great to have more fine-grained permissions for things that don't need full access.
Most successful/useful/business extensions usually request oauth access to the backend Gmail API from the user anyways so its not as big of a concern as you might think.
Looks like it will from the screenshots (https://4.bp.blogspot.com/-HeFnmVgMiJ8/WMDL3f4TQgI/AAAAAAAAB...) - each app will have it's own icon and hooks into emails/threads. I too have built a few gmail integrated apps and this will be super nice and convenient.
Sorry to be the one that has negative feelings about it.
Email is one of those rare concepts that is really hard to change or enhance. I can easily see Google abandoning this feature in 5 years.
People need email service just because of the email function, nothing more than that.
It's concept clearly has some limitations (attachment sizes, layout inconsistencies and so on) but it also doesn't have any deal-breaker problems.
Introducing external services integration to email sounds like taking a huge risk. How people manage their invoices, to-do lists and other stuff is changing faster than ever. These add-ons will require active development all the time to keep themselves up-to-date.
As a developer, I wouldn't risk investing in this feature.
An API that might go away in 5 years is much much better than hacking the DOM. I wouldn't base a business around either, but I can think of some fun and useful add-ons I could build
I've been panned on here before for saying this, but I really feel everyone should leave email alone. As a spec its already so immensely complicated and embedded that any features you add will only be picked up by a tiny percentage of providers.
Imagine if that advice had been taken pre-gmail though. Not everyone loves it, but for most people, gmail's conversation view is far superior to the default way emails were organized before. And it does this while still interacting seamlessly with other email clients.
I don't see gmail as perfect, but that's kind of the point; it's possible we could gain from this kind of experimentation.
Afterthought - archiving and snoozing emails are also concepts that weren't around initially, but can be extremely valuable depending on your workflow. I'm sure there are other similar improvements and additions to be found.
I've come to dislike it more and more. Gmail hides too many details. Thinks like precise timestamps. Things like not surfacing subject changes well enough. Things like a spam filter with immense amounts of false positives. I keep having to fight with gmail in ways I never have to with other mail solutions, to the point were I'm getting very close to abandoning it entirely.
I agree with you on the spam filtering. It would be VERY nice if you could customize the threshold, or even better, have a couple of thresholds, so you end up with a 'definitely spam' and a 'probably spam' box.
I've kind of created that by using spamassassin to filter out really hardcore spam before it gets to gmail, but obviously that's not an option if you're using an @gmail address.
That said, I think we take for granted just how good gmail's spam filtering is. Their ability to 'see' so much email passing through the system gives them a massive advantage there, which they've used to pretty good effect. They catch a ton of stuff for me that SA misses, and very few false positives (but just enough that I can't ignore the folder, unfortunately).
Unfortunately the false positives vary greatly with your mail patterns. For me the amount large enough that even though it also stops a shitload of spam I'm starting to think it's too much of a problem. Just checked right now, and though I've checked my spam folder earlier this month (and emptied the folder), it now has 40 messages of which 9 are false positives. What's more, several of them are from senders I regularly get e-mail from and that I have never marked as spam.
Ha, lucky you. Before I started pre-filtering with SA, I got about 3000 spam emails per month. I can cut out about 2/3 of those with SA without losing any of the false positives, so now I only have to wade through 1000 or so to find the one or two falses. :/
That brutal, but if my false positive rate was that low I'd probably be willing to just tolerate it. What drives me most crazy, is just how hard it is to get Gmail to accept that a given type of e-mail is not spam...
> Not everyone loves it, but for most people, gmail's conversation view is far superior to the default way emails were organized before.
Before gmail, I used gnus (http://www.gnus.org/) to read my email, and frankly the two methods seem pretty on-par (in fact, for over a decade I used gnus to read gmail). The only reason I do use gmail (actually, Inbox) today is because I want to read & send email from my phone, and it's convenient to use the same interface both places.
Honestly, I'm a bit tempted to switch to K9 on the phone & gnus on my computer again. Gnus is orders of magnitudes faster than Inbox or the Gmail web UI.
I had the same reaction as you at the headline, but clicking the article and seeing intuit and salesforce made me rethink slightly. It would indeed be handy to be able to toss a receipt email into quickbooks or a new name on cc into a salesforce contact from webmail. I'm sure there are some other decent uses of the concept.
Nah he's right. They have a history of axing stuff with 0 care about personal or corporate users.
Search 'Google graveyard' , etc.
There may be a huge market, but your dev time will earn income for not many months/years.
I'd rather see my products live longer than that, and me focusing on growth, than constantly trying to restart development just because Google worries much more about their bottom line, than their users.
I don't know man. Right now the hard part is using the tools. It's a pain in the ass. The last I tried FireGPG was the best and it wasn't terribly smooth flow either (no fault of it's own).
I knew how PGP worked, but still accidentally sent around my private instead of public key by mistake the first day I set things up. Information 'wants' to be free; it takes real effort to keep it contained.
Inbox was nifty at first but it positively crawls now. Any input action takes several seconds, at best, to process on a fast machine, sometimes much more. Loading Inbox is about 30s. It's maybe 20x slower than straight gmail classic. Plugins will just slow it more?
12 seconds to load fully here (that's 11.90 seconds too long - can't they store some stuff in local storage or...?) - and of course it's not really usable until it's fully loaded. You could start trying to type but it'll not do anything, or stuff will move.
Opening the 'Updates', er, 'section' with 2 emails in it took 2 seconds, which is silly.
I love the flow of Inbox but I'm seriously considering going back to a local client. Are there any good ones left these days? I liked mutt, but using it with an IMAP mailbox made it a bit clunky. I just need to work /fast/, without crashes, without spam, and preferably with vi keys and programmabil... never mind the last two, I can live with the speed, stability and spam-free parts.
I can't trust Nylas because you have to trust yet another third party with your email, in addition to Google/Fastmail/etc.
AFAIK Nylas doesn't work locally, but through their "cloud APIs". They are not alone in doing this, for example Outlook for Android does it too.
That's not acceptable for me. The email client should only communicate with the email provider. Trusting Google or Fastmail with my email is a leap of faith on its own without an extra third party involved.
I'd also question their business model. If Nylas Mail syncs via their own "cloud", it means it's not free to operate on an ongoing basis, which means it will end up either milking users for ads or die.
> Not really. I wish the Mozilla Foundation would rejuvenate their email client once and for all.
I would love that too. Sometime last year Mozilla enabled donating specifically to the Thunderbird project (which was a long time wish of mine) as opposed to donating to Mozilla as one entity, and I started donating to it. With more monetary support, we could have possibly have it become much better again (native and good Exchange calendaring support without extensions would be my top wish - the current scheme with the integrated Lightning and Exchange Provider is quite buggy).
> I love the flow of Inbox but I'm seriously considering going back to a local client. Are there any good ones left these days?
As I mentioned elsethread, I'm thinking of switching back to gnus. Mutt was awesome too (I used it back when I used vi, then switch to gnus when I converted to emacs).
Gnus is pretty incredibly fast, and hyper-programmable, and as stable as can be. And it'll be as spam-free as the IMAP source is to begin with. Gmail over IMAP still has all the Gmail spam-filtering.
Opera mail is my default client now. I've used basically every client in existence, had to switch from Linux to windows so mutt wasn't an option. Thunderbird would hog resources and become unresponsive on my bigger IMAP accounts (Gmail), opera handles it superbly. No integrations though (calendar or anything)
Try deleting or moving messages in a folder (sorry, "label") with large number of messages in it (few thousand), then you'll never complain about 2 seconds to open something again...
Like you I'm considering ditching Inbox/Gmail. It's getting more and more painful to work with.
Strange, my experience with Inbox is nowhere near that bad. It is noticeably slower than Gmail classic, but load time is ~2s and actions like search take a fraction of a second. This is all on a 2012 MBP.
Gmail is slow to load compared to others. Notably, FastMail. I abandoned Inbox a while ago because of load time. Coming close to abandoning Gmail too. Takes way to long to load. This happens for me on low end laptops AND high end desktops.
If you look at the examples, they all look like adding extra functionality to your inbox, not to the content of the emails you send.
So it doesn't sound like "I'll send you this email that you can only access if you have gmail AND this specific add-ons", more like "when you open an email, the add-on shows relevant information from your internal CRM system as well as canned responses".
This is awesome. I developed Chrome/Firefox browser extensions that connected Gmail attachments with cloud storage in the past, and hacking through Gmail's DOM always threw any SLA we could provide out the window.
It's even better that this will run on Android and iOS as well, which truly makes all the "Gmail extensions" from developers such as myself production-ready.
And just as I completed a WebExtension based integration. Awesome! /s
Seriously though: I was considering using Gmail contextual gadgets, but it seems google has just dumped those, left the tooling and admin panels not to work and the documentation to rot at least 3 revisions earlier.
Looking into it was a complete waste of time, and seeing this now, I'm going to guess soon to be deprecated.
I wonder how long until Google repeats the history with this one. I'm honestly not sure I'd dare jump on another Google tech like this.
Seriously though: I was considering using Gmail contextual gadgets, but it seems google has just dumped those, left the tooling and admin panels not to work and the documentation to rot at least 3 revisions earlier.
That's in line with my experience. We had a gadget working a few years back (a button to create a ticket, for our support teams); a year and half ago we had to make an update, and the gadget simply never came back - even after we reverted. And the tools are useless to identify these problems.
(disc: googler)
How could you make an open standard for this? Do you mean an open standard for apps-in-email? Or an open standard for doing things in gmail?
I meant an open standard for apps-in-email, but then again, interoperability between apps is something that probably should be handled more generically at the OS level.
Coming back to my remark, email is one of the great federated protocols of the web, and I would really hate it if a big company would ruin it by adding proprietary extensions.
This seems to be extensions to the client, not to the messages themselves.
The extensions to messages they did was Email Markup, and they do use standard/open formats from schema.org (which is developed by multiple orgs, not just Google).
Seems like a lot of posters here not catching on, this seems to be a parity thing with the new cross-platform, HTML-based MS Office Add-ins which are pretty sweet and have been out for a while. Unusual for Microsoft to be out in front of this since usually they like to follow examples.
I still like Google's Inbox. Which seems like a forgotten and abandoned child sometimes.... But it works great for me. Makes it easier to wage through the tons of stupid mails.
Talking about Mobile version here. The web version is not good.
Did I understand right that add-ons also work in the iOS app? How are they implementing that, especially since Apple recently said you're not allowed to load custom code on the fly? Sorry if this comes across as ignorant, but I have no app dev experience whatsoever so I have no clue how any of this stuff is done at the moment.
My understanding is that on the fly code loading is still allowed if (1) the loaded code is written in, or compiled to, JavaScript, and (2) no native hooks it can call allow it to call arbitrary native functions by name, which was being misused to access hidden/proprietary APIs that could break during updates. Which makes sense if Apple wants to guarantee "our updates won't get blamed for broken apps as long as our public APIs are backwards compatible."
I'll probably setup a Slack channel for those interested in talking more about this. I'm not part of the program yet, but very interested in it, and I'd be happy to meet you if you have similar interests. btwelchy_gmail
A little off topic, but anyone else find those example gifs exceptionally fluid and intuitive? I really liked the way the blue dot indicated movement, clicks, etc. A very elegant solution for demoing a touch-based system.
I found it a little disingenuous - in reality, half that screen is going to be taken up by an on-screen keyboard, and typing is nothing like that quick; that little blue dot would be moving from key to key to key to key.
Eh honestly, I think posting 3MB of images is a bit antithetical to their goals of making everything faster. Gifs are basically the worst format possible for this.
I read that Google is trying to engage developers and allowing them to market their add-ons via the G Suite market place. Has anyone had any financial success via developing these type of add-ons?
I doubt much direct revenue would come this route. But, if you sell CRM software, or trouble ticket software, the integration might swing a potential buyer.
This happens very regularly for me, Google's own internal links are terribly broken.
I'm on an android device, using chrome. I'm clicking a link on a Google site, a call to action to sign up.
I get a page that's not a signup page but another overview, and has a broken image in.
Usually it's broken links on help pages but this is just useless. How do I sign up? I want to build on your platform! Please stop making the first interactions I have with you broken!
Would this API support manipulation of message composition format? I would really like a gmail add-on that eliminated quoted text in replies by default, with a button to "reply with quoted text" for the rare occasions when it is wanted.
You can now build native add-ons for Gmail that work on desktop/mobile gmail, with native UI and hooks without needing to write hacky chrome extnesions.
There's still a shit ton of companies whose products live extensively (or exclusively) in Gmail - not to mention the examples they give are use cases that you would not use in slack. Slack is certainly winning as an external communication tool, but email/gmail dominates external (and customer) communication for gSuite-using companies.
Having the power to do this with Google's consent _and_ have it be available on mobile devices is huge.
I hope this solves the problem of conflicting Gmail extensions, I currently just have too many installed that don't place nice together.
[1]: https://gmail-message-id-finder.co/ [2]: https://www.inboxsdk.com/