Hacker News Reader

Comment by Traubenfuchs | Hacker News Reader

I think the answer is: This is the best the richest and best companies in the world, with their best paid 100x rockstar developers can do. Google is literally both the creator of the browser (Chrome), the framework (Angular) and the web-app (GCP) we use and still, this mess is the best they can give us. They have direct access to the creators of Chrome and Angular, in some sense they are the owners of the internet and the owners of the way we access the internet.

And yet, that's the best they can do. It's just that hard and impossible to get it right. Sorry guys!

View on HN

I don't think I agree with you here.

Make Cloud UI fast is probably not their priority. This is an enterprise product, not consumer facing, users are much less likely to be turned off due to slow UI. They will wait.

Integrity/Security would be much higher on the list than UI loading speed.

Not surprising at all.

>This is an enterprise product, not consumer facing, users are much less likely to be turned off due to slow UI.

Shouldn't this be the opposite? Maybe this is just me but if I have to use something to do my actual job and it take more time that it should because of the UI I'd look elsewhere.

> I have to use something to do my actual job and it take more time that it should because of the UI I'd look elsewhere

The one who made the decision to use GCP would not be the one who would use it actually. If GCP offers a bigger cut than other Cloud providers, loading time would be irrelevant in that optics.

Enterprise users are risk averse. Speed is definitely a plus, but they would care more about stability/predictability than anything.

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.

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 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.

This is such a depressing take. "I'm at work for 8 hours a day so it's ok if some time is wasted, there's plenty of it!"

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.

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.

Only if you have a choice. Most people don't have a choice of what tools to use, they are dictated by their employer. And employers may have other priorities (e.g. checking off "serverless" on their bullshit-bingo-card before the next board meeting)

Can you look elsewhere? Most _users_ of Google Cloud are not the decision makers and can't move to, say, AWS.

Consumers can more easily make that choice since they're not part of a hierarchy.

they don't care about the opinion of the people using the awful UI, they care about the executives signing the contract after being wined and dined

Tell that to the guys at Atlassian, the worlds slowest web application...

The people making the decision aren‘t not often the ones who need to work with the product.

At least the new JIRA workflows are faster than the old one...

People who use this product largely don't interact with the web ui, a lot of things are only done occasionally. And the people that use it frequently won't use the web ui, command line tools or a third party program that abstracts that away is more likely.

Also the AWS web ui has a lot of the same problems, so switching vendors wouldn't just fix the problem

The UI is the primary management interface, log search interface, and in certain cases, analytics interface.

I don't know. GSuite admin panels used to be pretty fast in the early days --now it can become frustrating to use.

I must say after using Microsoft Teams...

M$ is back, baby. I would invest in them if I invested in huge-market-cap companies.

After IBM, Microsoft became the company selling Windows and Office for businesses. Huge cash cow. They lost that for a while due to the iPhone and Google and stuff moving to the Web and mobile.

Now they’re back.

The fonts and aesthetics remind me of using Windows apps 20 years ago. This ain’t Google. Small, crisp verdana, tahoma or whatever.

Meetings done right. Office - Word, Excel - integrated. Tons of plugin support.

Compared to Slack, this is way better. And compared to Google Suite, well... Teams is faster and actually feels like a product teams would live in day-in and day-out. No need for slack, zoom, gmail and a hodgepodge of other things.

Microsoft also has a huge cache of businesses who would literally onboard their entire company and pay monthly recurring revenues. They have successfully gotten back into the Microsoft Office business.

Except this time it’s recurring revenues and on the mobile too. Even if Microsoft doesn’t sell mobile devices. They are going to eclipse Google with businesses if Google keeps doing its cute slow Web based interfaces, imho.

And I say this as a person who has not used Windows for 15 years, who hardly ever used Office or Office 360 until literally trying Teams as part of a consulting gig.

It’s amazing. And it’s very Microsoft.

> Compared to Slack, this is way better

Try scrolling up in Teams. I'll wait.

Now do it in Slack - 10 times quicker, and thus usable.

On the flipside though, try doing a video chat in Slack.. Not exactly an ideal experience

