
Why Did Google Decide to Split Inbox from Gmail? - alexbash
http://techcrunch.com/2014/11/16/why-did-google-decide-to-split-inbox-from-gmail/
======
fidotron
The problem with this "You are not the user" criticism is it misses the point,
which is that the users that totally rely on your product are the ones living
with the edge cases. Most of the other users could just switch elsewhere and
it's not going to bother them one iota. This is why MS Office has held on to
the market so strongly, as seemingly every finance department is reliant on a
different obscure feature that isn't replicated in alternatives.

This has been happening over at Apple too, where the power user experience has
deteriorated dramatically now that they've decided that lot are all stuck in
the ecosystem already. It's a dangerous game, and it's what caused MS to get
unstuck as Linux rose up. Right now you'd be hard pressed to consider OS X,
Windows, Android, Chrome OS or iOS as headed in directions power users (or
content creators) want or need. This will lead to a division like in the early
90s again, where to do serious work you need a "workstation" which will be
quite different to a normal machine.

~~~
m_mueller
Could you give examples for such developments on OSX? I'd consider myself a
power user, but the issues I have with OSX are not related to features, rather
to its stability and complexity (resulting in more bugs). I liked it best back
at version 10.4, but today we have way more features, lots of them directed at
power users.

~~~
praseodym
When releasing iWork 2013, Apple ditched all AppleScript bindings[1]. In later
updates, the bindings returned[2], but it still caused uncertainty about the
future for users with AppleScript workflows.

Something similar happened when they released Final Cut Pro X[3], also fixed
in later updates. But again: uncertainty, and many users prematurely switching
to alternatives (like Adobe Premiere).

[1] [http://www.macworld.com/article/2058705/the-state-of-
applesc...](http://www.macworld.com/article/2058705/the-state-of-applescript-
lets-not-panic-yet.html)

[2] [http://www.macworld.com/article/2090831/applescript-
makes-a-...](http://www.macworld.com/article/2090831/applescript-makes-a-
comeback-in-numbers.html)

