Not the opposite, but we're missing the simple fact that enterprise products would rather get more features out over micro optimizations. There are constantly clients bringing their demands for additional features or major fixes, very rarely are they "please optimize the UI". For consumer facing products, that's not really the case, unless some massive features are missing, they would rather things be snappy as they tend to be extremely distracted at all times so dropping your app/site/whatever is no big deal.
During work, what else are you going to do if Cloud UI is slow besides just wait? Go through the entire process of trying to convince management to make a switch because UI is a little clunky? Good luck with that!
> enterprise products would rather get more features out over micro optimizations.
I've been using logs, bigquery, dataflow, and a smattering of other products pretty regularly for the past few years.
Are these products getting "more features"? Hardly. Well, dataflow deprecates minor SDK versions every month, so you have to run twice as fast just to stay in one place.
Instead, they have been redesigning the logs interface with fancy animations. And for the longest time ever they removed features from it like streaming logs.
Meanwhile the minor stupid things like displaying dates in MM/DD/YYYY format in date pickers, using AM/PM for time? Oh, they stay on. Graphs that work half of the time and you can never know if they are broken, cached, or just don't work? Oh, they stay on.
It's Google's systemic organisational failure: they suck at UIs, they don't care, and they couldn't be bothered to maintain features because "oooh, shiny new thing looks better on my resume".
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 of developers working on internally facing developer UIs. The payloads themselves are irresponsibly large on this application to say the least, and the ability/skill and understanding needed to make it better are probably not within the team(s) working on this UI to begin with.
Personally, I absolutely hate Angular and it's ironic that Angular's chosen primary UI toolkit @angular/material gets roughly half the downloads of the third party material-ui for react. Not even counting boostrap adapters.
Most web applications can easily be done in JS with an initial JS payload of ~500k-1mb (download size, compressed), with code splitting can have payloads for different areas/components come up as needed. Charts is probably the biggest beast that is practically impossible to tame, there have been a few times that I just generate the SVG directly in a React component to save the overhead of using a charting library, which is surprisingly easy to do.
- 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)
- Or the hilarious story where they needed a user study involving 600 people to tell them that if a text field doesn't look like a text field, people won't be able to tell it's a text field: https://medium.com/google-design/the-evolution-of-material-d...
And that's just off the top of my head.
But all of that could be forgiven if Google bothered or cared. They don't.
I know that some of the details above are worth calling out. In terms of usability, it's important and that is as much an implementation detail as it is a design guideline detail.
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.
I think it's more that people care about the speed of the actual cloud offering, not the internal control panel. The product isn't the control panel, it's the cloud services.
They're not saying it's ok. They are saying that the overall system (the business-business-management-employee complex) prevents optimization of this UI from being a priority.
>"I'm at work for 8 hours a day so it's ok if some time is wasted, there's plenty of it!"
that is how enterprise employers treat their employees. The time is wasted everywhere. Slow Google UI is just a one item in the long list, so no one of those enterprise customers would give Google a headache over it.
During work, what else are you going to do if Cloud UI is slow besides just wait? Go through the entire process of trying to convince management to make a switch because UI is a little clunky? Good luck with that!