Why Did Google Decide to Split Inbox from Gmail?
techcrunch.com
techcrunch.com
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.
I'm not comfortable with that... at all, but it may not be a bad idea.
As Alan Kay says, computing is the one field where, thanks to Moore's Law, you can live in the future just by spending enough money. He puts forth a pretty good argument that one of the problems with modern computing is that it's too incremental, and one of the reasons for that is because most programmers (and students) use consumer-grade laptops and desktops, and thus they're stuck writing code for yesterday's state-of-the art hardware. On the other hand, programmers using workstations can write for tomorrow's consumers. He attributes much of the breakthrough progress of the 1970's Xerox PARC to its willingness to buy the researchers and programmers $60,000 workstations (that's adjusted for inflation, and they built 80 of these)[1][2]. The expressed goal was to be able to develop software for the computer that would exist 10 years hence.
[1]http://history-computer.com/ModernComputer/Personal/Alto.htm...
[2]http://data.bls.gov/cgi-bin/cpicalc.pl?cost1=10000&year1=197...
We have all of the algorithms now, so the hardest part is probably developing a good UI. So, you need to a super fast computer so that:
(1) You can power the UI
(2) You can rapidly iterate in response to user testing.
[1] By "cache" I mean stuff that is stored locally rather than in the cloud; I'm not talking about CPU caches which will probably stay about the same.
> We have all of the algorithms now
Aren't some of those algorithms patented, e.g. speech recognition from SRI, Nuance, Apple/MS/Google, IBM, AT&T and increasingly implemented in centralized cloud storage rather than at the edge? How about lack of access to training data?
I don't think speech recognition algorithms are patented. At least not the Google ones, since AFAIK they use neural networks. You could train your algorithm centrally and then ship all the neurons, weights and biases of to the individual device and keep the training data secret.
The first Alto (mostly designed and built by Chuck Thacker at Xerox Parc) started working in April 1973. The original cost target was around $15K in the dollars of that time. We eventually made more than 1500 of them (actually close to 2000 by some estimates) during the 70s.
I recall that the budgeting was actually about $22K per machine, which would be roughly more than $100K in today's dollars.
There are a variety of points here. The biggest one is that -- being a rather practical field -- we tend to have ideas that are possible. A factor of 10-50 allows us to have ideas that our subconscious minds reject automatically, because we are used to working within "normal". We have to shift or get beyond "normal" to make big progress.
Best wishes
Alan Kay
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...
[2] http://www.macworld.com/article/2090831/applescript-makes-a-...
So, they designed Gmail around people who don't use email? That explains a lot.
Edit: Not sure why downvoted. I'm not being sarcastic, please read the article, it's right there.
"In parallel, the Gmail team would begin working on a standalone product specifically designed from the ground up for advanced users who have to handle a firehose of incoming emails every day. And that’s how Inbox was born."
I use Inbox for my personal email, but gave up on it for my work email.
Inbox, on the other hand, is "specifically designed from the ground up for advanced users who have to handle a firehose of incoming emails every day" (last paragraph of the article).
To summarize the article: the Gmail team decided that Gmail should be geared toward non-power users; power users of Gmail (Google employees) hated this decision; Inbox was born as a product specifically for power users. In the meantime, (some) power user affordances were kept in Gmail, but better hidden.
Inbox has the hidden power-user affordances, The real power-user Gmail is the old Gmail that is allowed to still exist.
Author can't English good.
The backlash was because GMail was being used by high-volume users who struggled with the new, simplified version.
1) Based on their observations of user behavior, the Gmail team started pushing to simplify Gmail's interface;
2) This prompted a backlash among Googlers, who use Gmail for their work email and therefore need the sort of power-user features that would have been dropped in a simplification;
3) The Gmail team pushed back with a "you are not the user" argument;
4) A giant political furball ensued, with the stakes being whether Gmail would become a simplified email tool for general consumers or a power-user email tool;
5) The "power-user email tool" side lost, but as a peace offering they received a consolation prize: rather than dropping their ideas altogether, the Gmail team would build a separate product (Inbox) incorporating those ideas. (I call it a "consolation prize" because any separate product will have to fight for its own user base, making success much harder than if it could roll out to Gmail's already massive user base.)
I.e. the original version of the Gmail was designed by heavy emailers, they then noticed that most users got very few mails and redesigned it (in 2011) for that use-case. (Including the wide line spacing leading to low text-density, and similar things that lots of people complained about at the time).
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.
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.
That looks like overhead to me.
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.
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.
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...
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?
We need people who have actually studied and practiced design (interaction, graphic, visual, industrial, ...), the latter being important because design is as practice based, if not more so, than programming. So developing junior designers under the mentorship of experienced designers is essential and often left out in companies (especially startups) who don't get design.
And this is what gets me about the "designers must code" meme: if they are coding, they are not getting experience designing.
With digital design, the turn around is so short that it can be incredibly beneficial to learn similar digital techniques yourself instead of waiting for the reply that tells you "can't do it".
You specifically mentioned interaction design as the first discipline (and i would URGE companies to hire classically trained designers), and ffs, of all the disciplines, it's the most tied to coding. It is integral to learn of the production processes to be worth your salt. In college, we made books by hand. We made websites without frameworks, exhibition designs in foamcore real-life mockups. Any course worthwhile will continually stress the understanding and competency in the production methods. I'd like my architect to know the theory and have some practise in building a basic wall, wouldn't you?
You are also exhibiting a web bias here; a lot of design work doesn't occur for the web. Should a designer for mobile learn ObjC or Java since that is what is used to implement their designs? And god forbid the designers that work on AutoCAD; must they really learn about C++ while they are becoming experts on CAD?
Many IxDs that I've met are trained programmers and architects (though my wife is an IxD trained in visual design). Even the ex-programmers have no chance to program (our company tends to have more design work than designers, and enough programmers). I haven't noticed any difference in design quality between the ex-programmers and ex-architects (but that was mobile, not web).
On the other hand, I have also met some good researcher-style designers who get their hands dirty with design-oriented programming platforms like processing and arduino in their more open ended projects. This is sort of a different style of designer beyond professional, though (professional designers just don't have much opportunity to go this route).
You're right in saying that design schools can't offer the specialisation of a particular production mode to all students, it's not feasible. Yet what is feasible, is that the interest is there, and it can be built upon by one lecturer or third party resource (on recommendation) to a particular student. There are people who I graduated with that gained an incredible amount of print production knowledge in their final year that stands to them completely, while I focused on "hey why can't i make stuff on this website move and interact in a more delightful[0] way.
The main point here is that there is a investment in learning any production technique, and anyone who has that knowledge will always be more valuable than someone who does not. The choice for designers is to work it out for themselves if it's worth learning it for what they want to do.
Now I've gotten ranty :( sidebar: That's a fierce irish name you have, are you from Eire? :P
[0] Kill me
In experimental prototyping situations, you'll see designers learn the non-design skills they need to build their prototypes and express their ideas. That's great, but we must never mistake prototypes for products (prototyping is a distinct activity from production with different goals). So a designer might code, but they might not test well, or write comments, or any of the other million things you need to do for production-level programs.
I've been in hiring situations before, and I often find those who identify as "designer programmers" to be neither great designers nor great programmers. There are of course some great designgineers out there, but they probably won't apply to our company :(
Disclaimer: I'm a self-identified programming language designer whose niche field necessitates programming (since we are designing for programmers...duh!), but I have a lot of design studio experience working as a prototyper (never as the designer) on more conventional areas (web, mobile, even old-style surface when it was a table and not a tablet). Not Irish, just typical mixed up American with Scottish and Irish heritage (among everything else).
Going back to your comment a couple of levels above, I think it would be wonderful if more designers could produce their designs in a form that's closer to to the end environment instead of Photoshop and tools like that.
Of course there is something to be said for people specializing in what they're good at, while also listening to others with complementary skills.
It seems like it would be a good idea for a design team to have an embedded developer involved in the design process from the beginning. (I mean a developer "embedded" in the design team, not an embedded systems developer.)
In a web design shop, this would be somebody who could make the jQuery plugins or whatever libraries/utilities are needed to implement, or at least do a proof of concept of the trickier parts of the designs. Have a fancy transition in your design and don't know if it can work and not be janky? Then it's your team's responsibility to not only provide the design, but the basic jQuery plugins to demonstrate that it works and give the main dev team a head start on it.
Maybe I'm speculating on this because it sounds like the kind of job that would be fun for me. As long as the designers treated me like an equal member of the design team and not just "their coder." :-)
Ya, that used to be my job. This actually happens at Microsoft (my company), you'll get one or two people who can code and do prototypes working directly in the design studio working more directly with the designers (also useful for calling out BS when the devs say they can't do something).
You could have a point that design is more practice based than programming, but you haven't backed it up at all. Programming is very much practice based, in my experience.
[1] https://en.wikipedia.org/wiki/Human%E2%80%93computer_interac...
I never want to blame the messenger when it's bad news, but I do want to thank the messenger when the news is good. :-)
I'm with you on the caps. It seems superficial, but it was such a pleasant relief to see the all caps menus gone when I opened VS14 for the first time.
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.
https://play.google.com/store/apps/details?id=com.google.and...
If you got rid of the second part of that sentence, it would just be...
> You engineers do not understand the user
And they would be correct. From what the article said, it seemed the Gmail team (not just designers, the whole team) had mountains of data defending their choices. Their data proved that Gmail was becoming harder and harder for regular people to use, while engineers continued to ask for more advanced features. The only real solution was to split the interface between advanced users and normal users. As hard as it is to believe, especially in Silicon Valley, most of the people using Gmail are not engineers and do not work at Google. So while I'm not claiming that designers have all the answers, they can at least prove that this needed to be done. I would agree with them, I think most people who are going to use the web interface of Gmail are casual users and the UI changes work well for them.
Given Google's immense size, I'm very glad they're taking this approach...attempting to satisfy both the casual emailer and the power user and still providing a great service behind the scenes.
You speak with much certainty, like you work on the product. If so, I apologize. If not, then please defend your statements with supporting evidence. You present strong opinions but no reasons why we should believe what you say.
The advantage that a designer brings to the table is they are (hopefully) looking at the problem with a fresh set of eyes. They aren't constraining their solution to technology or legacy constraints that may or may not be valid.
> 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.
Then what the designer intended wasn't really what was implemented.
Good designers may push you to do things you think aren't feasible at first glance.
I've seen so many developers drag their heels through the mud "proving" that something won't look right just because they stuck with their stubborn assumption that a design wasn't possible from the start. So of course, they end up producing something that is kludgy and broken, which only helps them assert that their original opinion was correct.
For a largely used application like gmail (or email in generally), it's often important to be able to show a "simple" interface and an "advanced" interface... this flag should affect all areas of use... Not just bury options together under an "advanced settings" menu.. but by declaring "I'm an advanced user" other menus will offer more options.
Some of said screens will be wholly different, and that is okay.
I have to agree on a lot of the changes you make note of regarding Gmail for android, and in VS... What really got me was when they changed the mail app in android to match gmail... I really don't need a randomly colored box with a letter for every email I see... I'd rather have a few more words from the subject, or sender's email address.
In a tablet, it's actually not so bad... I can't imagine how bad that would be in my browser.
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..., 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.
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.
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.
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.
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.
You have it backwards (if the OP is accurate): the UX redesign that met with resistance among Googlers became the new version of Gmail.com (new as of a few years ago, that is).
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.
But sure, I'd love to see Inbox for Apps as well, because my personal mail account uses Apps on my own domain.
Most of my mail flows through my business account on Google Apps. I really want to put Inbox through it's paces there. Hopefully it will be available sometime soon.
Surely, it runs in a web brower; does it not?
Just look at the new Google Calendar app :-S, it's WAY to busy...
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.
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.
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...
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...
That's not a page of "Google's SSL-based tracking" methods. That's an attempt to enumerate ways browsers leak information.
Wasn't the whole point of Gmail supposed to be better spam filtering?