GMail already is a platform; look at Mailbox.app -- it's a new UI for the GMail "platform". Building on top of the GMail platform obviates the need to actually do any of the grungy mail stuff. But as one commenter noted elsewhere in this thread, the lock-in implications are pretty sobering.
We made Inky from scratch -- without building on top of GMail, Outlook, etc. -- partly to avoid the lock-in, but primarily because it's hard to imagine fundamentally changing the email user experience without touching any of the code for the mail platform itself. The downside, of course, is the usual trade-off: by not layering on top of somebody else's already-debugged stack, we have to make our own huge raft of code work right.
The analogy to Lotus Notes should be a wake-up call to CIOs everywhere; our analysis of the enterprise email/messaging space makes it clear that the big companies still using Lotus Notes are doing so primarily because they have too much investment in the Notes ecosystem ("intranet web sites" built on top of Notes, etc.) to switch. They come up with an internal estimate of the cost to convert all the stuff they've built on the Lotus platform over to something else and realize that figure exceeds the likely N-year savings from switching. So, conversion project not approved by CFO. Next!
I am skeptical. There are apps out there extending Gmail's possibilities, already. Look at Streak (http://streak.com), look at Right Inbox (http://rightinbox.com). They are based on Chrome extensions. People use them if they need. The real trouble is Gmail becoming a bulky web app in time. Sending money, now actions in the Inbox. Lots of features, majority will not use. It is unclear, if Gmail will remain an simple email platform (which was the initial idea) or Google's promotion/enforcement ground.
This is a great point. If you aren't careful, adding extensions on top of gmail can really kill performance because of ballooning memory.
We (streak.com) spend a ton of time optimizing performance and memory usage. Not all extensions do this though.
If you're interested, there were 2 great talks at this years Google IO on how some gmail engineers spent a year reducing memory usage (and thus increasing performance) by a factor of almost 4x for power users.
The one thing Google will need to address is GMail's memory usage - it's bad enough on its own, but once you start adding extensions to it... I no longer keep GMail open unless absolutely necessary.
Unfortunately Steve Jobs broke the lock on the Pandora's Box that contained Walled Gardens so in light of that, this seems an obvious step for Google and could likely work simply because of scale and ease of adoption - something that the existing apps don't have in comparison.
For once, the answer to the title isn't obviously "no."
Can you imagine Gmail as the new Lotus Notes? Specially as third-party vendors flock in to fill the gaps? The potential for lock-in is absolutely dizzying; moving away from Gmail once you have your whole workflow automated would feel like going back to punch cards.
Exactly. pg has also written about "using your email as a todo list" (in Startup Ideas We'd Like to Fund) to partially address the problem of email being more than just a dumb box for all incoming information. Email as it exists today is very obviously broken, and very few players are in a position to change it. (Although there must be some startups with the frighteningly ambitious plan to replace email as we know it today.)
Of course it remains to be seen whether this is just a first move by Google towards a big goal or whether Google is just playing with new Gmail functionality to see what happens.
Agreed. Do we really want Gmail to be a great operating system lacking only a decent mail client? What is this, emacs 2.0?
And so what if people are using it differently then how it was originally intended? Give me a well designed tool, and I'll use it in 930294 ways it wasn't indented to be. That doesn't mean I'm going to like the new super-multi-purpose swiss army knife version of that tool.... Keep it simple stoopid, get off my lawn, not in my back yard, go unix, etc etc </curmudgeony old person rant>
When people say "It's broken" what they often mean is "It works both ways".
That is to say, the power granted by email to ignore others, send badly composed missives, avoid direct engagement, and conduct extensive time-consuming posterior-covering is (horrors!) mirrored by other people's ability to do the exact same things in return.
Ultimately, any "solution" that "solves" these problems satisfactorily will do so only be frustrating others, while leaving the people with the "improved" version free to go on doing whatever irritating things they've always done in a world that can no longer push back.
EDIT: Ok, perhaps there's more to email being broken than the social problems that are beyond the scope of technical fixes. But honestly now, how much?
Great read, and I'm expecting this to happen sooner too.
Think it something like -- the core-emailing is there within gmail, but extend the functionalities via services. Some external app uses to build services on top of emailing.
Something like -- Hootsuite on top of twitter, Hootsuite manages and adds value by its own apps.
Think: we have Gmail powered apps?
A link on top like: my-installed-apps -- to easily navigate and find newer apps for your workflows.
I'm working on stuff like this but from the ground up. You can't get any meaningful innovation until you can allow people/devs a way to access the system at a deeper level than Gmail will allow.
I'd love for another company to come out that has the clean interface and reliability of gmail, with even more security and better customer service. This is a great time for a disruptor.
Any company can compete with many Google products if they have a product that is almost as good, if not better, with way better customer service.
What ever happened to "If it ain't broken, don't fix it"? Every product doesn't need to be constantly re-inventing itself.
What most people want from Gmail is a sleek, reliable and fast email client. The Google+ integration is already annoying enough, please stop bloating it with more features.
Makes sense from Google's POV. Separating 'Gmail the email client' from 'Gmail the IMAP/POP/SMTP server', the latter requires a lot of investment with not much return. It seems that most of the value to Google comes from you using their client, since they can:
* show more contextual advertising
* track you as you travel around the web (since you're more likely to be logged in)
* use other Google services - especially Google+
So by adding proprietary features that only mean anything when viewed within Gmail itself, it's a big win for them. Also, once people become used to the microdata, they can gradually reuse it in other Google services. For example - complete a Google form straight from an email, that then does something special on an App Engine product.
What this shows is that Google has given up on product improvements for features. Instead of solving the inbox problem, they are selling "priority emails, now with bigger flames!".
The email problem isn't figuring out what the sender wants me to do with each message, it's figuring out what I want to do. This is e-junkmail and has less to do with making the recipient's life better and more to do with advertising.
"Today, we are introducing schemas in emails to make messages more interactive and allow developers to deliver a slice of their apps to users’ inboxes.
Schemas in emails can be used to represent various types of entities and actions. Email clients that understand schemas, such as Gmail, can render entities and actions defined in the messages with a consistent user interface."
I haven't looked into this in any depth but it doesn't necessarily seem Gmail specific (a good thing) but it does mean even more clicky buttons in an interface where I can't easily see what those buttons actually do (less good from a security/phishing standpoint).
That may be why they've made it a partner-only program, and why they control the interface for rendering each schema (that they specifically choose to support). While frustrating, it's an interesting point to consider.
Hmm. With Google canning Reader, it removes the only reason I had left to remain logged in, since I use a desktop email client. (Re Reader: I've moved to Inoreader, a clone which is still a little rough around the edges, but if it hangs around, it's a great replacement).
Gmail, as an email client, has always just been adequate. It isn't reliable at notifying me of incoming mails without the installation of extra software or downgrading to Chrome. And the real killer, it doesn't support multiple accounts in anything like a usable way.
I'm putting "logged in Google" in the same box as Facebook, and only using it in a separate browser.
Which desktop client do yo use ? I'd like to do the same but I know I will miss Gmail's thread formatting. I know there is a plugin for Thunderbird but it's not as great.
Something old-school - Forte Agent. It can do thread formatting like a newsgroup, but it isn't perfect - e.g. it sorts the threads by the timestamp of the root of the conversation, rather than most recent message.
We made Inky from scratch -- without building on top of GMail, Outlook, etc. -- partly to avoid the lock-in, but primarily because it's hard to imagine fundamentally changing the email user experience without touching any of the code for the mail platform itself. The downside, of course, is the usual trade-off: by not layering on top of somebody else's already-debugged stack, we have to make our own huge raft of code work right.
The analogy to Lotus Notes should be a wake-up call to CIOs everywhere; our analysis of the enterprise email/messaging space makes it clear that the big companies still using Lotus Notes are doing so primarily because they have too much investment in the Notes ecosystem ("intranet web sites" built on top of Notes, etc.) to switch. They come up with an internal estimate of the cost to convert all the stuff they've built on the Lotus platform over to something else and realize that figure exceeds the likely N-year savings from switching. So, conversion project not approved by CFO. Next!