The real answer is that Google's promotion and hiring processes don't respect front end developers. Systems programming and distributed systems are considered "hard" and worthy of reward. This explains why Google's front ends are bad, and it also explains why there's a proliferation of non-composable distributed systems inside Google. As a second order effect, the design of those back ends also make it harder to make…
Why is the Google Cloud UI so slow?
291–300 of 405 posts
Re: Why is the Google Cloud UI so slow?
#292Earlier quoted context omitted.
I don't entirely agree... Material Design is pretty great imho and I like most of their UI choices (for applications that seem to sometimes get priority). I think what this comes down to, is that their best technical minded developers are busy working on tooling, platforms, systems or other lower-level development. Their best design focused developers on public facing applications. This tends to leave the most junior…
Material UI is ... well. It just is. It's mediocre at best, and hilariously bad at worst: - Insufficient contrast everywhere https://grumpy.website/post/0TEJkwzPA - Inconsistent use of their own guidelines: https://grumpy.website/post/0Ra93yy33 (references the old design of the site, but the new one is just as bad) - Bad physical metaphors: https://grumpy.website/post/0UnXYXhD9 - Or the hilarious story where they nee…
Regarding the buttons, I agree they should elevate on hover and press down... with the animation for the click radial effect. Touch interfaces with just the radial click indication.
For the survey/study, I'm not convinced this is a bad thing. Actually interviewing with people to determine what works best should be actively encouraged.
This also isn't to say that I think google proper really cares all that much. I'm pretty sure their UX designers are treated like second class citizens in their engineer focused culture, let alone those that cross between UI/UX and engineering.
I also want to differentiate between "Material Design" the guidelines and "Material UI" the react component library. It's probably the single best component library I've ever worked with, which isn't saying too much as it's not perfect, just better than anything else I've seen.
edit: the main point was that Google's blessed implementation for their UI design framework is less used than a third party implementation for another framework.
Re: Why is the Google Cloud UI so slow?
#293There's a meta-answer, which is Google is shipping its org chart. Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component…
This comment makes little sense. AWS is even less uniform when it comes to tools, exactly because of its organic growth. This clearly has no impact on its success nor its features. Google does have a problem with management and the org-chart, but not the way you think.
But their focus is on spanning the feature-set, not making the resulting UI fast. And the feature set is incredibly broad.
Re: Why is the Google Cloud UI so slow?
#294Earlier quoted context omitted.
I don't think it is just that. Google is just shockingly bad at web frontend. All their properties are terrible, except maybe Youtube which I find quite agreeable. For example I just made a search on google.com, the most popular website in the world, and it can't even fit the content into this reasonably sized window [1]. [1] https://i.imgur.com/ER5yfbd.png
Which large companies aren't bad at web frontend? UX seems to always be far down on the list or priorities for modern websites.
I know it's popular to shit on them, but Facebook (and to an extent Instagram). Despite all the expansion, and third part integrations, at least for me (13" MBP 2017, i7/16GB):
1. Everything "feels" like Facebook. 2. It's relatively quick. I can hop from posts, to events, no notifications.
I hardly use Facebook, except for marketplace, so I can't say for sure if users find the interface confusing, but the UI at the very least is well done.
Re: Why is the Google Cloud UI so slow?
#295There's a meta-answer, which is Google is shipping its org chart. Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component…
And even then in the Google Cloud console I still feel that parts such as Stackdriver are, in fact, completely separate parts of the UI and not integrated into the bigger whole. Same for many other products. Which begs the question, what problem are they solving with this “unification but actually not” approach? Couldn’t they just bite the bullet and give up on the unification and be done with it? Phrased differently…
In theory, they expected merging SD into the GCP UI to be straightforward, because they're both Angular. In practice... Angular is a framework for inter-component communciation, not an SDK. And it's not a profoundly opinionated framework---the way the two codebases use Angular is so wildly disjoint that a merging was basically impossible without a rewrite. They don't even use the same date-time libraries.
One does wonder why they don't give up on the unification model.
Re: Why is the Google Cloud UI so slow?
#296There's a meta-answer, which is Google is shipping its org chart. Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component…
I would have thought that you could reasonably decouple concerns in order to fix it as well. Have every service expose a nice restful API, and then have one team responsible for the web interface but use those apis. Obviously, you need a way to require a reasonable performance out of the backing apis, but at least then you only have the one team to be concerned with how to build the front end and ensure that it works…
Re: Why is the Google Cloud UI so slow?
#297Earlier quoted context omitted.
> What happened to the Closure Compiler stack? Nothing, I still use it daily at work, alongside Angular (though not together). > how the heck did they end up settling on Angular of all things At Google, It's convenient to use Angular because there are well-documented ways to do all of the normal things you have to do to have a production-quality front-end application, such as building reusable components, dependency…
> It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google. I left on 2018, and I remember there were a lot of orgs and teams trying to migrate to a new framework. In my org we were discouraged to start new projects in Angular.
Re: Why is the Google Cloud UI so slow?
#298Googler who doesn't work in front end here, so take my opinion with a grain of salt: 1) A "footsoldier" dev has no choice in frameworks, and heavy frameworks with heavy reusable components are the norm. Frameworks are used to improve dev velocity and ensure consistency among the 100 teams that contribute to the web UI. 2) Devs care about performance but might not have time to do much about it given competing prioriti…
Because they are a customer with real world usage?
I don't think anyone is asking for "special access" or "special Google only APIs" or anything like that. However, if the Angular team isn't even looking at how parts of Google themselves are using their framework in out-of-the-box configurations and making the Framework look terrible on performance at scale, then is the Angular team looking at any customer's performance?
Facebook and Microsoft here both make a huge deal of dogfooding one's own frameworks because when you are your own first customer you get a lot of direct, immediate feedback. There are performance characteristics of today's React that we know come from needing to work at Facebook scale. There are performance fixes to Typescript that we see get mentioned that Microsoft internal teams experienced pain points with and let the Typescript team know that a hand would be useful there.
At least from external appearances, almost all of Google's largest scale usages of Angular perform poorly. I don't understand how anyone would want to use Angular knowing that even Google can't get it to perform at scale. That either the Angular team isn't prioritizing performance at scale or the Angular team has built it in such a way that even supposedly smart people "in the office next door" can't figure it out. In neither case does it look good for Angular.
What's the point of even having the Google name behind the Angular brand if Angular isn't taking production performance feedback from Google? (Obviously, it's still good marketing because so many people outside Google are using Angular, sometimes against their own better judgment. But it feels like a bait and switch.)
Re: Why is the Google Cloud UI so slow?
#299Earlier quoted context omitted.
I find Github and Amazon's main site to be pretty reasonable in comparison.
As someone who regularly uses other e-commerce front ends, I find Amazon to be quite cluttered and messy. Also it‘s surprisingly difficult to quickly find a specific product.
Re: Why is the Google Cloud UI so slow?
#300There's a meta-answer, which is Google is shipping its org chart. Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component…
This should be the default! What a world we live in.