Agree. But try doing a video call in a channel in a team in Teams, and watch everyone in the team join, not just the people in the channel. At that point you won't miss just starting Zoom so much.

Especially when you can just /zoom from inside Slack, in fact.

The moment you find slack to be faster than something else. You know we have reached the absolute rock bottom.

I have to use both Slack and the Google Cloud UI at work. RIP.

Try doing a screenshare in Slack. You can't, you have to connect a voicecall before you can share your screen.

Now do it in Teams. You can share your screen without completing a voicecall.

I happen to like MS Teams a lot... was very happy to see Linux getting proper support earlier this year, similar for o365. If you run a company with more than a handful of users, worth the price of entry imo.

I also wonder how often the UI is used vs the command line.

It's not the best they can do. It's the best they will do.

There are companies with higher (arguably actually acceptable) quality standards, but they're few and far between.

It's not the best they can do.

Without seeing them do better there's no way to actually know that. You're assuming they're capable, but you could be wrong.

Considering as a company, they created the first very fast JavaScript engine, massively usable browser implementation and UX features along with other applications that are pretty complex with UIs that aren't excessively slow to load, evidence is contrary.

I think it comes down to their best and most experienced developers and designers are focused on other areas with higher visibility, engagement or critical function.

It's not the best. It's what is passable considering the politics and priorities involved.

Attach a monetary concern directly to the performance and there will be improvements overnight. Otherwise this is the "best" we get, given the circumstances.

Yep its simple

The more money you make, the better of a person you are, in literally every way - this is known as rule 1. So if the highest paid people work for FAANG, they must be the best people, so obviously the best humanity can do is 5 seconds to load a spinner.

At my lowly serf job, we are only able to make a web app that usually responds in <1s with a total of 8 low paid, middling, dull engineers working on many other things at the same time.

I think 'building cloud solutions' is higher on their priority list than 'making the UI fast'. Whether they have access to the Chrome and Angular teams is irrelevant.

How is it that Microsoft's Electron apps are so snappy and performant? You would never know Visual Studio Code was Electron by how it performs. I'm not a user of their cloud apps, but are they similarly snappy, or is it just that Microsoft's Dev Tools team is way out in front?

Performance is a priority for VSC. Same with Azure's console. Same with sites like Stackoverflow.

It's not a priority with many of Google's current apps.

Which is a problem with the dev environment. If it takes a lot of effort to make an application performant then most of the applications written in that environment will be slow.

It isn't so much about environment as it is experience. It is incredibly easy to bring in libraries and components that bring the entire jungle for want of a banana. Especially graphing/charting libraries. It's also about focus, the focus is on the feature not the performance/feel.

VSC dev here. Correct, perf is a priority for us and it's no black magic. A simple one is to keep your bundles small. VSC's main bundle is less than 9MB, Cloud UI seems to be 15.

That sounds a bit dramatic. It seems more likely that, given the competition and alternative choices, their current effort is good enough, not their maximum capability...

I think YouTube has been going downhill for years, but where else are people going to go? Vimeo? Users have been trickling away to other platforms, sure, but not enough to seriously challenge YT. FB video is probably the only serious contender in the rear view mirror at the moment.

Is this some kind of dig against the web? I prefer native myself, but obviously there are huge numbers of faster websites out there.

The answer is that Google’s frameworks suck, and have for many years. I can’t comment on whether things are equally a mess in their proprietary code, but I don’t see any reason to think they’re not. This is a problem with Google, and their slide into mediocrity.

The parent is being sarcastic, very sarcastic.

Is this some kind of dig against the web? I prefer native myself, but obviously there are huge numbers of faster websites out there.

The parent isn't saying no one can do better. They're saying Google's engineers can't do better. It's sarcasm, but at the same time there could be a grain of truth to it - it would be unfair to believe Google's engineers aren't doing the best work they can. Most people do try their best. Perhaps it's actually fair to assume Google's engineers just aren't very capable when it comes to frontend dev work.

I wasn't trying to be sarcastic, but I prefer the sarcastic interpretation.

