The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases.
The reason its hard (currently) to build a mail client using the API is that call to list the threads in your inbox or any other label doesn't actually return the messages in those threads. So its hard to show the people that are on the thread as well as some of the timestamp. If they added some more summary data to the thread object, I could see this becoming feasible.
One of the key differences between your solution (and fut.io, followup.cc) and our snooze is that we also do the conditional "but don't bring this back if there's a reply on this thread". Along with being able to "snooze" an email you're sending out with the conditional. This brings us much more in line with Boomerang's main functionality.
Plus our snoozing functionality is 100% free, no matter how many you schedule, or how long it's for :)
Oh, and you can see/edit/manage your snoozed emails all from right within Gmail.
And we also have the "Awaiting Reply" view that doesn't require you actually DO anything, other than send out emails. We show you a custom list of the last 20 emails you've sent that don't yet have a reply.
fyi: fut.io will send you an email asking if you want to cancel the followup if there's a reply on the thread. I think the follow up email has to be replied to, though.
And a competitor to you would be Follow Up Then which does what you do, I think. (http://fut.io/) I've used it for a very long time, but just switched to the snooze button in Streak. It's slick.
Any chance your project is open source? I would do this to something like 2 emails a year, but I'm intrigued by how it works from the technical aspect. Is there a database, or just exim/postfix magic?
Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)?
Apart from that I like the API idea - I have been beta testing my own personal document scanner - I email myself photos of bills and receipts and file them under the subject line (ie file-as bills.electricity) - it beats the hell out of a document scanner I never used.
Anyway I was going to link it to Evernote but I just don't use Evernote enough to justify it
I use my Gmail inbox as sort of a todo list. If a conversation is in my Inbox, it needs attention from me - I need to do some work related to it, reply to it, forward it, etc. Once I'm done with an email thread, I immediately archive it.
If you use this workflow (many do), snoozing an email is useful. I use it primarily for threads where I'm not able to reply and provide information immediately (so removing it from my inbox until I can reduces distraction), and for threads where I'd like to follow-up in a few days, if for example I don't get a reply.
Sounds like you should start using flags instead ("stars" in web-gmail?) Then your todo list should be easily accessible through a filtered list of flagged messages. Most IMAP clients offer this out of the box.
I have labels for organization but once something is marked as read or out of my priority inbox (where starred emails go) is has an extremely low priority and might as well not exist. If it's in my inbox and unread it gives me anxiety not to action it. A Snooze feature is a perfect middle ground.
> Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)?
Example that happened to me yesterday: a colleague asks me for a piece of information that I know I can find in a book at home, but I'm at work. I snooze the email so that it doesn't fall at the bottom of my inbox, and so that it gets redelivered when I'm home and can access the book.
Hypothetically, wouldn't really aggressive archiving accomplish the same task?
Have a 0-email inbox, and if you get something that you can't address immediately (but you can take care of later in the day), then you leave it in the inbox. In the meantime, anything you can act on in some way gets acted upon and then archived. By the end of the day you would ideally have just that email in your inbox (and even in a realistic world you might have a few tasks lingering in your inbox, but few enough that you can glance and see that "task" still there). Check your email at the end of the day and act on the things you needed to postpone for whatever reason (as well as pruning emails loitering in the inbox).
This requires, as previously said, really aggressive archiving, but since there's no difference between inbox and all-mail as far as I know (unless you use it as a search operator e.g. "from:friend@university.edu label:inbox"), it wouldn't be that big a cost (except that you would have to remember to archive or go through later and archive stuff).
I had been doing this somewhat organically for a while - tagging emails that didn't get filtered automatically and archiving them when there was nothing more for me to do with them - but when I disabled all of my filters (a misguided experiment I don't recommend anyone attempt) I stopped.
I'm awful at remembering to do anything. When doing inbox zero, I find it really useful to be able to postpone emails so I get a push notification on my phone when they come back into my inbox. That way I know if there is anything in my inbox, I should look at it pretty soon to decide how to process it (deal with it or postpone it)
Agressive archiving and postponing emails aren't mutually exclusive. They complement each other really well.
[edit] It also reduces stress. Some things can be dealt with until the evening, or tomorrow, or the weekend. It's really nice not having to pick though a middle of things that need to be done later and now and be constantly reminded that there's all these things to do. Of course, you can tag them or put them in folders, but it's nice when those tags/folders then let you know they're due.
Yeah, I do hardcore archiving and practice inbox 0 as much as possible, and it does alleviate that need. But it's still nice to have the email be at the top just when I get home.
AFAIK it's related to the "inbox zero" concept. You want nothing in your inbox except things that need to be actioned, but if you can't action something yet, you might want to snooze it.
> I'm surprised they don't recommend using this API to
> build full email clients. I fully expected that to be
> one of the core use cases.
I didn't see today's API announcement, but I'd be surprised if they wanted to encourage that. Similar to how Twitter doesn't want you to write full-fledged Twitter clients.
If we write full-fledged Gmail clients, won't they miss out on the ad revenue? Maybe not; maybe they're just glad to tie us to their service and data-mine our emails even if we're not using Google's web client.
Still, I'd be scared of basing a lot of work around this API, since they have a history of deprecating and discontinuing things in the past...
There's already a setting they lets you turn off ads. In any case, revenue from those ads is probably incomparable to the data-mining which they can then use to show you ads elsewhere.
Is there any way to use this feature without all the other Streak stuff cluttering up the UI (among other things, the "box" icon on every message in list view, Pipelines on the left, big button on the top, six new buttons in compose view). The CRM stuff looks spiffy, and getting the snooze feature through you is good advertising in any case, but I don't currently have a use case for those features, so I can't use the extension if it's going to fill up the UI with them.
I use a small google script to "snooze" my emails. I change them to a custom label which the script looks for. The script just runs once a day and sends me a summary of ones with this label if I haven't already replied to them.
Just a heads up, your Youtube videos on the home page won't play in Chrome if you loaded the page over HTTPS (you get a blank pop-up and the "This page contains insecure content." message). Slick product you have!
Aleem, this is great to see. We at FollowUp.cc (https://followup.cc) have been doing snoozing for quite a while and have a Chrome extension that does this as well. We are getting close to rewriting our entire extension from the ground up, and this API is definitely going to make our lives easier. Side note, I'm a big fan of Streak =)
It will be interesting to see how and if Context.io (http://context.io) starts to use this API. We use Context, and it's a fantastic product.
How fine grained are the permissions? Can your snoozing app operate with a sufficiently restrictive set of permissions that you are prevented from reading my email?
This is a good point. Typiucally, reminders are useful for reminding your team about a box (a deal or customer...) that needs to be looked at. Snoozed emails are just for you and remind you about a particular email.
There is clearly some overlap in use case and we're working on making that better but wanted to get out Snoozing as soon as possible.
I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMAP. I'm worried that API access could be cut back or eliminated entirely in the future depending on developer uptake, leaving gmail entirely inaccessible to third-party applications.
Edit: I'm going off of this sentence:
>It will replace IMAP, a common but complex way for applications to communicate with most email services, limiting the number of apps that can work with Gmail
Maybe it's misleading, but it sounds like the plan is to drop support.
Whether they drop support or not, clearly their idea here is to replace it.
Replacing globally supported open standards with proprietary APIs is one of the things people hated about Microsoft in the past.
Why does Google seem to get a pass from so many developers for this type of behavior? Or worse, get applauded for it?
If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilaterally making your own API is not the way. Unless you don't care about anyone but yourself.
> Whether they drop support or not, clearly their idea here is to replace it.
Its clearly their idea to replace it for some use cases for which IMAP's design is completely unsuited. Beyond that seems to be speculation.
> If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilaterally making your own API is not the way.
Actually, unilaterally creating your own API, getting some real use and experience with it, and refining it and submitting it for standardization is exactly the way that useful new standards usually get created. Attempts at creating standards not based on existing unilateral APIs often result in things that no one ever implements, like XHTML 2.
Having spent one year of my life trying to replicate Gmail's interface in a desktop app through IMAP (www.betterinbox.com), I can say with confidence that IMAP is completely unsuited for the Gmail paradigm. If we had this API back when we were working on BetterInbox in 2011, our lives would have been much easier.
It doesn't sound as though they're removing IMAP. It's still the recommended API for mail client applications. This API is a new, separate option for applications that don't need access to all your mail.
Gmail don't implement IMAP properly anyway - the IDLE command in Gmail doesn't provide notification of changes in the number of unread messages, just the existence of new ones.
It was quite a shock to find when I stopped hosting my email via GetMail/Dovecot that my read messages wouldn't automatically propagate across my devices until I did a manual poll. Gmail seems to use some HTTP API for this rather then following the standard.
TBH, I've never understood why more people didn't explore the multipart content type feature of email to extend email. It's typical to have plaintext and html in the same email, but why no JSON using a well defined and published JSON-schema.
I'm pretty sure that absolutely nothing is preventing this, and you could start sending emails with JSON inside right now. The hard part is probably finding something meaningful for it to do.
Email allows someone to send me data, as opposed to HTTP/S which targets servers. Adding structured data to emails could allow natural language communication to have a machine readable view of the communication. And there's probably a lot more uses.
I've done that twice: First time was when we built a demo registrar platform for ".name". We used Qmail with some custom bits and pieces to distribute messages that were used for things like live updates of the primary DNS server, live updates for a web forwarding service etc. A couple of the guys took the idea much further, and implemented a small library to do things like queue browsing via POP3.
The nice thing was all the existing tools that works well with various aspects of e-mail, and the great ease of introspection and testing.
The second time I did it was at Edgeio, where I initially used it to get a prototype of our blog feed retrieval / indexing pipeline up and running quickly. Though we relatively soon replaced it with a homegrown Stomp server, mostly because a lot of the stuff we were doing didn't need the delivery guarantees of e-mail, so we used in-memory queues for a lot of stuff.
It works great for some workloads, and it's a very easy way of prototyping things that makes it easy to debug message flows etc.. The state of open source message brokers have drastically improved since the times I did it, though - the first time we did it was back in 2002 or 2003.
Depends on your messaging volume and typical message size. For some types of apps it won't matter because the volume is small; for others it won't matter because the payload is huge. But you get battle-tested federation, scaling, server discovery etc. nearly free.
They recommend IMAP for full clients. The new API will replace IMAP for a wide variety of use cases, though (since IMAP was the only choice before it was available.)
Nice, but I'm very reluctant to give any third-party access to my mailbox. Most sites I use let me reset my password by email, so this is like handing over the keys to the castle.
Yep. It would depend how granular it is. I'd like to only allow access by sender domain or something like that.
However - how many people trust our email to small web hosting companies? How much better is that?
For example - many of my clients use the mailbox provided by Webfaction who I'm sure are beyond reproach but do I trust them any more than I trust a well known SASS company that integrates using the GMail API?
I run a small self-tracking service (zenobase.com), and would love to let my users pull in some "metadata" from their email (e.g. the number of messages in the inbox, or the number of messages sent by hour). But I don't want my users to trust me with unrestricted access to their email.
One of the advantages of this is that it allows finer-grained control than IMAP, so it can be used, e.g., for apps that can send mail (or create/read outgoing drafts) but cannot read incoming mail. So you can have at least some mail apps that don't require the "keys to the castle" that you are worried about.
It looks like auth scopes allow to restrict to read-only already [1], but I would really love to be able to restrict to a specific label/subfolder. Would provide a good level of security without having to forward the email etc, plus labels can be applied afterwards without modifying an email.
This seems great for building bridges from Google Apps' Gmail to internal applications, though, where there's no third-party to worry about.
Being able to replace my current IMAP client code - full of hacks to convert internal ids to Gmail ids and format conversion issues - into a couple of HTTP calls sounds great to me.
I can't believe how many people are stoked about this. If you look at https://developers.google.com/gmail/api/auth/scopes, basically apps can do a combination of a) have full control, b) read everything, c) do everything but delete emails, or d) read/write/send drafts.
Granting that level of access with no fine-grained control to 3rd party apps seems insane to me. I predict at least a couple major security incidents in the future.
While I somewhat agree with you, it's not as though these problems didn't already exist with IMAP. I think a better way of looking at it is this is the first step in removing the password from 3rd party access. Maybe at some point in the future they'll add more fine-grained access, but for now removing the credentials from the process seems like a good first step.
Not sure why they really need an API though. Seems to me like it would have been a better solution to stick to the IMAP protocol and allow an alternative method of authorization. For example an application would request access to your email, then they'd get an access token and use that to authenticate with IMAP. They could then try to delete an email with the IMAP protocol and if they hadn't requested that scope they're receive an error.
HTTPifying everything seems to be a trend, not sure what the real purpose is - if anything it's just making things less open.
I think accessibility. More developers are comfortable with REST than they are with IMAP.
In fact, at least the connotations I have with IMAP/SMTP: "shit still gotta learn that before I can start". Even though it would probably not even take a couple hours to get started.
I'm not sure what this API enables that can't be done over IMAP. IMAP may not be as familiar as JSON-over-REST, but it's supported by virtually all mail clients and providers, which makes it about as open as you can get.
Already the Gmail IMAP implementation is non-standard in a number of annoying-but-workable ways. I've been suspecting for a while that they're going to kill it or lock it down, the way they did for XMPP and Talk[0]. I really hope this isn't the first step towards that.
As bpodgursky pointed out, this sentence is troubling:
> It will replace IMAP, a common but complex way for applications to communicate with most email services, limiting the number of apps that can work with Gmail
Emphasis mine.
[0] I admittedly had no evidence for this speculation before today, just a worry.
Just based on a glance of the documentation, you can permanently delete emails using this, I don't think you can do that with the IMAP interface for gmail, but I'm not 100% sure on that.
Two key bits from the first two paragraphs of the article:
"make it easier for other Internet applications to use information in your email"
"It will replace IMAP"
First one seems par for the course, the second one doesn't seem to be reflected in the Google blog post [1]. Certainly for the moment, thankfully, it looks like IMAP is staying:
"The Gmail API should not be used to replace IMAP for full-fledged email client access" [2]
It would take something pretty amazing for me to allow anyone access to my gmail account. LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts.
There's a tremendous difference between an email client, whose job is merely to show me my messages, and an application that is not an email client that is designed to do something to my messages other than let me read them.
Everyone's fine with the former, but the second should always give people the creeps.
This might be big, I was just done complaining about the user interface of the GMail web app. If this means that developers can now effectively create another interface on top of a real GMail API this has the potential to really change things. I can already envision several ways in how I could improve my inbox management and reduce the time spent sifting through emails.
It seems like it would take a really big, promoted initiative with major players behind it to make a shift from IMAP, but it's good to know that other people have thought about it (your comment and its siblings).
My killer app for this needs webhooks, or some sort of event notification when mail arrives. Bonus points for making that condition a stored procedure/filter.
Until then I'll probably run out of "quota units" polling the thing..
My solution. Gmail Filter -> Forward to Mandrill Email Address -> Mandrill Webhook -> POST to HTTP endpoint that will issue a Twilio voice call to my phone.
I then have my Twilio number added as a favorite contact in iOS Phone app thus bypassing the scheduled Do Not Disturb feature. I will continue to get calls every 3 minutes until I answer the call and press 5. That's my "shit hit the fan" alarm.
We currently use Gmail IMAP with IDLE to support this use case. It works great, so I hope they don't drop IMAP without a suitable replacement like webhooks.
If they can combine this ease of accessibility for developers with a security model on the end-user side, I think it can be a solid win.
I'd love to see granularity in what the API can access, for example, TripIt may request something like "Grant access to emails from the domain travelocity.com, usairways.com, etc.," and I can know with confidence that they will not have access to the rest of my inbox.
It doesn't have that level of granularity, just four auth scopes:
1) Full access to the account
2) Do everything but permanent deletes of threads and messages
3) Read everything, but no write access
4) Create/read/update/delete drafts and send messages/drafts, but no access to anything else
Finer-grained access (especially for reads, but there are some use cases for finer-grained sending controls, too) would be better, but this is, AFAIK, a step ahead of any other email API.
I immediately checked for that level of scope when they announced it, my post was merely a "this would be pretty amazing for security conscious end-users" not "this part of the API is cool" -- a wishlist item have you.
It's high time that we get user-controlled sandboxes that could enforce additional security restrictions and are application-transparent. If a third party app requires access (R/W) to my Google Drive files, I should be able to limit said access to a single folder, for instance, and any other content should simply be invisible to it. These restrictions should be tuneable at any time (before and after app install) and there should be visualization tools to control their effectiveness.
Google has been adding lots of widgets to email recently, like RSVP on invitations, itinerary on flight booking emails, etc. These are pretty useful features and I believe a lot more are possible with the APIs being opened.
However, I feel the access control is very coarse grained. For example, RSVP widget needs access to only event related emails and itinerary needs only travel booking emails, but the API spec does not allow for such fine grained control.
IMO, given that google is able bucket-ize emails into travel booking, event, etc., and even user-defined labels for any custom grouping, allowing access on such buckets would be nearly as useful and much more user-privacy friendly. For example, an accounting app could still access invoices from my inbox to update my accounts automatically. Google could even push for microformats kind of annotation to make emails semantically richer.
We (http://grexit.com) let users share Gmail labels. We're very happy to see this release as it has been a pain to build and scale our service over IMAP.
It'd be interesting to see what kind of limits (no. of calls, concurrency etc.) that Google has put on the API. Has anyone trying this out hit of any of these issues yet?
Technical users can and will block access to portions of the API during authenticatcaion, but what about people like my parents? They might very well login, giving full permissions to the app, seeing that it's a trusted google URL while not knowing what they have done.
I see that as being a great opportunity for customer referrals. So many people have a gmail account. It'd be cool, from the business' standpoint, to see if your customers are connected through something as simple as email if they allow an app to access sender information.
This is fantastic. What we need next are OAuth libraries for Postfix and other SMTP servers, so I can use Gmail to centralize and read my email but still use my home organization's SMTP server to send email, without having to give Google a copy of my password.
This looks like it'd be EXTREMELY useful for cronjobs and other things where you need to send email to yourself (or another address) automatically. It would remove the need to self-host email just so that you can send status reports...
Great idea. I only wish it was an open standard... Email success b/c of it openness, but if we start proprietary APIs on top of it then we are getting locked in.
I am using Sparrow (Mac). Funny how GMail started as an the best webapp, and now I don't even remember when I last used it in "pure" form. Doesn't really help the "webapps will rule everything" message.
I've been waiting years for something like this. In the meantime, does anyone have any suggestions of third-party desktop applications that sync with gmail?
They don't preserve the correct labelling. Google rolled their own IMAP implementation to support putting a single email into multiple folders without copying the email. Thunderbird will take a copy of the email if it has more than one label.
Hot off the presses! Google just released the latest future ex-api they will get bored of in a couple/few years and kill, along with any company that depends on it. #rememberthiscommentthen
The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases.
The reason its hard (currently) to build a mail client using the API is that call to list the threads in your inbox or any other label doesn't actually return the messages in those threads. So its hard to show the people that are on the thread as well as some of the timestamp. If they added some more summary data to the thread object, I could see this becoming feasible.