Last October, Google announced that all applications accessing and storing Gmail data must pass a security audit from an outside firm – Google estimated that such an audit would cost $15,000 – $75,000 or more. Many useful Gmail plugins and integrations are shutting down due to this requirement, even open source applications where the code is available for all to review.
Historically, Google has been slowly repositioning Gmail from an email inbox to an app platform itself: there are Chrome addons and Gmail plugins to turn Gmail into a CRM, a todo list, a kanban board, and so many other integrations – which is why I’m surprised to see Google seemingly reduce the usefulness of Gmail by adding these requirements and losing these plugins.
We’ll see how this goes, but I would bet on Google slowly loosening up restrictions over time, or possibly offering subsidies for the security audits of popular Gmail plugins.
Google Reader Strikes Again
A particularly cheeky ArsTechnica commenter wrote the following insightful comment:
When Gmail was first introduced, it was truly revolutionary. Most other email providers offered a handful of MB of total storage. Webmail interfaces were slow, crowded with ads, and were a mess to use. When Gmail was announced, many thought it was an April Fools joke: who would offer 1 GB of storage when that was 2 magnitudes above what most providers offered?
I think what surprises me the most about Gmail is how completely it has won the email market for the past 15 years. An email service is relatively straightforward to implement: the protocols are all open, there’s open source software that can scale reliably; and yet Gmail is the undisputed king of email. Even many corporations use Gmail through G Suite.
Now that Gmail has essentially won the email market, it looks like it is slowly pivoting to become an application delivery platform in itself. Just like how the web pivoted from delivering simple HTML pages to full Single Page Applications (SPA): games, word processors, custom applications – Gmail is doing the same thing. If you look at the original blog post, Google is introducing many new actions with email: reply to a comment post, browsing hotel recommendations, and generally interact with other web sites and services. Gmail will slowly turn into a one-stop shop for all your messaging needs – it’s not too hard to imagine Gmail being able to add items to your todo list, to create posts to be sent to your blog to post, to send texts to friends, etc.
Here’s to another 15 years of Gmail transforming our lives. Thanks for everything.
Sometimes the full Gmail experience is too much for an older laptop or mobile device. Instead of trying to load the new Gmail, you can force the basic HTML version of Gmail to load by going to mail.google.com/?ui=html .
If you’re already signed in, you might see the below screen. If you’re signed out, you’ll need to sign in using the standard login screen.
After this, you’ll see a much stripped down version of Gmail:
It’s a pretty straightforward answer, but it started me thinking about the nature of folders and Google. It’s interesting that Google Drive supports folders at all, considering that another famous Google service – Gmail – doesn’t support folders at all. Instead, it has labels.
In Gmail, you can create as many labels as you want, and apply any number of them to an email. Labels are similar to folders: they enable users to categorize and easily search for files – the only thing missing is the hierarchical pattern that folders enable. Which leads me back to Google Drive: I wonder how folders are internally represented within the Google Drive system. Based on the API, it looks like folders are considered a special case of files.
But if Drive can handle folders as simply a special file, why doesn’t Gmail support folders as well? Is it simply that Gmail and Drive are separate codebases, or that Google feels that labels are a better categorizing scheme than folders?
It’s always interesting to think about Google’s architecture and how different services have vastly different builds and APIs.