[3]
[http://en.wikipedia.org/wiki/Final_Cut_Pro_X#Reception](http://en.wikipedia.org/wiki/Final_Cut_Pro_X#Reception)

~~~
m_mueller
Yes, the new iWorks (if it can still be called that) is clearly a step back -
no new features and a dummed down UI. I don't consider it part of the OS
though.

------
shaftoe
"All of the decisions revolved around the central fact that a typical Gmail
user was receiving only about five emails per day, most of which were of
promotional nature, and as such, required no response."

So, they designed Gmail around people who don't use email? That explains a
lot.

~~~
beaner
That sentence in context applies to Inbox, not Gmail.

Edit: Not sure why downvoted. I'm not being sarcastic, please read the
article, it's right there.

~~~
SwellJoe
I genuinely can't tell whether the article is suggesting that Inbox is for
advanced users or for non-advanced users (and GMail for whatever the other
user is). I believe, based on my own understanding of the two products, that
GMail will continue to exist for advanced users, and Inbox will be simplified.
But, the article is not at all clear on that; the last sentence seems to flip
the meaning of the rest of the article and indicate that Inbox is the
"advanced" one, while GMail will be made more simple. Or something.

Author can't English good.

~~~
nl
Inbox is created for high-volume users.

The backlash was because GMail was being used by high-volume users who
struggled with the new, simplified version.

~~~
mistermumble
It seems to me the other way around. I am a high volume user and I have relied
on Gmail for almost 10 years. I signed up for inbox (because I am always
looking for something better). I found it slowed me down. It was pretty but
superficial. I prefer the plain but functional Gmail. Just one data point, I
realize.

------
kellegous
I'm not at liberty to give details and I know very few of them after early
2012, but this doesn't seem accurate to me. The original design of Inbox was
the work of Michael Leggett
([https://www.linkedin.com/in/leggett](https://www.linkedin.com/in/leggett))
and while the project has always targeted the power user, its evolution was
not so straight-forward as this article suggests.

~~~
general_failure
The article seems correct to me. But I cannot provide more details either

------
tempestn
So.. is Inbox the "advanced" product designed for users with a firehose of
email, or the stripped-down version designed for everyday users? It seems to
have elements of both. Snooze is a great feature for people practicing Inbox-
zero (which anyone getting hundreds of emails a day and remaining sane likely
is doing). The increased automation of filters, and the addition of bundles in
the inbox all help.

On the other hand, the reduced compose window size, the removal of read
message counts within labels, the inability to nest labels, the inability to
specify advanced filters, and more, make Inbox (at least without occasional
use of gmail) inappropriate for power users.

This article (at least the final paragraph) seems to suggest that Inbox is the
power app designed for email-firehose users, but in its current implementation
it appears more useful for the everyday user who wouldn't bother to manually
set up filters for recurring emails (and could instead just use the new
"sweep" feature).

Anyway, I very much hope they continue to develop both products, and continue
to support their inter-operation, as well as porting features between them.
(Snooze in gmail-proper would be great, for instance. Advanced filters in
Inbox aren't really necessary, since they can be managed from gmail. Read
message counts and a decent compose window are, though.)

As long as both products maintain a decent user base, perhaps this best case
scenario will play out. On the other hand, if a feature-poor (but sufficient
for most users) Inbox gains the majority of the market share, I could see
gmail going the way of Reader, which would obviously be a shame.

~~~
walterbell
The one that generates the most semantic, ad-useful data will survive.

------
venomsnake
> This was in contrast to a typical Googler who received an average of about
> 450 emails per day, many of which were important to at least read, with a
> good chunk of them requiring a reply

That's ... quite a lot. The fact that the company manages to produce so much
IT products with such big overhead on the engineers is amazing.

~~~
nl
Proper communication in an engineering company is never an overhead.

~~~
jonathansizz
If we assume an average time spent dealing with each email of 15 seconds, that
adds up to around 2 hours per day. If most emails require replies, then
average time/email will be much greater than 15 seconds.

That looks like overhead to me.

~~~
nl
It's not overhead.

Large scale engineering optimizes the _teams_ output, not that of individual
contributors.

A key component of team output is communication.

Email is a key communication mechanism, especially within Google where (to a
large extent) their development workflow is built around it.

~~~
jonathansizz
Okay. But I don't believe that hundreds of emails per day is necessary.
There's a low signal/noise ratio and the noise is overhead.

~~~
nl
_There 's a low signal/noise ratio and the noise is overhead._

And that's exactly the situation people customised Gmail to do (using filters
etc), and what Inbox is designed to do from the start.

The problem is that "noise" is very, very context sensitive. 30 messages of
commit-spam, 10 comments on a bug and a 60 message long thread in an internal
mailing list suddenly become very, very relevant when that bug lands on your
desk.

------
Stratoscope
What bugs me about "you are not the user" is the implied corollary: You
engineers do not understand the user, but we designers do.

I've seen designers take too many decent usable designs and make them worse,
for no apparent reason other than chasing the latest design trend. The latest
Android Gmail app is a case in point. Its changes include:

* Garish distracting colors where the old one used muted colors that were easy on the eye.

* Thin spindly gray text for read messages in list view, where the old version used much more readable thicker dark text.

* When you pull a list view down to refresh it, a spinning circle appears that _covers up_ part of the topmost message in the list. The old version used an unobtrusive thin animated bar at the top of the list.

Or take the general OVERUSE OF UPPERCASE in modern design, such as the
UPPERCASE MENUS in Microsoft Office and Visual Studio. When developers
overwhelmingly complained that they hated the uppercase menus in comments on
the Visual Studio blog, Microsoft circled the wagons around uppercase:

[http://blogs.msdn.com/b/visualstudio/archive/2012/06/05/a-de...](http://blogs.msdn.com/b/visualstudio/archive/2012/06/05/a-design-
with-all-caps.aspx)

Ironically, this was a clear situation where the designers were _not_ the
user, and didn't understand what the user really wanted, but the designers
ruled the show nonetheless.

The funny part is that the complaints from developers weren't just based on
aesthetics. Most of us work in case-sensitive languages most of the time. And
in all of those languages, File and FILE are not the same thing! The uppercase
menus aren't just ugly, they cause a speed bump for anyone who has trained
themselves to look for accidental case mismatches.

Developers may not be "the user" in most cases, but I don't think designers
are either.

Not that I can claim to be any kind of visual designer myself! But I do have a
good sense of usability and I know bad design when I see it. I value the times
when I've worked with good designers who know that not all their ideas will be
right and listen to feedback about them.

It's harder to work with designers who think they always know best or that
their user tests and focus groups always tell the whole story, and don't want
to listen to developers - their job is just to _implement_ the designs. These
designers get support from management who doesn't have a clue about design.
Management _knows_ that the designers must be right because after all, they
are the professional designers and they have all these impressive studies to
cite. What could a mere _coder_ know about design?

It's a crazy situation, but I've been in the midst of it too many times.

The weirdest part is when companies who claim to do "agile" development are
really following a waterfall model:

1\. The designers build the design.

2\. The design is approved.

3\. The developers implement the design.

The designers don't even need to know what's feasible to implement! They don't
work in the same tools as developers. They use Photoshop and various kinds of
movie makers to make beautiful animated demos - with no idea of what can and
can't be done in the actual operating environment where the code will run.

So they spec out things that just ain't gonna happen - and if they do happen
it's a huge development effort and only after that do you find out that the
animations are janky and can't be fixed and it ruins the whole experience.

Or you do get it done and it works well after a major effort - but you've lost
development time that could have gone into features your customers actually
want.

And all the SCRUM meetings your dev team holds won't fix the problem that the
Big Up Front Design was broken from the start.

How agile is that?

~~~
e40
_Garish distracting colors where the old one used muted colors that were easy
on the eye._

The new Google calendar app pushed to Android within the last few weeks is a
perfect example of this. In the old one, I could easily pick out dates and
items. In the new one, the colors overwhelm everything and I literally have to
consciously focus my mind to "see" the data they are presenting. It's a
complete FAIL, IMO. I wish there was an option to opt out of the material
design version.

~~~
bigtones
I did the same - uninstalled it. For the most part I like Material Design, but
on a Nexus 5 the new calendar app is woefully bad, and the reviews piling into
the Play store tell that story - in the last week overwhelmingly 19k negative
reviews, ouch.

[https://play.google.com/store/apps/details?id=com.google.and...](https://play.google.com/store/apps/details?id=com.google.android.calendar)

------
techtivist
I think more than just a product decision, this seems to be a more strategic
decision. Inbox is great for consumers, for your personal email. But for power
email users, there's very little, which is perhaps why they haven't even
opened it up to Google Apps users.

There's an underlying trend, while consumer mobile apps have been embracing
more and more unbundling, the good business mobile apps out there are actually
bundling more and more. Inbox replaced Mailbox for my personal email.

But for work, once I moved to Acompli
[https://itunes.apple.com/us/app/acompli-
email/id829384901?mt...](https://itunes.apple.com/us/app/acompli-
email/id829384901?mt=8), there was no turning back.

Acompli leaves a lot to be desired in terms of design, but I really don't care
because it has seamless multi platform file integration and integrated
scheduling features, stuff that I don't need for my personal email. But
mailbox and now inbox is great for my personal email, because it focuses on
stuff I really care about: quick replies, adding simple tasks and most
importantly snoozing emails that I don't need to reply to rightaway.

~~~
cognivore
"Inbox is great for consumers..."

That was the main point I took away from looking at the Inbox website. The top
three categories it uses are promotions, purchases, and trips. It's an inbox
for someone who's a consumer - literally. Looks like it's not a communication
tool so much as method of more easily getting people to buy things.

------
Immortalin
The reason why I love GUI builders is because they allow me to focus on the
design part and not on the code. My personal philosophy is that designing a
GUI should only be done in a wysiwyg interface. If you create a GUI using code
alone, there is a certain disconnection with the design which can lead to poor
interfaces especially if you are on a tight deadline and is trying to keep the
UI as simple as possible. My belief is that code should be strictly used for
business logic only and everything else should be left to the compiler and
IDE. Many fail to understand my preference for using VB for scripting purposes
instead of a "nicer" language such as Python or Ruby. To me the GUI builder is
one of the most important tools, many developers fail to understand that most
end-users would rather click on a menu than type in the commandline even
though sometimes it may be faster. What we should be doing now is making more
powerful IDEs so that the GUI builder abstractions are less leaky.

------
smacktoward
I love how the article starts off by telling us that the author "climbed to
Everest base camp," as if that has any relevance whatsoever to the topic at
hand.

~~~
sharkweek
...?

He's guest authoring a post on TechCrunch - they probably asked him for a bio
so he gave them a unique anecdote, an impressive one at that.

------
bluehex
I imagine most who care have already found an invite, but just in case, I'll
offer. I've got 10, pm with an email address to invite if you'd like one.

------
srtjstjsj
Very confusing wording.

In the last paragraph, the author is (with poor wording) saying that Inbox,
"the new Gmail", would be the new simplified "Email for people who only Get
GAP ads and notes from grandkids", and there would be _another_ new Gmail for
power users who like the old Gmail.

~~~
wodenokoto
No the article implies that inbox is the streamlined, low featured version of
gmail that got everybody angry and then finally ends up telling us that it is
in fact inbox that is the power user version of gmail and normal gmail is the
simple version.

------
steventhedev
In fewer words, Inbox started as a UX redesign, was met with so much
resistance that the team lead had to write a "You are not the target user"
post internally, and to salvage the sunk costs, they released it as a separate
interface.

Personally, I hope that Inbox gets some of those currently missing features
added back in, starting with support for Google Apps accounts. The ability to
snooze emails is too powerful (followup.cc turned it into a business model) to
allow it to get thrown into the Google Labs graveyard.

~~~
jsmeaton
I didn't think I would, but I love Inbox. I really want it for my work Google
Apps account. Snoozing stuff is a killer feature. Wiping entire lists is a
killer feature.

I get maybe 5 marketing emails a day, and a few actionable emails a week in my
personal email. I get about 10 actionable emails a day in my work account, and
about 200 emails that could just be wiped. I'd get so much more value out of
Inbox for Apps.

~~~
praseodym
You could use Priority Inbox, which you can train by using Important markers
on actionable/otherwise useful email. With the Gmail app on Android/iOS you
can even get (push) notifications for just these important messages.

But sure, I'd love to see Inbox for Apps as well, because my personal mail
account uses Apps on my own domain.

------
hollerith
What does the OP mean when it refers to Inbox as "standalone"?

Surely, it runs in a web brower; does it not?

~~~
vlad003
He means separate from Gmail.

------
NicoJuicy
Designers don't understand the user...

Just look at the new Google Calendar app :-S, it's WAY to busy...

------
jmount
"typical Googler who received an average of about 450 emails per day" ick

------
justcommenting
the most obvious answer to this question-even after reading the article-is
that this is just a continuation of what's always made google wildly
successful: inserting itself between open architectures and your personal data

that's not meant as a criticism per se, but it's the core of their business
model: serving jquery for free in exchange for tracking your users
persistently via Google Analytics, building a browser to slowly but surely
make it harder to opt out of Google's SSL-based tracking.

like all of its successful products, Inbox aims to create value for users
while subtly moving more of your activities to a level of abstraction that
Google controls and/or monitors.

~~~
magicalist
> _serving jquery for free in exchange for tracking your users persistently
> via Google Analytics_

jQuery on their CDN has nothing to do with Google Analytics, and it's served
without a cookie and with long cache expire times, so it's not a very good
tracking target.

> _building a browser to slowly but surely make it harder to opt out of Google
> 's SSL-based tracking_

I have no idea what you're referring to here, but it doesn't sound like it
makes much sense.

~~~
justcommenting
> jQuery on their CDN has nothing to do with Google Analytics

most production servers i encounter that serve google's copies of jQuery also
serve GA. i know this because i have to manually allow those requests using
RequestPolicy. yes, they're technically different products. but that wasn't my
point.

> I have no idea what you're referring to here

check out: [https://sites.google.com/a/chromium.org/dev/Home/chromium-
se...](https://sites.google.com/a/chromium.org/dev/Home/chromium-
security/client-identification-mechanisms#TOC-Lower-level-protocol-
identifiers)

~~~
magicalist
> _most production servers i encounter that serve google 's copies of jQuery
> also serve GA. i know this because i have to manually allow those requests
> using RequestPolicy. yes, they're technically different products. but that
> wasn't my point._

so...when you said "in exchange for" you meant that some sites also use Google
Analytics?

> _check out:[https://sites.google.com/a/chromium.org/dev/Home/chromium-
> se...](https://sites.google.com/a/chromium.org/dev/Home/chromium-
> security/client-identification-mechanisms#TOC-Lower-level-protocol-
> identifiers) _

That's not a page of "Google's SSL-based tracking" methods. That's an attempt
to enumerate ways browsers leak information.

------
Animats
_A typical Gmail user was receiving only about five emails per day, most of
which were of promotional nature, and as such, required no response._

Wasn't the whole point of Gmail supposed to be better spam filtering?

~~~
praseodym
"promotional nature" doesn't mean spam; it's things like company newsletters
that people did subscribe to and generally do want to read or skim.

~~~
taeric
I still maintain that just because someone subscribed to it, doesn't make it
not spam anymore. I've even found myself on a few mailing lists for not being
super diligent in unchecking when I signed up for something. I can only
imagine the so called "average" user.

~~~
JeremyBanks
What are you suggesting?

~~~
taeric
Basically that the entire point of something like Inbox seems to be to sift
out what you want. We just don't go so far as to call stuff that you actually
signed up for spam. We do want it to be easily ingored, though. And, at the
end of the day, I'm not sure what the difference between my spam folder and my
trash folder is. Add in my various "dumb subscription" folders, and they are
basically the same.

