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.
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.
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).
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.
I recently upgraded OSX and couldn't read KeyNote presentations by any one else in the office. I'd honestly pay them $100 to take the crippling upgrade back at this point.
>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.
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.
I may be missing something, but how would giving programmers more powerful hardware prevent incremental changes? Even if I'm using a top of the line rig, it's unlikely that anyone actually using the software I write will have that same level of technology available. I can only see this as a benefit in specific cases where the limits of modern hardware are being challenged, which are far fewer today than they once were.
The point is that you can write something that takes advantage of hardware that will be consumer grade in x years, rather than hardware that is consumer grade now. I thought parent stated that fairly clearly.
Ah, that makes sense. However, since most applications outside of video editing, gaming, etc. are not resource intensive, why shouldn't programmers just use consumer-grade hardware? An email client running on 2014's hardware and one on 2019's hardware are probably not going to be substantially different.
The "email" clients of the future are going to be dealing with multi-terabyte caches[1] with lots of high-bitrate audio and 5K+ video and images. A robust and competitive email client should be able to do real-time summarization, translation, text-to-speech, speech-to-text, and index into media files (I should be able to query for a phrase and get the relevant portion of a video or audio clip in the search results).
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.
Can you point to active research in the area of interactive applications with local or multi-tier caching? Everything in the news is about "cloud". The closest I've seen to cache-oriented apps were the cloudlets at CMU, http://elijah.cs.cmu.edu.
> 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 think the point here is that we don't see this kind of research because nobody invest in these super fast and expensive workstations that could mimic the future hardware.
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.
it's a 'strike price' R&D programme. work on expensive stuff _now_ on the assumption that it will be cheap/mainstream in x years. if you waited for it to be cheap enough before you start, you'll be outgunned by the crew that started 6 months before you did. that's iterative of course, how far back you go is the decision that counts. someone once said "10x faster isn't just faster - it's different". i like that metaphor, in CS you might throw away processor cycles for the GUI at a time when everyone else is optimising the metal for a text inteface to eke out a millisecond or two...
Developing bleeding edge software takes time. So you start writing your SW on a top end machine; in two years it becomes mainstream, which might coincide with the time of your first release. Moore's law worked perfectly for you here.
"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.
It's not written very clearly, so I can understand the confusion, but that's not how I interpreted the article. It sounds more like the sequence of events went like this:
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.)
Maybe a clearer way to phrase is "they _re_-designed Gmail around people who don't use email".
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).
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.
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.
Thank you for clarifying. It makes the last sentence of the article make sense, but I think one would have to already know the difference between GMail and Inbox in order to understand the article with confidence.
No, it doesn't. "The decisions" refers to those that the design/product team made (see paragraph preceding the GP's quote)---the same changes that were made and roundly panned by Googlers.
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.
That's not how I interpreted the article, but I may be missing something. I haven't used Inbox, but the description below indicates it's for advanced users, not somebody's Aunt Floe.
"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 like Inbox, but in my experience it is inferior to gmail for that particular use case. Gmail does a far better job of displaying a lot of information that I can scan quickly. Inbox treats you email like a todo list and expects you to deal with everything (that isn't automatically sorted out) individually.
I use Inbox for my personal email, but gave up on it for my work email.
I feel like most startups were using google mail (no longer free so not sure if people are buying it). I'm the "interesting" guy in my small startup office because I use apple mail as my client instead of gmail.
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) and while the project has always targeted the power user, its evolution was not so straight-forward as this article suggests.
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.
> 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.
You can see this sort of thing in open source projects where every status change for a issue or a patch automatically sends email. If you're subscribed to lots of issues and patches, and monitor the user support mailing lists as well, it adds up.
A good deal of it is change lists (CLs), which are sort of like pull requests on github, and issue tracking. With inbox I have all CLs that mark me as a reviewer explicitly in one bundle, all the ones in my "domain" but not with me as a reviewer in another, and all the remaining in a third. This bundling helps me keep vaguely on top of what's going on while only spending a second or so per email reading the subject line. Obviously, I spend more time on things where I'm marked as reviewer. If none of the CLs stand out to me as something that needs digging, I can just click the check mark for the whole bundle.
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.
This is a great point and one that so many people miss. Time spent managing email is not necessarily time wasted. Working with a team involves communication, and often that communication happens via email, and so managing email can be productive. When I'm in the midst of coding, I'd much rather my teammates send me emails that I can handle asynchronously than have them stop by my desk and interrupt me to say the same thing.
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.
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:
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.
> You engineers do not understand the user, but we designers do.
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.
Actually that's not the case at all. Google Apps users use the "regular" Gmail as their daily email client day in and day out, and there are over 6 million of those users who pay for the right to use Gmail as their client. They're not casual users who receive 5 or 6 emails per day that are mostly promotional, they receive upwards of a hundred emails over the course of a day in running their businesses. If you look at the most popular email client in the world, Microsoft Outlook, it has tons of advanced features to satisfy power users. For Google designers to err on the side of casual users over advanced users was an error and I'm glad they were called out on it by their own staff.
Is that really not the case? Do you have inside information, do you work on gmail?
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.
Maybe anecdotal, but I think many who use google apps for domains use a native email client -- mail.app, outlook, maybe even thunderbird. Certainly very few on iOS use the gmail ui, apps or not. Certainly I do, and most people I work with.
In my experience, a good designer (especially a UX focused designer) certainly leans on focus group, research, interviews, the history of existing solutions, and their own team (including developers) to arrive at a balanced solution to solve the problem.
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.
What's funny is that sometimes designers need to really accept that there may be a need for more than a single use-case and that a global all-happy answer isn't right. If it weren't for actually breaking up into groups of answer blocks we'd never have Thick And Chunky spaghetti sauce.
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.
This may speak to a growing need for people who have actually studied human-computer interface design, combined with other skillsets (probably graphic design principles, too), to be primarily in charge of the screens and flows.
HCI (as a CS science-based discipline) is not design and never has been (though there are definitely aspirations).
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.
I have always felt that learning code as a designer is no different to learning to take the production of print work into your own hands. Foil-blocking? Better talk to the printer. Six spot colours on a 64 page handbook? Best check with the printer. Half fold gate sleeve design with laser cut matte finish front over a high-gloss neon backing? Jesus, I better check with the printer.
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?
Sure a web designer should know some CSS, but javascript? I think many design schools do teach some web production technologies, but designers almost never have time to specialize in production.
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).
Completely agree I have the web bias, it's what I grew up making, yet I think the further comparisons you mention (autocad + c++ (tbh, no knowledge there)) separate the implementation from the final artifact much too abstractly for it to be a viable recommendation for career designers. Want to design a stool? Learn joints. Want to make an app? Learn flows. I wanted to make cool shit happen on a screen when you clicked, so I'm learning javascript.
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
There are plenty of ways that designers get their hands dirty in production, but this is enrichment to improve their design capabilities, not skills they will put 10,000 hours into. I guess I'm not so much against "designers must know how to code" as I am against "designers must code on the job and be good at it." To me, this de-values design itself and takes away valuable cycles from its practice.
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." :-)
> 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.
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).
According to the authority on everything (Wikipedia) [1], HCI connect CS and design, amongst other fields. But it's really just semantics. I want someone with that skillset and good design fundamentals in charge of the user interaction of my product.
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.
This is ranty, but also quite insightful into how a mistreated developer would feel and should give pause to other designers listening in. For what it's worth, the digital design crusaders have been pushing for tighter integration with developer style tools to make the hand-off more carefree. That being said, I do love to let my mind run wild with ideas and then pass it along to tomorrow me that is tasked with making that happen. It's a shame I have so few people to review code for security, scalability, known conventions and best practises. If it works, I'm happy out.
I appreciate being on the winning end of your double standard!
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.
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.
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.
When I hear "you are not the user" argument it sets red flag all over. If you think your company's engineers don't understand users, your company is screwed. This response should be taken with contempt by any engineer. Typically this argument is made by rather arrogant people, very likely suffering from a level of incompetency, who just want to shutdown further argument and stick to their guns. I'd hear that many engineers were unhappy with what so called designers were doing with Windows 8 and they also got back this same argument.
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.
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.
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.
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.
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.
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.
That definitely seems like what it should be saying, since Inbox seems to be the streamlined version of Gmail. But the way it's written is pretty unambiguously the opposite of that. I don't get it at all.
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.
>Inbox started as a UX redesign, was met with so much resistance . . ., and to salvage the sunk costs, they released it as a separate interface.
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 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.
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.
I agree about Google Apps support. So far, I like Inbox, but I don't get much volume on my personal Gmail account.
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.
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.
> 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.
> 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.
> 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?
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.
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.
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.