I love the web from the bottom of my heart. I love Javascript, I love Typescript, I love Angular. Develop once, run everywhere, no client side updating required. I love rest(ful) APIs. I consider working with Angular a joy. I am serious here.

Kinda funny that after all you said you felt the need to add a I am serious here ;)

I am simply aware that there is a very vocal amount of developers disgusted by Angular and in love with react. But coming from a Spring backend background, Angular 2+ felt just right to me. Meanwhile I hated react every time I tried.

I do like JS much more than most and have warmed up a lot to TS. I would echo most of this statement... except I think Angular is a dumpster fire that I'm more than happy to never touch again in my career.

"Best" is a tradeoffs assessment, and Cloud is chasing "the best features," not "the best speed."

They're taking the eng-hours of the people who could be responsible for speeding up and consolidating and saying "Okay, as long as it doesn't mean we can't release high-granularity-IAM-control-based-on-user-eye-color this quarter. Because it's a non-starter to get LensCrafters on board until we have those table stakes."

The speed of GCP's internal control panel isn't going to affect Google's bottom line like it would with their search offering or other massively user facing things. Google could redo this frontend from scratch and make it really lean and fast, but they clearly don't think they need to.

You might be surprised there... enough friction for the developer experience will open the door to opportunities for other tools/platforms to take root. If the AWS UI/UX was exceptional, there's no way Google or Azure could have gained the footholds they did.

Totally true, just wanted to clarify that point of the OP

I think there is an important difference between what the company "can do" and "do do". Which is to say if it was a focus, surely they could do better, Looking at the article shows that it's clearly possible to do better with focused effort.

I think you're right in that this is the best any individual in the company "can do" they likely run up against organizational road blocks and incentives that run they astray. But if the organization would take this as a priority, surely with all the capacity they have, they could do better.

This isn’t tied directly to ads/revenue/profit. Make it more obviously profitable to have it fast and you will see what the best they can do is..

This is especially frustrating if you consider that Google's own benchmark tool Lighthouse constantly gives you MOTDs like "Company X increased their revenue Y dollars per 100 ms page load speedup."

I am on mobile; what are the Lighthouse scores for Google's own products?

They are optimising for something other than performance. E.g. ease of maintenance, or ease of scaling

Google employs 115000 people, are you sure they are all 100x rockstars?

Anyways, if the management was forced to use Google Cloud's UI, I'm sure it would look and feel completely different.

As it is, they're making a product they don't really have a personal stake in.

I think the UI is probably not a high priority on their side and they assign most of the work to juniors and outsourced.

Probably the best they want to do because they do not want to allocate more resources to it.

I wonder if it's a case of Conway's Law at play. Google is a big company and there are multiple pieces involved in GCP and so in the end the interface between those pieces is inefficient and slow. They've shipped the org chart.

I am pretty sure there as boatloads of developers that want to do good and even know what needs to be done just as in every single company I have ever worked with.

After working with graduates from "the best university", I doubt it is "the best".

After using "the best" search engine, and finding what I needed on Bing instead, I started doubting it was "the best".

Perception is different than reality. I genuinely wonder if these are "the best", or if these employees were merely the ones willing to move their lives to a new city for a high paying job.

But I'm sure FAANG and FAANG employees would tell you they are the best.

I wonder if they would fall for marketing tricks. Do "the best" fall for marketing tricks?

while i agree with you, there's a lot more going into performance and usability of a product than whether the employees are "the best"

That conversation can always be reserved elsewhere, right now the greater issue is the incentives of the organization and deployment process.

People act differently in groups than as an individual. The coordination is not solved and is not proclaimed to be the best at these large organizations, no matter what an individual's skillset and competence is.

It's all a matter of signal to noise ratio.

> Perception is different than reality. I genuinely wonder if these are "the best", or if these employees were merely the ones willing to move their lives to a new city for a high paying job.

You can always find that one diamond in the rough. It's true there's a selection bias toward folks that are willing to relocate. But I bet the average engineers at Google is much better than at Generic Company Co.

Reply on news.ycombinator.com