Why is the Google Cloud UI so slow?(debugbear.com)
debugbear.com
Why is the Google Cloud UI so slow?
https://www.debugbear.com/blog/slow-google-cloud-ui
404 comments
This is what I was thinking as well. Once you recognize Conway's Law and Sinofsky's "don't ship the org chart" quote, you start to see it a lot in large companies.
Want another great example? If you write iOS apps, you'll probably have worked with the App Store Connect website. That site is such a hodgepodge of slightly different UI paradigms that it could only have been written by multiple teams with differing goals and timelines.
Want another great example? If you write iOS apps, you'll probably have worked with the App Store Connect website. That site is such a hodgepodge of slightly different UI paradigms that it could only have been written by multiple teams with differing goals and timelines.
I've come to the conclusion that you want to structure your org chart to deliver the structure of application / experience you ultimately want to provide.
This reminds me of the famous comic about org structures of various companies. [1] Perhaps this is why Steve Jobs liked to get his fingers in everything, to make sure everything flowed smoothly according to his vision.
[1] https://bonkersworld.net/organizational-charts
[1] https://bonkersworld.net/organizational-charts
This is what's known as an "Inverse Conway Maneuver"
Guess what, you've just invented re-orgs. And the reason why big tech (and other) companies continuously shuffle around teams and their structure.
[deleted]
disclaimer: i work in google cloud, but on the apps side.
One thing worth noting here is that google pretty famously has a monorepo and single-version policy. Meaning: while you may be right about the subteams/orgchart meta-issue, it's not actually shipping multiple versions of the same subcomponent. There's just one version.
One thing worth noting here is that google pretty famously has a monorepo and single-version policy. Meaning: while you may be right about the subteams/orgchart meta-issue, it's not actually shipping multiple versions of the same subcomponent. There's just one version.
and i should add that this constraint is one of the reasons why some products get discontinued. right now, I'm dealing with migrating a dependency that has some breaking changes in an old section of my codebase that nobody has touched in years. I have to change it, because the dependency is changing, and I cannot continue to depend on the earlier version.
Happily, it is a simple enough update (and frequently these changes are automated by whomever is actually changing the library). But when this is something that needs extensive reworking, the project might get turned down instead.
Happily, it is a simple enough update (and frequently these changes are automated by whomever is actually changing the library). But when this is something that needs extensive reworking, the project might get turned down instead.
Aha, so my guess was right: https://news.ycombinator.com/item?id=24457476
Isn't this what happened to Facebook's iOS and Android Apps? IIRC their Android app had thousands, upon thousands of overlapping class files.
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 well.
GCP is something like a hundred APIs. It's not tractable to have one team responsible for a GUI that big.
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, what are the advantages of this unification and reuse of components, exactly?
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, what are the advantages of this unification and reuse of components, exactly?
The stackdriver acquisition was a big eye-opener for Google. Well, should have been. I don't know if they actually learned any lessons. ;)
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.
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.
Stackdriver was acquired: https://techcrunch.com/2014/05/07/google-acquires-cloud-moni...
The problem is that single-entrance is very valuable for ease-of-discovery. But complete integration / unification is just too difficult for something already present since they may simply use a totally different tech stack. Re-writing may not be justified by ROI.
For those kind of "separate parts", I can easily mention a few: 1. Stackdriver (acquired). 2. Cloud Data fusion (acquired, formerly cask.io) 3. BigQuery (predate GCP) 4. DataPrep (partnership)
The problem is that single-entrance is very valuable for ease-of-discovery. But complete integration / unification is just too difficult for something already present since they may simply use a totally different tech stack. Re-writing may not be justified by ROI.
For those kind of "separate parts", I can easily mention a few: 1. Stackdriver (acquired). 2. Cloud Data fusion (acquired, formerly cask.io) 3. BigQuery (predate GCP) 4. DataPrep (partnership)
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.
Google does have a problem with management and the org-chart, but not the way you think.
AWS has significant first-mover advantage, but in chasing that advantage, Google sees providing a UI as a distinguishing feature to the AWS exeprience.
But their focus is on spanning the feature-set, not making the resulting UI fast. And the feature set is incredibly broad.
But their focus is on spanning the feature-set, not making the resulting UI fast. And the feature set is incredibly broad.
GCP's interface is worse because it clearly prioritizes form over function. When I click a button in the AWS control panel, generally it works. When I click a button in the GCP control panel, there's a non-trivial chance it will result in an infinite loading screen or an ambiguous error.
I see it all over Google's products (with the exception of search). Gmail loads 50mb of assets these days, and is extremely sluggish. It shows you the search bar but if you try to type in it too soon it'll skip characters and start to chop. It's embarrassing. And I'm on an i9 with a gigabit connection. Imagine how horrific it is to a user in the third world.
I see it all over Google's products (with the exception of search). Gmail loads 50mb of assets these days, and is extremely sluggish. It shows you the search bar but if you try to type in it too soon it'll skip characters and start to chop. It's embarrassing. And I'm on an i9 with a gigabit connection. Imagine how horrific it is to a user in the third world.
> And the product as a whole is chasing feature parity, not speed of UI.
I find it hard to believe GCP is not chasing the UX experience since they have actively focused on building arguably non-priority features like a fully functional terminal within the cloud UI.
I find it hard to believe GCP is not chasing the UX experience since they have actively focused on building arguably non-priority features like a fully functional terminal within the cloud UI.
They care more than zero, but about feature completeness more than speed. Keeping in mind that their leading competitor (AWS) leaned heavily on CLI, providing web frontends is seen as a competitive advantage.
But they're far more focused on spanning feature set than the speed of the result.
But they're far more focused on spanning feature set than the speed of the result.
Having used both, I prefer AWS's UI over GCP's
What funny is that AWS's UI was built with GWT -- Google Web Toolkit -- technology that Google abandon in favor of Angular.
> and be willing to take a whole-page refresh when the user transitions from one page to another.
This should be the default! What a world we live in.
This should be the default! What a world we live in.
I prefer sites like this. Also give me plain links that I can middle click on to open new tabs.
Let my browser manage my workspace, please don't make a window manager inside my browser window.
Let my browser manage my workspace, please don't make a window manager inside my browser window.
> [G]ive me plain links that I can middle click on to open new tabs.
[Stampede of +1s]
It's really sad that WeB ApPlIcAtIoNs seem to be synonymous with broken no-choice-but-left-click navigation. Yes, I consider that broken.
I only remember to right-clicking the tab to try duplicating it about half the time, and that works maybe 60% of the time I do try it.
[Stampede of +1s]
It's really sad that WeB ApPlIcAtIoNs seem to be synonymous with broken no-choice-but-left-click navigation. Yes, I consider that broken.
I only remember to right-clicking the tab to try duplicating it about half the time, and that works maybe 60% of the time I do try it.
I mean, I create SPA's where this just works for nearly every navigation element. With a proper "route-first" design, this is not that hard. Of course, it is a bit more work to perform url navigation even when merely opening a subview, but it's definitely worth it.
I share your annoyance at all websites who don't allow for this though.
I share your annoyance at all websites who don't allow for this though.
I wish Wireshark also had tabs that you could clone with middle-click.
Yes! We're building a fairly complex web app and page refreshes are < 100ms. With prefetching on hover this becomes virtually instantaneous.
But the screen flashes white, it looks non-native!
It does not flash white. See e.g. https://instant.page/
> Google is shipping its org chart
This is basically the definition of Conway's Law.
This is basically the definition of Conway's Law.
> And the product as a whole is chasing feature parity, not speed of UI.
I thought google was actively avoiding parity-chasing, opting to "do their own thing, which will be better" instead. Or have I just been drinking the kool-aid?
I thought google was actively avoiding parity-chasing, opting to "do their own thing, which will be better" instead. Or have I just been drinking the kool-aid?
While they do have some initiatives that are unique, the Cloud org's goal is absolutely "Beat Amazon and Microsoft at the market-share game." Which means they need all the meat-and-potatoes features (storage, compute, short-lived functions, monitoring and analysis, permissions on all of the above).
I would've expected a shared design library that had all the standard widgets, and then each page / area of the UI to be implemented and managed by the individual teams.
The dependency version drift could be solved by forcing every part of the application to use the same version, though obviously this increases the complexity of each upgrade.
My understanding from following angular development was that prior to each angular release they effectively beta test it across Google's estate - I think this is partly why the upgrade process is so smooth, because it wouldn't be tenable otherwise. The same pattern could be applied to a shared design library
The dependency version drift could be solved by forcing every part of the application to use the same version, though obviously this increases the complexity of each upgrade.
My understanding from following angular development was that prior to each angular release they effectively beta test it across Google's estate - I think this is partly why the upgrade process is so smooth, because it wouldn't be tenable otherwise. The same pattern could be applied to a shared design library
Googler 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 priorities. Cloud is a fast-moving area, so new features are being added all the time. Even if they want to improve performance, they're limited by the frameworks you have to use.
3) For folks that are saying Google controls the browser, framework, and component library, and so should be able to do better than this, you are right. But the different divisions don't talk to each other as much as you'd think. Why should they? Angular devs shouldn't get special access compared to React, no? Whether this is an organizational failure or an enforcement of separation of concerns is up to you. I imagine critics will complain if Chrome did something special for Google properties, and they'd be justified.
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 priorities. Cloud is a fast-moving area, so new features are being added all the time. Even if they want to improve performance, they're limited by the frameworks you have to use.
3) For folks that are saying Google controls the browser, framework, and component library, and so should be able to do better than this, you are right. But the different divisions don't talk to each other as much as you'd think. Why should they? Angular devs shouldn't get special access compared to React, no? Whether this is an organizational failure or an enforcement of separation of concerns is up to you. I imagine critics will complain if Chrome did something special for Google properties, and they'd be justified.
What happened to the Closure Compiler stack? It was infinitely ahead of its time, how the heck did they end up settling on Angular of all things
> 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 injection, component testing, screenshot diffing, etc. Standardization of the framework also has the benefit of making it easier to find someone to ask for help.
It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google.
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 injection, component testing, screenshot diffing, etc. Standardization of the framework also has the benefit of making it easier to find someone to ask for help.
It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google.
> It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google.
And in fact, Cloud already did this.
Unfortunately, what they chose to bring up to the same level was... Angular, when they transitioned off AngularJS.
They moved from a framework with known performance pitfalls to a framework with slightly fewer known performance pitfalls. It was the right move for them, but it only solved a handful of the problems they were having with the previous iteration of Angular.
And in fact, Cloud already did this.
Unfortunately, what they chose to bring up to the same level was... Angular, when they transitioned off AngularJS.
They moved from a framework with known performance pitfalls to a framework with slightly fewer known performance pitfalls. It was the right move for them, but it only solved a handful of the problems they were having with the previous iteration of Angular.
As a former frontend dev, current google employee, I don't think it would be as technically herculean as it would be politically herculean. Plenty of production apps aren't on angular, but they are in much smaller orgs with less management, or they are in search where shaving ms of time is a job description.
It's really hard to wrangle the amount of feature growth cloud is experiencing and I expect they made tradeoffs to satisfy that first.
It's really hard to wrangle the amount of feature growth cloud is experiencing and I expect they made tradeoffs to satisfy that first.
Coming from the outside world and looking (back) in, I simply can't ever imagine being in the kind of environment where discussing the choice of web framework or tool language would last more than 10 minutes, before whoever spoke last basically wins. But then, I'm the kind of techie who has lost their love of and has actively grown to despise tech.
"Is it supported?" "Yep"
"Can we hire for it cheaply? "More or less"
"Does it support the weird InternalSuperWidget it must talk to?" "Essentially"
"Ship it!"
"Is it supported?" "Yep"
"Can we hire for it cheaply? "More or less"
"Does it support the weird InternalSuperWidget it must talk to?" "Essentially"
"Ship it!"
It isn't this simple. You have millions of LoC already written, docs, onboarding, hundreds of teams with different opinions, training people in a different tech stack.
In green field development or smaller companies, sure, I however do not find it as exciting since there are not real people / technical challenges most of the time, once you compare with what you can build with 1000s of engineers.
In green field development or smaller companies, sure, I however do not find it as exciting since there are not real people / technical challenges most of the time, once you compare with what you can build with 1000s of engineers.
I do not miss Google's monorepo one iota. It had huge benefits, but after stepping back far enough the result also easily begins to look a little like Stockholm syndrome. Anything they want to open source they basically have to rewrite from scratch because of that godawful repo, never mind reasoning about what actually ended up in your binary on any particular day when depending on such a gargantuan tree, and of course not to mention what by now is likely 10s of FTEs dedicated simply to managing the tree.
Those millions of LOC mostly only existed to serve their own purpose, and possibly the intrigue of many a doe-eyed eng. If I came across a codebase like that today, I'd likely be quite vocal on reallocating the evidently outsized engineering budget to some more productive use
Those millions of LOC mostly only existed to serve their own purpose, and possibly the intrigue of many a doe-eyed eng. If I came across a codebase like that today, I'd likely be quite vocal on reallocating the evidently outsized engineering budget to some more productive use
Can you expand on "If I came across a codebase like that today, I'd likely be quite vocal on reallocating the evidently outsized engineering budget to some more productive use"
Like, Google (or other company) still has to deliver to production and they do so using their existing system. I believe not supporting the existing system means not having deliveries.
I am actually facing a similar issue in my current job and it isn't an easy thing to move away from.
Like, Google (or other company) still has to deliver to production and they do so using their existing system. I believe not supporting the existing system means not having deliveries.
I am actually facing a similar issue in my current job and it isn't an easy thing to move away from.
> 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.
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.
I completely forgot to mention that what I was saying was scoped to the Ads org, which has Angular embedded within it deeply.
It was infinitely ahead of its time when it was new... and then it was abandoned until it was miles behind the competition.
It's the Google Way.
(But truly, the headcount on Google's internal web tooling compared with the size of the organization is laughable. I watched lots of devs burn out trying to improve internal tooling, then quit, because the organization doesn't value it.)
It's the Google Way.
(But truly, the headcount on Google's internal web tooling compared with the size of the organization is laughable. I watched lots of devs burn out trying to improve internal tooling, then quit, because the organization doesn't value it.)
> But the different divisions don't talk to each other as much as you'd think. Why should they?
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.)
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.)
I think your criticism is totally valid. Angular should take a look around and see the real-world uses of their framework and see how they could get so slow. Ultimately, the onus is on the Google Cloud team to prioritize and deliver performance. Perhaps part of the problem is that very large customers use the automation APIs, so they don't make the complaints that get heard. ("Platinum" customers have a strong impact on the roadmap.)
User to Dev: the memory usage is excessive. Dev with 256 GB RAM to User: WFM
I would not be surprised if a lot of these problems could be traced back to developers having above-average network connections and super beefy computers. Combine that with fresh or minimal installs while testing the software, without lots of data that accumulated over month or years of use and in consequence they experience their products as super snappy.
Summary: they maybe never experience their products as a normal user would.
I would not be surprised if a lot of these problems could be traced back to developers having above-average network connections and super beefy computers. Combine that with fresh or minimal installs while testing the software, without lots of data that accumulated over month or years of use and in consequence they experience their products as super snappy.
Summary: they maybe never experience their products as a normal user would.
Why is everyone assuming that just because someone works for Google has to be competent? Solving algorithmic puzzles is not an indicator or actual technical skills.
To me, it looks like a work of incompetent developers led by incompetent technical managers upon requirements of clueless and ignorant product managers.
To me, it looks like a work of incompetent developers led by incompetent technical managers upon requirements of clueless and ignorant product managers.
Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. They're attempting to maximize their velocity, maximize their API stability, and make programmatic usage of their system as easy as possible.
GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick. Probably the best one of the bunch (Azure, AWS, Oracle, OVH, ...).
GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick. Probably the best one of the bunch (Azure, AWS, Oracle, OVH, ...).
I thought Terraform provider was developed/maintained by Hashicorp, not Google. Are Google employees actively involved? I also did encounter annoying issues (which have slowly been getting better though).
I guess it might speak to a solid, if somewhat slow, API.
I guess it might speak to a solid, if somewhat slow, API.
Yeah they've got a nifty tool called Magic Modules that partially auto-generates the Terraform Provider (along with Ansible and InSpec) from the GCP API:
https://www.hashicorp.com/resources/google-provider-new-terr...
https://www.hashicorp.com/resources/google-provider-new-terr...
My understanding is that it is actively maintained by GCP employees, but yes Hashicorp owns the repo.
The terraform provider is usually a near 1:1 mapping of the provider's APIs.
> Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. They're attempting to maximize their velocity, maximize their API stability, and make programmatic usage of their system as easy as possible.
Yep, already covered that under incompetence and cluelessness.
> GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick. Probably the best one of the bunch (Azure, AWS, Oracle, OVH, ...).
In that case, I would assume that backend team indeed consist of competent people, as opposed to web team. But TFA was about front end experience which is abysmal.
Yep, already covered that under incompetence and cluelessness.
> GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick. Probably the best one of the bunch (Azure, AWS, Oracle, OVH, ...).
In that case, I would assume that backend team indeed consist of competent people, as opposed to web team. But TFA was about front end experience which is abysmal.
They had some big outages over the last year. I’m therefore still skeptical to bet on them from a “backend” operations reliability standpoint also. To be fair I’m not sure they are doing worse than AWS though when looking into details. I’m thinking recent AWS Kinesis us-east issue - move fast and break things? Maybe uptime is more important than a gazillion new “feature” services. I also prefer good terraform provider stewardship over any “fancy” new cloudformation CDK or “beautiful” GUI actually. It’s complicated.
> Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. (snip) GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick.
That's still incompetence. That counts as incompetence, too.
"This restaurant is filthy and full of bugs, but that's OK, because they're take-out only, so they're not optimizing for the same thing the average sit-down restaurant is. Sure, that place is disgusting, but the food in box still tasted pretty good..."
That's still incompetence. That counts as incompetence, too.
"This restaurant is filthy and full of bugs, but that's OK, because they're take-out only, so they're not optimizing for the same thing the average sit-down restaurant is. Sure, that place is disgusting, but the food in box still tasted pretty good..."
A better comparison:
"This restaurant only has one table and 1 chair with a broken leg and gum stuck to the seat but that's ok because they're take-out only"
"This restaurant only has one table and 1 chair with a broken leg and gum stuck to the seat but that's ok because they're take-out only"
Coding for Android has taught me that is definitely not the case.
They managed to make a mess worse than JEE, the native layer took 10 years to finally use Android Modules, they keep fixing the header files, still don't have proper C++ bindings and force everyone to write JNI boilerplate by hand.
They managed to make a mess worse than JEE, the native layer took 10 years to finally use Android Modules, they keep fixing the header files, still don't have proper C++ bindings and force everyone to write JNI boilerplate by hand.
The Android base wasn't written by Google. Google bought the company that made Android 2 years after it was written. That's a lot of time to create a base system and a lot of time to create cruft.
By now, it's too late to rewrite the whole thing from scratch, hence a new OS https://en.wikipedia.org/wiki/Google_Fuchsia
By now, it's too late to rewrite the whole thing from scratch, hence a new OS https://en.wikipedia.org/wiki/Google_Fuchsia
That is no excuse. They had 10 years to fix it, and many issues steem from Google's HR to promote doing shinny toys instead of fixing broken stuff.
Android is really the worst platform for developers. Context? Let's make a god object, and also create application context and activity context, and screw liskov substitution principle. Also create a library to fix all our bugs in all versions of the platform, but also have a shit ton of bugs.
Microsoft did nail windows phone apis, 10 freaking years ago, too bad it didn't survive.
Microsoft did nail windows phone apis, 10 freaking years ago, too bad it didn't survive.
Yeah, keep using my Lumia and playing with UWP.
I think by attributing it do incompetence you're missing the incentives problem.
Others point this out, but Google just has no incentives to improve this UX. Think about who makes the decisions to use Google cloud and what criteria they are using.
The snappiness of the gcp ui is not likely to be near the top of their list
Others point this out, but Google just has no incentives to improve this UX. Think about who makes the decisions to use Google cloud and what criteria they are using.
The snappiness of the gcp ui is not likely to be near the top of their list
No incentive? AWS is crushing them, the UI is the product.
Slow software doesn't indicate a lack of skill.
It indicates that speed is not a priority for management.
It indicates that speed is not a priority for management.
[deleted]
Because it is both kind and safe to be charitable, and many problems can be explained without having to assume idiot developers.
I used to think Google hires only "top" developers. Lately I think they mostly hire average or below-average people which resulted in products of average or below-average quality.
Besides well known computing idols, it is basically who is able to put up with their hiring process and manages to score a job offer.
The puzzles make sure you can write the O(good) algorithm, knowing the coefficients is a question of experience and knowledge of the shoulders your code stands on.
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
[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.
>Which large companies aren't bad at web frontend?
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.
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.
But then look at FB Ads Manager - it's hard to imagine that such a horrible UX drives billions in revenue and yet no one seems to care.
I find Github and Amazon's main site to be pretty reasonable in comparison.
Amazon is about the last site I'd use as an example of a good UX. They've clearly been working on making it better, as the account drop-down has shrunk, but the amount of items on this screen is such that it really should have its own search to navigate it. A simple thing like buying a new gift card for someone is surprisingly clunky.
https://i.imgur.com/ZNKOkMN.png
https://i.imgur.com/ZNKOkMN.png
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.
I am simply happy that Amazon has not embraced the ridiculous trend of low-information density with large amounts of whitespace.
Give me a cluttered UI that has everything available any day.
Give me a cluttered UI that has everything available any day.
Totally. Cmd+F FTW, if you wanna search.
One pet peeve I have is getting to prime video. They own primevideo.com, but it just tells you to watch on Amazon. It's also the first result when you search (on google) for amazon prime video. There's no direct url to get it (afaik).
amazon.com/primevideo and amazon.com/video both go there.
The situation with primevideo.com is strange, but it seems to have something to do with non-US territories?
The situation with primevideo.com is strange, but it seems to have something to do with non-US territories?
PrimeVideo.com is the website (in addition to apps on mobile and living room devices like TVs and consoles) where customers outside of the US, UK, Germany, and Japan can watch Prime Video. In the aforementioned four countries, customers can watch Prime Video directly on their amazon.* retail website instead.
Thanks, I had no idea!
I felt the same way with Amazon. Before then it was easy to navigate and finding the product that I want to buy. Now, I couldn't navigate it well like I did in the past. And asian-sounding names products took over first few pages of result which made it difficult to filter out. And they are crap quality products. It is easily to tell which products is made in. Hint the brand name is all capitalized.
Really? Criticizing Google's frontends but praising GitHub and Amazon? If I had to pick a large tech company with a bad frontend Amazon would be top of the list. GitHub is not great either. I guess this kind of thing is just subjective though.
Github's site is really fast. Many of the pages it displays are dense with information and I think it displays everything well, for example viewing diffs in Github is very good, it smartly wraps all the text so you can view everything on the screen and everything loads fast. Try comparing it to Bitbucket's diff view, which can't wrap text amongst other things. It's light years better in comparison. It looks good at any window width with little wasted whitespace.
Amazon's site works pretty well. Their product range is quite a mess to navigate but I've never been annoyed much by their front end. It seems pretty well engineered, eg. [1]
[1] https://bjk5.com/post/44698559168/breaking-down-amazons-mega...
Amazon's site works pretty well. Their product range is quite a mess to navigate but I've never been annoyed much by their front end. It seems pretty well engineered, eg. [1]
[1] https://bjk5.com/post/44698559168/breaking-down-amazons-mega...
On the whole GitHub's UI is good, though I still find it unreasonably difficult/slow to do a review commit by commit compared to kiln.
I'd really like it if they added a way to thumb between commits in one click without page loads, kinda like flipping through pages of a book
I'd really like it if they added a way to thumb between commits in one click without page loads, kinda like flipping through pages of a book
What do you find lacking about GitHub's frontend?
For one, they're using some sort of link / browser history hijacking (something like https://github.com/turbolinks/turbolinks, IIRC) which is buggy, for example:
* say you're on page A
* navigate to page B
* navigate to page C
* click your browser's back button, hoping to be back at page B
* the github UI screws up and keeps you on the same page while changing the URL in the address bar
* so you click back again
* now your on page A, completely skipping page B
* clicking forward takes you back to C
Additionally, GitHub is insanely slow. This page, for example, takes 3 seconds to load: https://github.com/Boemska/create-sas-app/commit/85224fe6622...
Couple broken history back/forward navigation with long page load times and GitHub is easily one of the most frustrating web sites to use.
Don't get me wrong, I'm not arguing that GitHub doesn't have value -- it most certainly does -- but that doesn't excuse bugginess and absurdly long page load times. If they fixed these problems it would be 100% awesome.
* say you're on page A
* navigate to page B
* navigate to page C
* click your browser's back button, hoping to be back at page B
* the github UI screws up and keeps you on the same page while changing the URL in the address bar
* so you click back again
* now your on page A, completely skipping page B
* clicking forward takes you back to C
Additionally, GitHub is insanely slow. This page, for example, takes 3 seconds to load: https://github.com/Boemska/create-sas-app/commit/85224fe6622...
Couple broken history back/forward navigation with long page load times and GitHub is easily one of the most frustrating web sites to use.
Don't get me wrong, I'm not arguing that GitHub doesn't have value -- it most certainly does -- but that doesn't excuse bugginess and absurdly long page load times. If they fixed these problems it would be 100% awesome.
For me this page render instantly. i5 2500K, 16 GB RAM on Linux (I do have some aggressive tweaks).
Back and forward work great on GitHub. My mouse has additional buttons for these.
Back and forward work great on GitHub. My mouse has additional buttons for these.
> For me this page render instantly. i5 2500K, 16 GB RAM on Linux (I do have some aggressive tweaks).
My machine: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz, 128 GB RAM on Ubuntu Linux 20.04.
> My mouse has additional buttons for these.
Similar. As a sibling post mentions, the history hijacking does some nasty stuff -- unless you're lucky or something, I guess.
My machine: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz, 128 GB RAM on Ubuntu Linux 20.04.
> My mouse has additional buttons for these.
Similar. As a sibling post mentions, the history hijacking does some nasty stuff -- unless you're lucky or something, I guess.
The page switch fuckery I'm noticing is not quite as severe as what you described, but still annoying:
* say you're on page A, an open pull request
* merge the pull request
* switch to a different site entirely
* go back to github's page A
* notice how it shows the pull request as if it wasn't merged yet
* refresh the page and see the status switch to merged
I'm using Firefox and I've never tried reproducing this on Chromium.
* say you're on page A, an open pull request
* merge the pull request
* switch to a different site entirely
* go back to github's page A
* notice how it shows the pull request as if it wasn't merged yet
* refresh the page and see the status switch to merged
I'm using Firefox and I've never tried reproducing this on Chromium.
github is great, both web and mobile (especially mobile). and their new homepage is great too.
target's item pages are really good right now. I love the information density and layout on their site, which to me is suggestive of thoughtful human-oriented design rather than amazon's (highly effective) a/b test shit shoveling.
amazon has "ship-it" UI standards and a lot of variance in page section order (could be a/b testing, or just discrete developer teams).
they have lots of really interesting ideas scattered around for how they can reach customers with unique contextual information, but I have a hard time with how dynamic the layout is and they also don't know how to make good hero pages. too many over-compressed image banners and image tables.
amazon and github both have crappy search which is kind of interesting to me. amazon sort basically doesn't work either, for price or for rating. not sure why.
/ecommerce rant lol
target's item pages are really good right now. I love the information density and layout on their site, which to me is suggestive of thoughtful human-oriented design rather than amazon's (highly effective) a/b test shit shoveling.
amazon has "ship-it" UI standards and a lot of variance in page section order (could be a/b testing, or just discrete developer teams).
they have lots of really interesting ideas scattered around for how they can reach customers with unique contextual information, but I have a hard time with how dynamic the layout is and they also don't know how to make good hero pages. too many over-compressed image banners and image tables.
amazon and github both have crappy search which is kind of interesting to me. amazon sort basically doesn't work either, for price or for rating. not sure why.
/ecommerce rant lol
I personally love Airtable’s frontend. That’d be a project I’d love to work on.
> Which large companies aren't bad at web frontend? UX seems to always be far down on the list or priorities for modern websites.
which web frontend is good ? (except HN)
which web frontend is good ? (except HN)
notretarded(4)
Youtube UI/UX is horrible, try moving items in a long playlist, it takes forever to drag scrolling. Imagine a search engine company that doesn't have a quick search inside a playlist. And you need browser extensions like Youtube HD to fix several issues. It has been this way for years.
The elimination of dedicated playlist pages also sucks for resuming progress in the middle of a playlist
This is something that really concerns me about the new M1 based Macbooks. We as developers in the first world are very likely to be the first ones getting these, and this will make the gap with the average end user which usually does not have a mac a lot worse.
I'm not far from imagining a non so distant distopic future where everyone just gets used to slow, laggy, clunky websites and applications. Oh... wait...
I'm not far from imagining a non so distant distopic future where everyone just gets used to slow, laggy, clunky websites and applications. Oh... wait...
As a developer you should 1) have the fastest possible code / test cycle - i.e. it's worth overpaying for faster machines 2) treat performance as a feature and formally measure it across configurations
I've worked for many companies, small and large, corporate and startups. None of them had performance as a priority, or even considered at the product level. Any minimal performance optimization or win we had was because a developer cared enough for it.... but maybe I'm the only one and just had bad luck with the product managers/owners I had.
Amazon retail website ruthlessly optimized for latency as they discovered the slower it is, the more likely customers are to abandon their carts.
The only companies I have worked for that really cared for performance were betting companies, because speed is money in that sector (esp. in live betting).
In my experience performance became a secondary (not primary!) priority once big customers began to threaten to not renew their contracts
I have seen the same basic cycle, management says don't focus on perf, just "knock out" (I despise this lingo) the features. They have this overconfidence, but flop on the next release and patronize the dev team about perf.
1) tracked from the beginning so it is drained from the system merge by merge
2) architected in at the design level and not applied as a spell.
I really like what the rust team is doing with tracking rustc compilation times. Another reason that integration tests are the best tests.
https://perf.rust-lang.org/status.html
1) tracked from the beginning so it is drained from the system merge by merge
2) architected in at the design level and not applied as a spell.
I really like what the rust team is doing with tracking rustc compilation times. Another reason that integration tests are the best tests.
https://perf.rust-lang.org/status.html
We definitely promote performance as a primary (and a half) concern. Mainly because the alternative is throwing more money at servers and/or dealing with disgruntled customers. I wish we dedicated more resources to it but we also don't ignore it.
Oh! yes... certainly that was mi experience too. I was referring to frontend... where you won't pay for the performance, but your users will (by having to upgrade their compures and/or just suffering it)
And their material UI is ugly.
That idea is very common, and very silly.
Who says that if they experienced the software the same as a normal user, they would automatically improve its performance?
This may apply for parts of open source development, where developers work on stuff for their own use. But even they may have other priorities.
And as a commercial developer, your backlog is constantly full. You may have some leeway to choose what you work on, but there is absolutely no guarantee it will be performance, just because you personally experience bad performance.
The way to get performance improvements is to make it a business priority to measure and improve performance.
And for that, it is absolutely not necessary for developers to be slower in everything they do, just so they can experience their software's performance "realistically".
Who says that if they experienced the software the same as a normal user, they would automatically improve its performance?
This may apply for parts of open source development, where developers work on stuff for their own use. But even they may have other priorities.
And as a commercial developer, your backlog is constantly full. You may have some leeway to choose what you work on, but there is absolutely no guarantee it will be performance, just because you personally experience bad performance.
The way to get performance improvements is to make it a business priority to measure and improve performance.
And for that, it is absolutely not necessary for developers to be slower in everything they do, just so they can experience their software's performance "realistically".
I’m unsure why the original idea seems silly, when it simply states a possible reason for this problem today. Giving a developer observability is the first step, that’s what they are pointing out —- some ways developers interface with features don’t include information that could deliver a higher value feature. A company can choose whether to deliver that higher quality or not with that information, ignorance removes that choice.
If a company has that information and doesn’t care, that’s one thing. There’s more than a handful of companies that just don’t have the information to even know if they should care.
I think most people would agree that we should use tooling to make it so that developers are aware of their blind spots, such as supporting systems with lower resources or a more inconsistent network. The Netflix blog had a nice post that included a tool they used to observe the UX under certain failure cases, which is a nice example of this [0].
[0] https://netflixtechblog.com/keeping-netflix-reliable-using-p...
If a company has that information and doesn’t care, that’s one thing. There’s more than a handful of companies that just don’t have the information to even know if they should care.
I think most people would agree that we should use tooling to make it so that developers are aware of their blind spots, such as supporting systems with lower resources or a more inconsistent network. The Netflix blog had a nice post that included a tool they used to observe the UX under certain failure cases, which is a nice example of this [0].
[0] https://netflixtechblog.com/keeping-netflix-reliable-using-p...
I use this UI all day, every day on a Ryzen 3900 with 12 cores, 24 threads, 32GB RAM, 300Mbps connection. It's always extremely slow, takes up obscene amounts of CPU and RAM. It's mind-boggling how they think, "this is ok".
The move to, "let's show them a pretty G spinner to compensate, because research shows that'll make them think it's fast" irks me to no end.
The move to, "let's show them a pretty G spinner to compensate, because research shows that'll make them think it's fast" irks me to no end.
Here's a couple of tabs, one is a dashboard taking up 1.5GB RAM, the other is a k8s deployment page, taking up 1GB. It seems any tab takes up a ton of RAM. CPU also locks up completely in those tabs routinely. The chance that occurs correlates with how long a tab is open.
https://imgur.com/a/i9L45ZM
https://imgur.com/a/i9L45ZM
This happens with web design a lot. I have a great monitor with a 1080p budget monitor on the side. It makes a huge difference when thinking about shadows, UI changes, etc which are almost invisible on the 1080p sometimes. I test my sites on both.
I agree. I have a second, crummy old laptop for just this reason. I can't quite bring myself to develop on an underpowered machine, but it is useful to have one as a reference. Also, my phone is old because I'm a cheapskate, so that helps tremendously with assessing mobile performance.
>> I agree. I have a second, crummy old laptop for just this reason.
Learned this the hard way. Made an editor, everyone loved it. Added features, people loved it. Kept adding features...then it was called slow, bloated etc.
Everything seemed fine on my new-at-the-time iMac.
Went into a conference room where we had one of the first Intel MacBook Pros...there were portions of the editor where you could literally see things being redrawn. A night of optimizations later, performance was restored.
Learned this the hard way. Made an editor, everyone loved it. Added features, people loved it. Kept adding features...then it was called slow, bloated etc.
Everything seemed fine on my new-at-the-time iMac.
Went into a conference room where we had one of the first Intel MacBook Pros...there were portions of the editor where you could literally see things being redrawn. A night of optimizations later, performance was restored.
> I would not be surprised if a lot of these problems could be traced back to developers having above-average network connections and super beefy computers
More realistically, they're serving up the assets from a web server on their machine. Which means that network I/O time is effectively nil.
More realistically, they're serving up the assets from a web server on their machine. Which means that network I/O time is effectively nil.
I suspect there's something in that comment on above-average network connections - the people working on Google Cloud's UI are going to be doing so from Google networks, or over a Google VPN, which means they'll be seeing much lower latency to your average person who has to be bounced around their ISP network and then across a couple of peering providers before getting there.
There can be some more nuance to this. The devs can often see the problems, but know more optimization is needed. They've done everything to implement what a PM asked.
When the PM views it with ideal network conditions they assume it's more than ready. At this point their focus is on shipping sooner so the next thing can be worked on. The devs can never talk them back. Users then complain on Twitter about the crappy perf.
This is a process and cultural failure too. The perf can be quantified and tracked to some extent. Even proxy metrics like the growth of assets over time can help.
Cultural events like poor handling of weekly demo days can create undue pressure on shipping poor implementations. Someone implements a great idea badly, it catches management attention (or helps the sales team), and next Monday it gets released. Over time this behavior can hurt customers and it always frustrates internal efforts to do the right things for perf.
When the PM views it with ideal network conditions they assume it's more than ready. At this point their focus is on shipping sooner so the next thing can be worked on. The devs can never talk them back. Users then complain on Twitter about the crappy perf.
This is a process and cultural failure too. The perf can be quantified and tracked to some extent. Even proxy metrics like the growth of assets over time can help.
Cultural events like poor handling of weekly demo days can create undue pressure on shipping poor implementations. Someone implements a great idea badly, it catches management attention (or helps the sales team), and next Monday it gets released. Over time this behavior can hurt customers and it always frustrates internal efforts to do the right things for perf.
Throughout 2020, this hasn't actually been true.
This stuff is dead slow even on a fast machine with fast connections.
The problem isn't people don't know. The problem is the software is drowning in layers of complexity and abstraction, and it's all in JavaScript not an optimized native language.
The problem isn't people don't know. The problem is the software is drowning in layers of complexity and abstraction, and it's all in JavaScript not an optimized native language.
My company fixed this by making us use under dimensioned VMs for development. Unfortunately it has not fixed the issue.
[deleted]
> above-average network connections and super beefy computers
Googlers have been WFH since March on laptops and residential Internet & WiFi.
Googlers have been WFH since March on laptops and residential Internet & WiFi.
Thats so true, devs also should try out a 5 year old phone and a slower ISP.
Google's UI's in general are shockingly slow. I don't understand why my Google Drive and Gmail have input lag and choppy animations on my 5 year old xps13, it's not that hard to make navigating a filesystem or list of emails fast. Actually I do understand, it's because they want everything they build to be made in a massive javascript framework with shared components, which looks nice but runs like garbage on anything not modern.
The original gmail design was so fast, beautiful and minimalistic. It had vi key bindings and was close to perfect.
The new one had a bunch of useless white space and the app has a loading bar!
Wtf?!
The new one had a bunch of useless white space and the app has a loading bar!
Wtf?!
Yeah the Gmail UI has become absolute garbage lately.
The fact that i need to see a cute-dystopian loading animation for 2 seconds each time i reload the page is incredible.
Send plain HTML, then make JS take over after loading like most modern frameworks can do.
.. yes i really have to ditch Google ..
On a sidenote YT has also become a dystopian addiction machine - years ago you could easily curate what you saw, feeds, channels etc, now everything is controlled by the "google god skinner box algo" just like i feel Gmail is headed towards with all kinds of automated tools.
The fact that i need to see a cute-dystopian loading animation for 2 seconds each time i reload the page is incredible.
Send plain HTML, then make JS take over after loading like most modern frameworks can do.
.. yes i really have to ditch Google ..
On a sidenote YT has also become a dystopian addiction machine - years ago you could easily curate what you saw, feeds, channels etc, now everything is controlled by the "google god skinner box algo" just like i feel Gmail is headed towards with all kinds of automated tools.
> The fact that i need to see a cute-dystopian loading animation for 2 seconds each time i reload the page is incredible.
They did the same thing for GC UI. They think it tricks the user into thinking it's fast, instead of making it fast.
They did the same thing for GC UI. They think it tricks the user into thinking it's fast, instead of making it fast.
The original design was done with function first and form received almost no attention which was typical for Google for a long time.
As design overall started to become more relevant in products Google started to push out their redesigns but it was done with form instead of function as the focus. They've never really re-designed anything to be better - their updates have usually made the product worse.
But without a strong design leader it's death by a thousand cuts because there are so many layers of management to getting anything done.
As design overall started to become more relevant in products Google started to push out their redesigns but it was done with form instead of function as the focus. They've never really re-designed anything to be better - their updates have usually made the product worse.
But without a strong design leader it's death by a thousand cuts because there are so many layers of management to getting anything done.
FYI you can still switch to the old design. When the fake loading screen (https://smitop.com/post/gmail-s-fake-loading-indicator/) is loading, click on the bottom on "Prefer old design". Then you can set that as default. It is an absolute must for me given how fast it is.
Note that objectively speaking the basic HTML gmail is slower in every aspect, except for the initial page load. Everything but the initial page load is slower. The main web app has extensive latency-hiding features that are key to Gmail's overall performance story. The basic HTML UI has none of these features. Every action in the basic UI takes half a second or more because it's a server round trip.
Example: load the basic HTML and enter a thread then return to the thread list. Returning to the thread list takes about 1 second. In the full gmail return to thread list takes no remote time, only local event handler CPU time, it's almost instantaneous.
Example 2: Open a thread in the basic UI and use "newer" or "older" to navigate to other threads. Every click takes ~1s. In the full Gmail UI navigate to adjacent thread takes almost no time, because the app pre-loads these threads in anticipation of you visiting them.
TL;DR the basic HTML gmail is good if your device is severely resource-poor and you just need to see if you have mail. For every other purpose it's worse.
Example: load the basic HTML and enter a thread then return to the thread list. Returning to the thread list takes about 1 second. In the full gmail return to thread list takes no remote time, only local event handler CPU time, it's almost instantaneous.
Example 2: Open a thread in the basic UI and use "newer" or "older" to navigate to other threads. Every click takes ~1s. In the full Gmail UI navigate to adjacent thread takes almost no time, because the app pre-loads these threads in anticipation of you visiting them.
TL;DR the basic HTML gmail is good if your device is severely resource-poor and you just need to see if you have mail. For every other purpose it's worse.
Keep seems to have gotten slower and slower over the years too - the web version is practically unusable on mobile, not just because the UI design isn't responsive (!), but because it's so painfully slow.
Boggles the mind how Google web apps have performance issues like this.
Boggles the mind how Google web apps have performance issues like this.
Wait, you think https://mail.google.com/mail/mu, the mobile web version aka "superpudu" is slow? Can you tell me your device? It paints itself in only 400ms on my iphone. I actually prefer it over the app because it's so fast.
My comments were about Google Keep, not Gmail, though I do actually find the Gmail web app pretty slow too - it takes several seconds to send an email.
I didn't know there was some kind of secret mobile Web version of Gmail - I get a blank white page when I open your link on mobile tho (using Brave)?
I didn't know there was some kind of secret mobile Web version of Gmail - I get a blank white page when I open your link on mobile tho (using Brave)?
Oh, I totally scanned passed "Keep" in your comment. The mobile web version of that does indeed seem a bit rough. It's been a while since I worked at Google but when I did, Keep was a one-engineer project so the amazing thing is it exists at all.
5.5 sec for that link to show anything other than a blank white page on a Pixel 4a.
I thought it was a broken page at first.
I thought it was a broken page at first.
It still has the pseudo-vi key bindings that you can turn on in settings. I've been really satisfied with how fast it is to do anything because of the key commands + relatively quick response and autocomplete (except click on links because I have to turn off Vimium for Gmail).
The Inbox by Gmail version loaded instantly, had inline emails and loads of other cool features that got half-arsed forced into the older gmail codebase.
Google made a superior replacement to the current gmail experience and then just threw it away like it never existed.
Google made a superior replacement to the current gmail experience and then just threw it away like it never existed.
FWIW you can select a setting to enable keyboard shortcuts, which are the vi key bindings.
I enabled that a while back which makes navigating emails much more pleasant
I enabled that a while back which makes navigating emails much more pleasant
I noticed this for last few years. Google stuffs been increasingly adding much JS in their stuff every year and that bogging down my system. Even loading Google Drive took average 6 second to fully load whereas it was about 3 seconds last year. YouTube is not quick to load anymore like it was before. And this is all in Chrome and other Chromium-based browsers.
It doesn't look nice. It looks a lot worse than 10-years ago. But it is more compatible with i18n/l10n and accessibility plugins and compatibile components across a dozen chat apps
It's all slow because it can be. People will put up with it because they have a virtual monopoly on all these free cloud services. What are people going to do, go back to saving locally and use something like LibreOffice?
Here's an anecdote: my partner used to work at PayPal, and they had a entire team dedicated to just the "wallet" portion of the web UI. There were reasons for this: that piece of the UI had to work in all nationalities, for all languages and currencies, in every browser on every device under the sun.
But here's what I'm thinking: I wouldn't be surprised if every single tab in the Google Cloud UI had its own team, with their own practices, dependencies, resources that need to be loaded, etc. And I wouldn't be surprised if there's nobody in the organization whose job it is to consider the Google Cloud Dashboard as a whole product, in terms of making it a cohesive experience, eliminating redundancies between independent pieces, doing cross-cutting optimizations, getting everybody on the same page. Given how many different things are stuffed into the interface (just look at the navigation menu), that would certainly lead to some bloat.
But here's what I'm thinking: I wouldn't be surprised if every single tab in the Google Cloud UI had its own team, with their own practices, dependencies, resources that need to be loaded, etc. And I wouldn't be surprised if there's nobody in the organization whose job it is to consider the Google Cloud Dashboard as a whole product, in terms of making it a cohesive experience, eliminating redundancies between independent pieces, doing cross-cutting optimizations, getting everybody on the same page. Given how many different things are stuffed into the interface (just look at the navigation menu), that would certainly lead to some bloat.
You're on the right track.
A team does exist to consider the whole Dashboard, but they were late to ramp up and were initially extremely under-staffed.
GCP's UI grew out of needing to unify features between Storage and the App Engine UIs, which were initially completely separate codebases. The solution started with "Just port the App Engine stuff into whatever Storage is using." But then they tried to extrapolate that model to every sub-component, and it went... Not great. And engineering management were late to realize how badly it was going.
A team does exist to consider the whole Dashboard, but they were late to ramp up and were initially extremely under-staffed.
GCP's UI grew out of needing to unify features between Storage and the App Engine UIs, which were initially completely separate codebases. The solution started with "Just port the App Engine stuff into whatever Storage is using." But then they tried to extrapolate that model to every sub-component, and it went... Not great. And engineering management were late to realize how badly it was going.
My pet peeve is that a lot of the GCP console doesn't even seem to work in Firefox. For example:
https://github.com/webcompat/web-bugs/issues/61522
https://github.com/webcompat/web-bugs/issues/61522
Cloud SSH has been broken for months https://github.com/webcompat/web-bugs/issues/57957 - no movement despite reporting it via the official channels too.
This is one of the first features a new GCE user is likely to use (if they're exploring the UI and haven't yet started using the CLI) - and it's broken out of the box. Amazing.
It's amateur hour over there when it comes to frontend development - it's not a web app where cross-platform/cross-browser testing takes place, it's a Chrome app.
This is one of the first features a new GCE user is likely to use (if they're exploring the UI and haven't yet started using the CLI) - and it's broken out of the box. Amazing.
It's amateur hour over there when it comes to frontend development - it's not a web app where cross-platform/cross-browser testing takes place, it's a Chrome app.
Feature-chasing. Firefox compatibility is a feature that nets them something like 5% of potential users. When they crunch the numbers, that's fewer than the 3 to 5 corporations they can get into their scope of market if they add the table-stakes features those corps require to consider GCP.
And Google's take on it is that a FF user can always switch to Chrome, since Chrome runs on all OSs that support FF.
FF support is, in theory, part of the acceptance criteria for new development, but it's not on the blocking list so it's not really part of the acceptance criteria.
And Google's take on it is that a FF user can always switch to Chrome, since Chrome runs on all OSs that support FF.
FF support is, in theory, part of the acceptance criteria for new development, but it's not on the blocking list so it's not really part of the acceptance criteria.
Many of Google owned products do not work on Firefox. Google analytics is another example.
yes - it has bad UX and it's broken in Firefox
I don't if this true but I have realized whenever I try to access google apps in firefox they are slow and sometimes breakdown but when I try to do it in chrome they just work fine.
Like I was trying to submit some work using google classroom on firefox it wasn't letting me upload the work but when I did it in chrome it just worked well
Like I was trying to submit some work using google classroom on firefox it wasn't letting me upload the work but when I did it in chrome it just worked well
The consequence of this is not that I think Firefox is bad, by the way. It's that I think Google are a bunch of idiots.
Yet another "oops" to add to the pile
https://twitter.com/johnath/status/1116871246510264320
https://twitter.com/johnath/status/1116871246510264320
The conspiracy theorist in me wants to believe that this is not incompetence, but sabotage. Everyone uses Google products; if they work fast in chrome and slow on firefox, people will blame Firefox, not Google. And therefore will eventually switch to Chrome.
Good strategy to steal market share.
Good strategy to steal market share.
It's not intentional sabotage; it's positive feedback loops.
Using Chrome, your tooling experience developing software at Google is, maybe, 1% faster. Some of that is core (TBH, FF's engine is old and creaky and webkit-derived browsers out-perform it on all kinds of metrics, though FF has significantly closed the gap). Some of it is that teams develop for Chrome first, because it's the first browser shortcut available. Plus, Chrome has all kinds of extensions built in-house at Google to make your life easier, and those have to be rewritten from scratch if someone wants them for FF also.
So now when you're doing UI development and testing it, your first testbed is always Chrome, because it's what you're using as a developer. So bugs always get seen first in Chrome, and only seen in FF if your team has acceptance testing requirements or you happen to have a team member who uses FF. So the gap widens: now using Chrome in Google is, maybe, a 5% better experience, because you're that much less likely to hit bugs the developing team hasn't hit yet. And th positive feedback loop continues.
The only way I'm aware of to stop this is to force teams to put half their engineers on using FF as their primary browser, and I've never seen a team willing to do so.
FF has die-hard supporters inside Google, but few are so die-hard they're willing to intentionally slow down their own development velocity by using a less-supported browser. Google's too competitive to incentivize that.
(Note: this applies to bugs that crop up between OS platforms also, because that happens---sometimes, the details of Chrome on MacOS surface a bug that never shows up on Linux. Some teams do require one engineer at least to use Mac, because the MacOS userbase is big enough that there's financial incentive to not break it. FF has like 5% market share; there's no such incentive there).
Using Chrome, your tooling experience developing software at Google is, maybe, 1% faster. Some of that is core (TBH, FF's engine is old and creaky and webkit-derived browsers out-perform it on all kinds of metrics, though FF has significantly closed the gap). Some of it is that teams develop for Chrome first, because it's the first browser shortcut available. Plus, Chrome has all kinds of extensions built in-house at Google to make your life easier, and those have to be rewritten from scratch if someone wants them for FF also.
So now when you're doing UI development and testing it, your first testbed is always Chrome, because it's what you're using as a developer. So bugs always get seen first in Chrome, and only seen in FF if your team has acceptance testing requirements or you happen to have a team member who uses FF. So the gap widens: now using Chrome in Google is, maybe, a 5% better experience, because you're that much less likely to hit bugs the developing team hasn't hit yet. And th positive feedback loop continues.
The only way I'm aware of to stop this is to force teams to put half their engineers on using FF as their primary browser, and I've never seen a team willing to do so.
FF has die-hard supporters inside Google, but few are so die-hard they're willing to intentionally slow down their own development velocity by using a less-supported browser. Google's too competitive to incentivize that.
(Note: this applies to bugs that crop up between OS platforms also, because that happens---sometimes, the details of Chrome on MacOS surface a bug that never shows up on Linux. Some teams do require one engineer at least to use Mac, because the MacOS userbase is big enough that there's financial incentive to not break it. FF has like 5% market share; there's no such incentive there).
> those have to be rewritten from scratch if someone wants them for FF also.
What? Why are they not standard WebExtensions?
What? Why are they not standard WebExtensions?
Because (a) most of them predate the standardization of WebExtensions and (b) that API still isn't standardized enough to make building against it as cheap as building a chrome specific extension.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Former Mozilla exec: Google has sabotaged Firefox for years (zdnet.com)
https://news.ycombinator.com/item?id=19669586
https://news.ycombinator.com/item?id=19669586
Agreed but if they work fast in chrome just use chrome for that otherwise keep using firefox
I left using chrome 3 years ago and I haven’t really missed out and I honestly love firefox
I left using chrome 3 years ago and I haven’t really missed out and I honestly love firefox
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 fast front ends.
And front end devs are often using tools designed for back end devs, like the Bazel build system. (Compare that to FB having online / incremental compilers for Hack, as far as I understand.)
So they either don't get the best people working on front ends, or the people they have aren't doing their best work because they're looking to move into a role that may be more respected or rewarded.
Before 2005, Google built two of the most innovative AJAX apps ever: GMail and Maps. People may not remember how awesome they were. When GMail came out, it was faster than Microsoft Outlook on desktop, which I was using at the time. You would click and your message would appear instantly, which was not true of desktop apps. The app startup time was also better than desktop! (i.e. seeing all your messages from a cold start)
When Maps came out, people didn't believe that the scrolling and zooming could be done without a Flash app. It also had incredibly low latency.
But somewhere along the way the company lost its leadership and expertise in the web front end, which I find very sad. (I worked there for many years, but not on front ends.) The slow Google+ app circa 2011 was a great example of that, although I believe the structural problem had set in before that project.
I don't think there's any question that FB and even MS are significantly more accomplished in these areas. They're the "thought leaders" (React, Reason, TypeScript, etc.)
---
edit: Also, if you want to remember what Google UI looked like circa 2005, look at sourcehut: https://man.sr.ht/
It was fast, simple, and had a minimalist style (though some people mistake that for no style). There is probably a generation of people who are scratching their heads at that claim, but yes that's pretty much what Google used to look like: the home page, which lacked JS; News; Groups; Webmaster Tools; Ads front end to some extent, etc.
And front end devs are often using tools designed for back end devs, like the Bazel build system. (Compare that to FB having online / incremental compilers for Hack, as far as I understand.)
So they either don't get the best people working on front ends, or the people they have aren't doing their best work because they're looking to move into a role that may be more respected or rewarded.
Before 2005, Google built two of the most innovative AJAX apps ever: GMail and Maps. People may not remember how awesome they were. When GMail came out, it was faster than Microsoft Outlook on desktop, which I was using at the time. You would click and your message would appear instantly, which was not true of desktop apps. The app startup time was also better than desktop! (i.e. seeing all your messages from a cold start)
When Maps came out, people didn't believe that the scrolling and zooming could be done without a Flash app. It also had incredibly low latency.
But somewhere along the way the company lost its leadership and expertise in the web front end, which I find very sad. (I worked there for many years, but not on front ends.) The slow Google+ app circa 2011 was a great example of that, although I believe the structural problem had set in before that project.
I don't think there's any question that FB and even MS are significantly more accomplished in these areas. They're the "thought leaders" (React, Reason, TypeScript, etc.)
---
edit: Also, if you want to remember what Google UI looked like circa 2005, look at sourcehut: https://man.sr.ht/
It was fast, simple, and had a minimalist style (though some people mistake that for no style). There is probably a generation of people who are scratching their heads at that claim, but yes that's pretty much what Google used to look like: the home page, which lacked JS; News; Groups; Webmaster Tools; Ads front end to some extent, etc.
I remember there was pretty similar post from ex-Wave engineer about exactly that -- they put "best" engineers (if such thing exists) on backend, and neglected frontend. It might not be the main reason for its utter failure, but it did contrubute.
I had one-off experience recently: tried to add IPv6 CIDR for accessing k8s master, and FE validated it perfectly but somewhere on BE they validated it with regexp that accepted only IPv4 CIDRs, but at least up to 999.999.999.999/99, so not that bad. /s
Hard to believe. FE devs will be evaluating and hiring other FE devs for all purposes, so this problem shouldn't exist. Besides they did the whole material design research. I agree that their UIs overall just suck though. Don't know what they do wrong, if anything I felt they take an overtly scientific approach to UX which sometimes needs something of an artistic bend.
[deleted]
Just look at what library they are using. Google used to use their industry-leading Closure library that's far better than anything outside Google. Then they flirted with multiple iterations of Angular and Dart and probably something else, but the rest of the industry has caught up and surpassed what Google has to offer.
Many people here seem to think this is due to incompetence, I don't. It's due to a lack of focus on speed as an indicator of quality.
I think Google devs are perfectly capable of building fast frontends, maybe they even want to, but if they're not rewarded for it (but are rewarded for "getting things done") they won't.
It's management's fault.
I think Google devs are perfectly capable of building fast frontends, maybe they even want to, but if they're not rewarded for it (but are rewarded for "getting things done") they won't.
It's management's fault.
But that is just managerial incompetence and the inability of the devs in question to push back against that managerial incompetence.
> that is just managerial incompetence
Isn't this making a bit of a leap? Management could be correctly measuring that keeping load times below 1s will cost them $10m/year and yield them $1m/year in increased revenue (made up numbers for the sake of example, of course), i.e. making improvements would have negative ROI.
I'd love for the console to be faster, but it's already way better than AWS (I haven't tried Azure so can't comment there) so I'm not sure I'd want to increase my cloud spend just to get better load times.
There's a general cognitive bias on HN where performance is assumed to be a feature that your product _must_ have, because we bias heavily towards individuals that appreciate good craftsmanship in our tools. I like well-crafted tools too, but it's important to keep in mind that the ROI on polishing a tool isn't always there, and that's one of the realities of life in a world of scarcity with limited resources to be allocated.
This is just speculation of course, it could well be that GCP's management is incompetent, and they haven't measured the dollar-per-unit-performance tradeoff; my point is that I don't think you've substantiated the claims of incompetence, rather you've assumed that the ROI on performance improvements must be positive. I know Google has done such experiments on the loading time for search results, I'd be interested to hear if anyone knows the details about whether this has been done in GCP.
Isn't this making a bit of a leap? Management could be correctly measuring that keeping load times below 1s will cost them $10m/year and yield them $1m/year in increased revenue (made up numbers for the sake of example, of course), i.e. making improvements would have negative ROI.
I'd love for the console to be faster, but it's already way better than AWS (I haven't tried Azure so can't comment there) so I'm not sure I'd want to increase my cloud spend just to get better load times.
There's a general cognitive bias on HN where performance is assumed to be a feature that your product _must_ have, because we bias heavily towards individuals that appreciate good craftsmanship in our tools. I like well-crafted tools too, but it's important to keep in mind that the ROI on polishing a tool isn't always there, and that's one of the realities of life in a world of scarcity with limited resources to be allocated.
This is just speculation of course, it could well be that GCP's management is incompetent, and they haven't measured the dollar-per-unit-performance tradeoff; my point is that I don't think you've substantiated the claims of incompetence, rather you've assumed that the ROI on performance improvements must be positive. I know Google has done such experiments on the loading time for search results, I'd be interested to hear if anyone knows the details about whether this has been done in GCP.
Isn't that incompetence too?
Former front-end dev of this UI here. This article makes the assumption that Google's primary goal is performance/page load. It's not. Feature parity and dev speed is. With a gigantic app like Cloud with hundreds of developers, there are massive technical hurdles surrounding things like independent releases, split bundles, and technical debt.
Google's business model for Cloud is b2b. The bottom line for getting b2b contracts normally comes down to requested features (among other things). Page load time doesn't factor as much comparatively, so these priorities do make sense. Not to say performance isn't on everyone's roadmap, but Google has and will continue to make strategic decisions that sacrifice performance over things like dev speed.
Google's business model for Cloud is b2b. The bottom line for getting b2b contracts normally comes down to requested features (among other things). Page load time doesn't factor as much comparatively, so these priorities do make sense. Not to say performance isn't on everyone's roadmap, but Google has and will continue to make strategic decisions that sacrifice performance over things like dev speed.
Google seems to fail to realize that cloud b2b starts with b2developer. A one single developer. Create an environment that developers love, and these developers will find ways to make b2b happen. Sell bottom up.
(and in case anyone from gcp is reading, not only the interface is atrociously slow - which makes me doubt the quality of engineering on the infrastructure side of things that I am supposed to be paying for - but the quota system is beyond terrible as well. Just the other day I wanted to experiment with youtube api to see what it can do, and it made me fill a quota increase form with at least two dozen questions almost asking what is my business plan with this - do you want users to use the api or not?)
(and in case anyone from gcp is reading, not only the interface is atrociously slow - which makes me doubt the quality of engineering on the infrastructure side of things that I am supposed to be paying for - but the quota system is beyond terrible as well. Just the other day I wanted to experiment with youtube api to see what it can do, and it made me fill a quota increase form with at least two dozen questions almost asking what is my business plan with this - do you want users to use the api or not?)
Even solo developers don't really choose a cloud platform based on the zippiness of the web UI. I've used Azure and briefly dabbled in AWS's web UIs, they're not better and are worse in some cases. Critical administration tasks are going to be wrapped and reused in CLI, the web UI is usually for ad-hoc stuff.
This is a pretty core staple of the b2b market: customers, even small ones, respond mostly to price & features that save a significant amount of time & money; Sorry but a sluggish web UI while annoying won't move the needle much on the bottom line.
This is a pretty core staple of the b2b market: customers, even small ones, respond mostly to price & features that save a significant amount of time & money; Sorry but a sluggish web UI while annoying won't move the needle much on the bottom line.
Not sure which awesome company you work at, but in most organizations infra is a cost center, and thus the decisions related to it are mostly done by managers, not developers. And this is why AWS sells and not Heroku.
The G Suite (now Google Workplace) admin console GUI is also pretty slow. What makes it worse is that you have no other choice - it's the only complete tool for administrating G Suite. There are APIs for some things, but quite a lot is only available in the GUI, and new features always show up there first (if they ever make it to the API at all).
There isn't even a way to import/export settings, so you have to painstakingly document everything and reconfigure it manually if you need to create a new instance. It makes things pretty painful from a compliance point of view.
There isn't even a way to import/export settings, so you have to painstakingly document everything and reconfigure it manually if you need to create a new instance. It makes things pretty painful from a compliance point of view.
The Workplace admin console is unbelievably bad, and search is a joke. Not being able to search for aliases causes issues nearly daily.
G Suite is the worst piece of shit I have to use in my work and I curse the developers every time I'm forced to use it. It's like they went out of their way to make the worst design choices at every point. It would be impressive if it wasn't so depressing.
I can't even get through to G Suite support lately since the only way is through the admin console chat bot, which is bugged and freezes at "transfer me to Cloud Support". Absolutely one of the worst products I have to use on a day-to-day basis.
Whats the BigCo alternative to MS and Google office suites?
The medium is the message. In some domains, slow and clunky feels like gravitas and reliability. Enterprise software. Enterprise recruiting software. AWS has a pretty slow, and clunky dashboard. AdSense is clunky. A lot of the biggest companies' flagship apps have a very bland "bureaucratic" look and feel. You may find it hard to believe, but Zuck wanted facebook to look like a government database for a long time, where you type in someone's name and see details about them. Engineers will probably scoff at these notions, because it seems to suggest that underlying their "real" engineering concerns, are implicit aesthetics they would neither say they agree with nor be aware of, but it's real. If you're deep in the medium, maybe you don't even see it as a medium anymore, and you don't realize its quirks.
Slow and clunky is also unreliable, it's did it go through?, did I click on that? Is it loading, or is my connection having troubles? Is the browser again?
Some of the ugliest Gov and Gov adjacent pages (e.g. tax collectors, some DMVs) are fast and prompt zero second guessing. They just work.
Some of the ugliest Gov and Gov adjacent pages (e.g. tax collectors, some DMVs) are fast and prompt zero second guessing. They just work.
The slow and clunky I referenced don't have "loading semantics" issues, they all show loaders, action statuses, and many indicate connectivity and save progress for multipage sagas. But you are right that slow and clunky can be unreliable, but so can slick and snappy. Tho, neither of them have to be. In some domains, slick and snappy can feel insubstantial and off-key. It's interesting that the pages you reference are "consumer" products, not enterprise, so that's inline with how I think this goes. I think basically we're talking about orthogonal kinds of slow and clunky, yours is more the engineering focus of how it works, and mine is, like I said in the parent comment, about the aesthetics and the medium in a domain.
I have never seen anyone in government or big corporate (including management and HR) put down a site for being too fast to load or react. I've seen plenty of instances where they've railed on one for being sluggish or unresponsive...certainly aesthetics are important for a subset of enterprise users (namely those who have to drink/act like they've drunk the kool-aid), but most folks aren't idiots and can definitely feel when something is objectively slow.
I get if you feel that aesthetics are a deliberate adoption only of those kool aid drinkers and "idiots", but that viewpoint probably just contributes to how you can't see that aesthetics and medium are a thing, that people expect but are unaware of. Because you wouldn't want to see yourself as a kool aid drinker or idiot, right. Meaning you're blind to it's effects, which I'm not saying makes you say idiot. This dynamic happens everywhere. It's similar to how people choose familiarity, over what "objectively" is better. What you said matches what I'm saying about it. People can tell when something is slow and clunky, or slick and snappy, and while they may praise, or rail, it doesn't mean they will think slick and snappy works better, or feel more comfortable using it. This is why those big softwares don't violate your implicit expectations that they are slow and clunky.
Another thing is just because people complain (about their enterprise software, or country, or house, or romantic partner) does not mean they would switch. And just because they praise your slick and snappy startup enterprise app doesn't mean it will solve their problem better, doesn't mean they'll feel more comfortable using it, and doesn't mean they'll buy it.
Another thing is just because people complain (about their enterprise software, or country, or house, or romantic partner) does not mean they would switch. And just because they praise your slick and snappy startup enterprise app doesn't mean it will solve their problem better, doesn't mean they'll feel more comfortable using it, and doesn't mean they'll buy it.
I think my point emphasized aesthetics too much to the detriment of the main argument, so let me rephrase: aesthetics are also important if you want a of majority enterprise users to enjoy using your product (ask anyone who has had to deal with SAP). There will always be a few who love the brutalist or "power user" UI, but I think we're in agreement that visual appearance does matter.
With all that out of the way, the example I _wanted_ to raise above (but neglected to, apologies) with the "kool-aid" drinkers is that corporate users are absolutely aware of how fast and responsive something is _in addition_ to how it looks. I think many folks have been in a screen share or training session where the presenter has to awkwardly wait for an application they're "selling" to load or respond to input. Is the presenter oblivious to this latency? I'd say they are even more aware given the audience, if not flustered. That was the thrust of "people are not idiots".
WRT why people continue to use this software, I think you underestimate the impact of top-level purchasing/procurement and the captive enterprise audience. Those making purchasing decisions are less likely to use software after the sales demo and thus are not exposed to any UX or latency issues. Again. there is no idiocy or mal-intent here either, it's just an artifact of how bigcos operate.
With all that out of the way, the example I _wanted_ to raise above (but neglected to, apologies) with the "kool-aid" drinkers is that corporate users are absolutely aware of how fast and responsive something is _in addition_ to how it looks. I think many folks have been in a screen share or training session where the presenter has to awkwardly wait for an application they're "selling" to load or respond to input. Is the presenter oblivious to this latency? I'd say they are even more aware given the audience, if not flustered. That was the thrust of "people are not idiots".
WRT why people continue to use this software, I think you underestimate the impact of top-level purchasing/procurement and the captive enterprise audience. Those making purchasing decisions are less likely to use software after the sales demo and thus are not exposed to any UX or latency issues. Again. there is no idiocy or mal-intent here either, it's just an artifact of how bigcos operate.
I think I get what you're saying. So kool-aiders are the ones who, true believers or not, need to sing praises of software foisted upon them as a captive enterprise audience by an inefficient top-level purchasing/procurement system. So, people are not idiots, means that most people, even some non-zealot kool-aiders see things don't work and could be better in such situations.
I totally agree. I think what happened with us is, as is the case in most of these things, we were talking about orthogonal or parallel things.
I'm not assuming your agreement with my belief that aesthetic, even "brutalist" or "slow and clunky", will connote quality to a certain subset of users, enterprise being one example. I think your might have took it to mean I was saying "haha, therefore I think enterprise users are idiots." Which is not what I meant, but I get how you could see that. I don't think an aesthetic preference, even one which may on the face of it seem maladaptive, means people are idiots. I don't think it's a maladaptive preference, it's a natural thing, and there's reasons for it that work. I suppose it's a form of stereotyping, that allows people to form quick judgments from limited information.
And I'm aware of the research that says that a "good UI" can hide other problems, and be easier to use. So on the face of it, that would seem to say software with "slick and snappy" UX will be more prevalent, or at least be completely wiping the floor with the "slow and clunky" competition. But it's not -- at least not at the high end of the market that I care about. So this is an idea I have about that.
Actually, my criticism, if it was with any group, was with the developers who want the new shiny above all else, and seem to fail to see the practical benefits of practices done by bigcos, even when the success of those products is right in front of them. I think such blindness is stupid. But the developers are not stupid.
My back story is I, even when I wasn't someone who valued new and shiny above all else, once thought, "all I need to do is consumer-productize" enterprise apps and everyone will love them. But that's not all that's required. So I don't underestimate the sales process, I'm just coming at it from the point of view that aesthetics are a component of that decision, albeit an implicit and probably by necessity unspoken one (otherwise: "This UI looks too fancy and the app is too fast. We can't trust these guys, but the old-reliable, clunky and 80s-looking app we've been buying for 20 years just works great for what it is." ~~ but, hey, maybe people really do say that!).
I think you can sell the unfamiliar (product, narrative) using the familiar vehicle (product, narrative, aesthetic). So if you want to do something new, the best way is to serve it to people in a package they already like and are familiar with. I believe that as a general principle. But in this more specific case we're talking about here, I just think I see the importance of aesthetics and many other people miss it.
I could be wrong...I was wrong about what's required to develop enterprise apps, but I guess I see it as something (one of my hypothesis) that should guide how I develop software. Because I figure if I do that, it will save me worrying about stuff that doesn't matter (the new shiny slick and snappy), and I can concentrate on what matters (building what they want), and maybe even hack their psychology a bit (make it look like the old style apps they are already familiar with). It's OK if you think differently about it. It's my idea after all, I was just hoping to convince you a bit about it, not to convince myself more through consensus...I don't need that, but because I like the idea that maybe you can benefit from something I figured out, and I can "invite you into the cool club" of people in the know about this secret thing, that nobody else really gets, and we can watch all the other people clamber around with their stupid ideas together and smugly go, "Heh, we know better." But yeah...It's an idea, I haven't tested it extensively (but a few of my current popular projects use slow and clunky, or identically copied from competitors UIs and they are very popular), but I'm comfortable with making my choices just based on my ideas and hypotheses. Maybe I just like the sense that I can see something in this space of developers, that many other people miss, because that lets me feel smarter than most everyone else in that way...maybe that's just compensating for a "lack of real success." But even if so, I need something to keep me going, right? Some sense of motivating self-belief. So those things, even if delusions, are useful. But I don't believe it's a delusion, and I do believe this to be true, and I'm comfortable with that.
I think that's how I think about things, so I hope that makes everything clear. But I appreciate you coming back and being nice about it, not being mean at least. That's a change from how it sometimes goes around here.
I totally agree. I think what happened with us is, as is the case in most of these things, we were talking about orthogonal or parallel things.
I'm not assuming your agreement with my belief that aesthetic, even "brutalist" or "slow and clunky", will connote quality to a certain subset of users, enterprise being one example. I think your might have took it to mean I was saying "haha, therefore I think enterprise users are idiots." Which is not what I meant, but I get how you could see that. I don't think an aesthetic preference, even one which may on the face of it seem maladaptive, means people are idiots. I don't think it's a maladaptive preference, it's a natural thing, and there's reasons for it that work. I suppose it's a form of stereotyping, that allows people to form quick judgments from limited information.
And I'm aware of the research that says that a "good UI" can hide other problems, and be easier to use. So on the face of it, that would seem to say software with "slick and snappy" UX will be more prevalent, or at least be completely wiping the floor with the "slow and clunky" competition. But it's not -- at least not at the high end of the market that I care about. So this is an idea I have about that.
Actually, my criticism, if it was with any group, was with the developers who want the new shiny above all else, and seem to fail to see the practical benefits of practices done by bigcos, even when the success of those products is right in front of them. I think such blindness is stupid. But the developers are not stupid.
My back story is I, even when I wasn't someone who valued new and shiny above all else, once thought, "all I need to do is consumer-productize" enterprise apps and everyone will love them. But that's not all that's required. So I don't underestimate the sales process, I'm just coming at it from the point of view that aesthetics are a component of that decision, albeit an implicit and probably by necessity unspoken one (otherwise: "This UI looks too fancy and the app is too fast. We can't trust these guys, but the old-reliable, clunky and 80s-looking app we've been buying for 20 years just works great for what it is." ~~ but, hey, maybe people really do say that!).
I think you can sell the unfamiliar (product, narrative) using the familiar vehicle (product, narrative, aesthetic). So if you want to do something new, the best way is to serve it to people in a package they already like and are familiar with. I believe that as a general principle. But in this more specific case we're talking about here, I just think I see the importance of aesthetics and many other people miss it.
I could be wrong...I was wrong about what's required to develop enterprise apps, but I guess I see it as something (one of my hypothesis) that should guide how I develop software. Because I figure if I do that, it will save me worrying about stuff that doesn't matter (the new shiny slick and snappy), and I can concentrate on what matters (building what they want), and maybe even hack their psychology a bit (make it look like the old style apps they are already familiar with). It's OK if you think differently about it. It's my idea after all, I was just hoping to convince you a bit about it, not to convince myself more through consensus...I don't need that, but because I like the idea that maybe you can benefit from something I figured out, and I can "invite you into the cool club" of people in the know about this secret thing, that nobody else really gets, and we can watch all the other people clamber around with their stupid ideas together and smugly go, "Heh, we know better." But yeah...It's an idea, I haven't tested it extensively (but a few of my current popular projects use slow and clunky, or identically copied from competitors UIs and they are very popular), but I'm comfortable with making my choices just based on my ideas and hypotheses. Maybe I just like the sense that I can see something in this space of developers, that many other people miss, because that lets me feel smarter than most everyone else in that way...maybe that's just compensating for a "lack of real success." But even if so, I need something to keep me going, right? Some sense of motivating self-belief. So those things, even if delusions, are useful. But I don't believe it's a delusion, and I do believe this to be true, and I'm comfortable with that.
I think that's how I think about things, so I hope that makes everything clear. But I appreciate you coming back and being nice about it, not being mean at least. That's a change from how it sometimes goes around here.
I don’t know if I agree with you, but I think an example of what you’re describing is the TurboTax web UI. You’re shown multiple “loading screens” where things like “We’re looking everything over!” are said to the user. The user is given the impression that some kind of heavy lifting is happening, when that probably isn’t the case. For Intuit, it’s a marketing thing.
I don’t think that is GCP’s problem, though.
I don’t think that is GCP’s problem, though.
TurboTax is a marvel of user experience. Taxes are dreaded, and their app literally psychologically calms you down, deliberately tries to ease you.
Those are people that get what problem they are solving.
Those are people that get what problem they are solving.
Turbotax created the problem they are solving. Filing taxes in other countries is much less stressful and a lot simpler.
This is a joke right? You really think they have someone spending all day writing while loops to slow down page load times?
No, they deprioritize performance, as a feature.
This is definitely not a joke, but yours is, right. There's plenty of ways to end up with slow and clunky without "writing while loops" haha... This is how i really feel it is.
It’s a real pain how slow it is. I’ve resorted to adding quick links to my bookmark bar for GCP products that I use often to get around the slowness.
I was happy with the old BigQuery UI and now they've finally moved it into the Cloud Console monstrosity :(
Google Cloud wanted to "eat its own dogfood", so they originally built the console with Angular v1 and App Engine instead of using more scalable and mature frameworks that would typically be used for those kinds of products within Google.
App Engine didn't support chunked transfer encoding so progressive data loading becomes impossible, and Angular v1 is a pathological performance and maintenance nightmare to the point where AngularJS / Angular v2 ended up being an incompatible rewrite.
The problem is, if you have hundreds of people contributing to a tool with deadlines to meet and lots of UI components you need an incremental approach if there's going to be any hope of replacing the whole architecture. Without an incremental path forward, rearchitecting is dead in the water. Management isn't going to want hundreds of people stop working on new features for months while the whole UI gets written from scratch.
App Engine didn't support chunked transfer encoding so progressive data loading becomes impossible, and Angular v1 is a pathological performance and maintenance nightmare to the point where AngularJS / Angular v2 ended up being an incompatible rewrite.
The problem is, if you have hundreds of people contributing to a tool with deadlines to meet and lots of UI components you need an incremental approach if there's going to be any hope of replacing the whole architecture. Without an incremental path forward, rearchitecting is dead in the water. Management isn't going to want hundreds of people stop working on new features for months while the whole UI gets written from scratch.
If dogfooding is the main reason behind using Angular, it's a bit ironic that <10%? of teams at Google use Google Cloud over Borg.
The Google Cloud team had more incentive than other teams would to be an early adopter in dogfooding their own products, in this case App Engine specifically.
Ending up on Angular was likely a consequence of using app engine: all of the standard google frameworks for writing UIs have a server-side component to help deliver data and scripts to the client, and most of those frameworks would have been difficult or impossible to port to app engine (either because of the chunked transfer encoding limitation, or just the general awkwardness and annoyance of porting a framework maintained by a completely different team from borg to app engine).
The codebase probably started with something that looked like an app engine example app, transferring data and code to the client in the simplest way possible, but not the most performant or scalable way.
Ending up on Angular was likely a consequence of using app engine: all of the standard google frameworks for writing UIs have a server-side component to help deliver data and scripts to the client, and most of those frameworks would have been difficult or impossible to port to app engine (either because of the chunked transfer encoding limitation, or just the general awkwardness and annoyance of porting a framework maintained by a completely different team from borg to app engine).
The codebase probably started with something that looked like an app engine example app, transferring data and code to the client in the simplest way possible, but not the most performant or scalable way.
One thing that I've started doing for my own personal projects is deliberately working on underpowered hardware. I got a Rasberry PI 400 and that seems to be the perfect dev environment for me. It also has the side effect of making me much more conscious of the technology and dependencies that I use to create a product with.
I use my own beefy server for creating builds and have a decent dev-build-test setup for myself where the dev experience is still pretty fast despite the hardware I'm using as a client - but when it comes to actually testing out my work I love using it on the PI because I know that most users will have an experience very similar to what I get on the PI.
I use my own beefy server for creating builds and have a decent dev-build-test setup for myself where the dev experience is still pretty fast despite the hardware I'm using as a client - but when it comes to actually testing out my work I love using it on the PI because I know that most users will have an experience very similar to what I get on the PI.
Knowing that the target audience for this is developers (for the most part), the decision to make it a javascript application in the first place instead of rendering from the server seems like overkill, at least IMO.
Maybe it's just me, but I don't really care about fewer page reloads or having multiple animations and interactivity. I understand why those can have an impact on end users and so I do think that SPAs have their place, but I'd much rather the interface was rendered from the server and worked through links if it means it'll work faster. In fact, half the time I'm not even using the web interface; I'm using the SDKs.
Maybe it's just me, but I don't really care about fewer page reloads or having multiple animations and interactivity. I understand why those can have an impact on end users and so I do think that SPAs have their place, but I'd much rather the interface was rendered from the server and worked through links if it means it'll work faster. In fact, half the time I'm not even using the web interface; I'm using the SDKs.
SSR wouldn't mean it'd be faster because it could have still been coded like spaghetti.
You sound reasonable and I'm not directing this to you in particular, but there is a clear bias on HN that SPA sites are inherently slower or less performant, which is not true at all. Either can be fast or slow.
The debate around SPA and SSR is so heated and centered on the front-end bit that people forget that UX performance depends a lot on the server. Websites are client-server systems regardless of the front-end architecture.
I'd wager that the case of GCP is no different and that the perceived slow UIs are caused by problems all across the stack.
You sound reasonable and I'm not directing this to you in particular, but there is a clear bias on HN that SPA sites are inherently slower or less performant, which is not true at all. Either can be fast or slow.
The debate around SPA and SSR is so heated and centered on the front-end bit that people forget that UX performance depends a lot on the server. Websites are client-server systems regardless of the front-end architecture.
I'd wager that the case of GCP is no different and that the perceived slow UIs are caused by problems all across the stack.
In Google play developer console there is simple table with list of apps and installs count. The cells are 34 levels deep in the DOM. Insane.
Blame the new hipster driven development with Javascript where it's ok to shove down a 100s of mb worth of assets into your user's browser whether they consent to it or not, all because you can load some fancy animations and write a blog post on your cool new JS stack.
An average react JS app built using create react app actually costs you in megabytes, not kilobytes, which has somehow become the new normal.
But hey, I'm not complaining. I make money turning these slow sites fast by bringing them down to a 50-100kb total. Not complaining!
An average react JS app built using create react app actually costs you in megabytes, not kilobytes, which has somehow become the new normal.
But hey, I'm not complaining. I make money turning these slow sites fast by bringing them down to a 50-100kb total. Not complaining!
I’ll just say as a meta comment that this thread is some of the most beginning-to-end Google frontend development ingenuity and organizational imperatives bashing I’ve ever read here.
There’s not a single poster here that didn’t throw a rock.
In defense of large orgs, faangs and non faangs, from my experience I can tell you that some talented developers on teams will notice exactly what is wrong with a product (frontend or backend). They might know parts of the UI need to be trimmed and made performant, api calls need to be restructured to be made performant, and so on, but don’t speak up.
There’s a variety of reasons here and it mostly has to do with the old adage ‘no good deed goes unpunished’. On teams there are egos, and you will bring out unwanted peer pushback (who do you think you are with your fancy ideas all the time, you don’t think the rest of us thought of this too?) when you take up some of these mantles. This is a dynamic that is coupled with general management issues that come from the product/project management, where your great idea might not be seen as worthwhile. On a team, socially and professionally, it’s better to not rock the boat here because the reward is not fair, and if it were outsized, it could be taken bad by coworkers as grandstanding.
Why bother? Which leads to the manifestation of the phenomenon: death-by-a-thousand-cuts. This is where professionally team members look like people with a self absorbed agenda. Now no one ever takes up reducing the bleeding, and finally, a world class company, with world class talent, builds laughably bad end results.
The only solution to this is for the egos to restructure the direction of their energy into a monomaniacal focus on ‘the final product is all there is’, where a good idea is a good idea. The ego has to be abstracted into the final output, where everyone involved derives their self worth from how good the thing they shipped is, and nothing else matters.
There’s not a single poster here that didn’t throw a rock.
In defense of large orgs, faangs and non faangs, from my experience I can tell you that some talented developers on teams will notice exactly what is wrong with a product (frontend or backend). They might know parts of the UI need to be trimmed and made performant, api calls need to be restructured to be made performant, and so on, but don’t speak up.
There’s a variety of reasons here and it mostly has to do with the old adage ‘no good deed goes unpunished’. On teams there are egos, and you will bring out unwanted peer pushback (who do you think you are with your fancy ideas all the time, you don’t think the rest of us thought of this too?) when you take up some of these mantles. This is a dynamic that is coupled with general management issues that come from the product/project management, where your great idea might not be seen as worthwhile. On a team, socially and professionally, it’s better to not rock the boat here because the reward is not fair, and if it were outsized, it could be taken bad by coworkers as grandstanding.
Why bother? Which leads to the manifestation of the phenomenon: death-by-a-thousand-cuts. This is where professionally team members look like people with a self absorbed agenda. Now no one ever takes up reducing the bleeding, and finally, a world class company, with world class talent, builds laughably bad end results.
The only solution to this is for the egos to restructure the direction of their energy into a monomaniacal focus on ‘the final product is all there is’, where a good idea is a good idea. The ego has to be abstracted into the final output, where everyone involved derives their self worth from how good the thing they shipped is, and nothing else matters.
Maybe they tapped the same developers who built the Google Ads web app, a UI so slow they have time to display tutorials while everything loads.
This is a hard problem for any sufficiently large application...web or otherwise. Solving it, in my experience, requires a strongly supported central body focused on managing code quality across teams. I know this is a relatively straightforward exercise with large React apps. I've never seen it done with Angular to know how difficult that is. Doing this all comes with a cost of maintaining that team and possibly slower development, of course.
However, I assert that no cloud provider has won or lost significant cloud deals based on the speed of their UI, and most engineers who live in the cloud do so through CLI tools. While people may not like it, and perhaps it's caused some engineers to do something different for personal projects, this is rightly not a KPI for Google Cloud, hence the state of of the cloud console.
However, I assert that no cloud provider has won or lost significant cloud deals based on the speed of their UI, and most engineers who live in the cloud do so through CLI tools. While people may not like it, and perhaps it's caused some engineers to do something different for personal projects, this is rightly not a KPI for Google Cloud, hence the state of of the cloud console.
Playing the devil’s advocate here, I think it‘s just very hard to build a dashboard for this scale of resources, services and users that‘s all of very (!) secure, flexible (as in terms of policies) as well as fast.
Having had to use the Microsoft Admin dashboard for creating five new PowerBI users (which took me the better part of an hour), going back to Google‘s Cloud Console felt like a godsend of UX, Comfort, Sensibility and Speed.
Having had to use the Microsoft Admin dashboard for creating five new PowerBI users (which took me the better part of an hour), going back to Google‘s Cloud Console felt like a godsend of UX, Comfort, Sensibility and Speed.
When you start implementing a second loading spinner. That's the time to stop and think about what you're doing. Surely.
[deleted]
And of course, Google gives demerit points to websites that load slowly. (Or whatever they are called)
This isn't really a public page, though. Their landing page loads really quickly.
https://cloud.google.com/
https://cloud.google.com/
I think the big-picture answer is that they held a "Latency Code Yellow" back in ca. 2007, and apparently stopped inculcating the same latency-sensitivity in people hired since that finished a year or so later.
Can a googler chime in to explain why Gmail is so slow at loading even on the most robust PCs with high speed internet?
Try this one: https://mail.google.com/mail/u/0/h/77z33rvyv1lz
It's HTML version of gmail and it loads instantly.
It's so fast! Blink and it's fully loaded! Also kind of looks better too. But that's subjective, I guess.
Because you are supposed to load it once and keep it forever. Loading a web app is like installing a software program.
What about web apps like https://sr.ht which are fully loaded and usable from a cold visit in under half a second with only 2 network requests?
Yikes, didn't realize they had the indecency to drink their own kool-aid. Angular, really? No wonder! Come to think of it, it's maybe been around a year since I last saw one of those tell-tale "page finishes loading to a blank page for 20 seconds before finally rendering" Angular sites
This comment is ignorance at it's finest.
The way my machine fan fires up when I use it I just assumed I was mining bitcoins to help offset my bill.
I used to work on Google Cloud UI. Short answer is: Google Cloud org is very unlike Google. It's more like IBM or Oracle. A lot of managers and engineers are from those companies.
I spent a couple years on a 5/2 mbps connection and GCP console was always the slowest thing to load out. 15MB of JS is crazy.
Perfect counterexample for the person who was telling me that single-threaded performance isn't visible to users any more. On the M1 mac mini the Google Cloud console is fully loaded in 5.1s (2.6s when cached), not 8.1s. As an enthusiast of software efficiency I don't think either of these is great, and there's obviously a lot they can do to make it faster, but it just shows how users still greatly benefit from throwing hardware at the problem.
I guess stuff like amp is good only to preach others. This garbage has been slow for ages. Also they keep throwing links to new stuff in their side bar without any rhyme or rhythm making navigation as annoying as possible.
That’s kind of the woah factor here. Talk about glass houses.
In Firefox, https://console.cloud.google.com/compute/instances never loads.
Meanwhile AWS uses google’s GWT to great effect
AWS console is by far the slowest thing on my machine, web based or not.
I don’t use GCP or many other Google products though. I’m kind of shocked google managed to ship a framework slower than GWT. I always assumed anyone that used it for a few seconds would say “well, that was a fundamentally bad idea”, and not double down on whatever the heck Google was thinking.
I don’t use GCP or many other Google products though. I’m kind of shocked google managed to ship a framework slower than GWT. I always assumed anyone that used it for a few seconds would say “well, that was a fundamentally bad idea”, and not double down on whatever the heck Google was thinking.
[deleted]
Some older services do. It isn’t the framework used by new services for their consoles.
Isn't GWT maintained by JetBrains these days?
Seems to be maintained by Google
https://gwt.googlesource.com/gwt/
https://gwt.googlesource.com/gwt/
And I thought GWT would be dead.
Any source of this info?
Atlassian Jira is dog slow too. Drives me nuts.
Atlassian is one of those places that I just can't believe has gotten so widely used. Every single thing I've used that is an Atlassian product drives me nuts. I really don't understand how anyone at any point looked at Jira or Confluence or anything Atlassian puts out and said "yep, this is the best version of this thing I've seen, sign me up". I've been using JIRA for years now, and it never gets any easier or better. I can never find what I want, I can never remember how to do things. I have to assume it's just me since everyone uses these things though.
As far as I understand it, it's because Jira is not made for developers. It's made for SCRUM and Project Managers that need fancy graphs and lots and lots of fields and processes. It's their reason for existence, so they have every incentive to make it so that developers do not understand.
That'd make complete sense. None of their products support Markdown really well. Each has its own weird way of handling code snippets. So many other tools support three backticks and boom, you're in a code-block.
Doing a small startup I forget about this nonsense sometimes. I could make more at a big company but when I read this I am glad to be doing what I am doing.
Because UI snappiness is not the only thing that matters.
One example: Jira integrates with _everything_. It really matters that you can create tickets from Slack, send email to the management when epics progress, see Github pull requests linked to tickets, and so on.
One example: Jira integrates with _everything_. It really matters that you can create tickets from Slack, send email to the management when epics progress, see Github pull requests linked to tickets, and so on.
One reason is usually the person that decides for the company to use it never actually touches it.
JIRA is used because it's been around a long time and until recently the competition was even worse. It's also gotten slower over time in my experience.
We're using self-hosted Jira and it's fast enough. From what I gather the cloud version is what's dog slow?
We'll likely find something else once the self-hosted version expires in a couple of years, unless the cloud version gets up to speed.
We'll likely find something else once the self-hosted version expires in a couple of years, unless the cloud version gets up to speed.
I guess I am older but pre jira things were so much worse that yeah... best version of this thing I’ve seen. Not that I love it but it’s functional and not an Oracle form or some ugly crud tool cookie cut for a process different than my teams.
Because 10-years ago Atlassian products were a huge breathe of fresh air. Everything else was so much worse.
Come to think of it, that's how Google became so popular too.
Come to think of it, that's how Google became so popular too.
You’re probably using it wrong. Click your mouse on a non-interactive UI component and press “.”
Now you can find everything you want. You’re welcome.
I agree jira is terrible. Other bug trackers I’ve used are somehow worse. Does anyone have anything they can recommend with a straight face? (Github issues are missing too many features for me. Jira’s sql-style language is just too useful.)
Now you can find everything you want. You’re welcome.
I agree jira is terrible. Other bug trackers I’ve used are somehow worse. Does anyone have anything they can recommend with a straight face? (Github issues are missing too many features for me. Jira’s sql-style language is just too useful.)
I'm a jira power-user and your answer highlights my two main problems with it.
> Click your mouse on a non-interactive UI component
80% of the UI is interactive, but not marked as such. Have fun finding a 10px strip that won't turn into an edit workflow when clicked!
> Click your mouse on a non-interactive UI component and press “.”
Even using the keybindings (seriously everyone, hit "?" and look through them) events are lost. Want to create a subtask? It's not `.sub<enter>`, it's actually `.sub^H^Hsub^H^H^Hsub<enter><wait><tab><tab><give up and use mouse to focus a field, because it arbitrarily unfocuses fields>Title Of My Task<use mouse to find the submit button>`
They've done so much work to make it a quick UX but it's all for nothing when it randomly eats keystrokes and defocuses constantly. Maybe some of our add-ons are at fault, I'm interested in hearing if there are jira installs that aren't like mine.
> Click your mouse on a non-interactive UI component
80% of the UI is interactive, but not marked as such. Have fun finding a 10px strip that won't turn into an edit workflow when clicked!
> Click your mouse on a non-interactive UI component and press “.”
Even using the keybindings (seriously everyone, hit "?" and look through them) events are lost. Want to create a subtask? It's not `.sub<enter>`, it's actually `.sub^H^Hsub^H^H^Hsub<enter><wait><tab><tab><give up and use mouse to focus a field, because it arbitrarily unfocuses fields>Title Of My Task<use mouse to find the submit button>`
They've done so much work to make it a quick UX but it's all for nothing when it randomly eats keystrokes and defocuses constantly. Maybe some of our add-ons are at fault, I'm interested in hearing if there are jira installs that aren't like mine.
What's a better alternative to Jira? I've tried Trello and Asana. Trello is nice for personal stuff and small projects but it doesn't work well for bigger projects and teams. Asana has an infuriatingly unintuitive interface but that might just be my personal preference.
http://linear.app and https://clubhouse.io -- I chose Clubhouse for our team a few years ago but Linear is new and is extremely well-made.
I agree completely. Bitbucket is OK, but everything else is so painful, and the Bitbucket alternatives are better than it anyways.
It's one of those products that is "sold" not "bought".
It is not just you. It’s shocking.
youtube is the same slowwwwwwwwwwwwwwww loading experience, it really shows when you try to use it on an underpowered chromebook.
It's strange to me that google devs don't dogfood their own google branded products! They just assume everyone is using the same dev workstation they are?
It's strange to me that google devs don't dogfood their own google branded products! They just assume everyone is using the same dev workstation they are?
I continue to advocate for hard download limits on the browser side that can only be overridden by scary user prompts. The defaults can be slightly larger for pages classified as “apps”, or certain file formats (e.g. when a link’s purpose is to download an entire app) but generally pages should be constrained to sizes on the order of kilobytes.
As long as the floodgates can simply stay open and pages can download whatever they want, coders will remain lazy. This isn’t surprising at all.
As long as the floodgates can simply stay open and pages can download whatever they want, coders will remain lazy. This isn’t surprising at all.
>JavaScript 15.7 MB
Some time ago Google moved away from rendering pages server side. Youtube right now downloads 1MB of mostly json packed data for client side rendering. Irony of this is old Youtube layout (pre Polymer, their client side YT rendering engine) downloaded ~30KB of pre rendered html. The difference to users is Youtube website visibly slowly appearing in front of your eyes (while one CPU core is pegged at 100%) instead of Old YT just loading instantly and working.
Some time ago Google moved away from rendering pages server side. Youtube right now downloads 1MB of mostly json packed data for client side rendering. Irony of this is old Youtube layout (pre Polymer, their client side YT rendering engine) downloaded ~30KB of pre rendered html. The difference to users is Youtube website visibly slowly appearing in front of your eyes (while one CPU core is pegged at 100%) instead of Old YT just loading instantly and working.
The gcloud command line is also abysmally slow.
The memory usage of the webpage often exceeds 1GiB.
But otherwise the platform is good. So I suffer through.
But I agree it’s annoying.
The memory usage of the webpage often exceeds 1GiB.
But otherwise the platform is good. So I suffer through.
But I agree it’s annoying.
The AWS console isn't fast either (just shy of 1 MB of data transferred). I chalk it up to -
1. So many services all living in the same place with a variety of UI components 2. The complexity of turning all the knobs and dials of building infrastructure (or multiple pieces) into a UI. 3. Being an ancillary service (admin UI).
1. So many services all living in the same place with a variety of UI components 2. The complexity of turning all the knobs and dials of building infrastructure (or multiple pieces) into a UI. 3. Being an ancillary service (admin UI).
Might not be great but AWS Console has been evolving and it's far superior than GCP Console. It baffles me when some people here in HN say that GCP's UX is better than AWS's? Like how?
I use both extensively and have a way harder time to figure out what the heck is going on when using Google Cloud Console.
I use both extensively and have a way harder time to figure out what the heck is going on when using Google Cloud Console.
Every Google SPA is slow. It’s compounded by poor animations that are all a little too long, and Material UI.
There's something poetic about using Google's own tools to demonstrate why their own frontend code is slow. Maybe the author can suggest they use Lighthouse CI next to track which commits improve/degrade UX (but I'm guessing that's a competing product with their own).
I can only imagine how many battery cycles I've lost to the BigQuery web console, especially the jobs detail views. Safari tends to be pretty great with battery life, but it's no match for that thing.
Personally, the Google Cloud Console UI is an engineering marvel. The amount of complexity is, to my imagination, mind-boggling. That is just works most of the time is amazing. Complex workflows that other require you to visit 10 pages to complete a thing is seamlessly executed for you with sidebar UIs, etc.
I'm sure the performance bit of it would catch up soon. But who is using it anyway, and surely these people have pretty good internet. Not vindicating, but I'm sure the optimization will come later.
I'm sure the performance bit of it would catch up soon. But who is using it anyway, and surely these people have pretty good internet. Not vindicating, but I'm sure the optimization will come later.
Probably the same reason why the gmail web interface is so slow too.
Is it slower than the AWS console? We use both and my subjective sense is that it isn't, but I regularly visit just a couple of specific sections in the AWS console whereas we use the Google console for a lot of things daily. I'm sure front end engineers could find a lot to complain about in the GCP console's design and implementation, but the tl;dr for me is that it works and it's fast enough for the things I need to do. In areas where the console is limiting I am probably working off the CLI anyway (daily operations within our k8s clusters for example).
Probably worth noting as well that for both consoles the underlying APIs are broad, complex, and evolving at a dizzying pace. I can only imagine the technical and organizational challenges around keeping these consoles up to date and improving them where possible.
Probably worth noting as well that for both consoles the underlying APIs are broad, complex, and evolving at a dizzying pace. I can only imagine the technical and organizational challenges around keeping these consoles up to date and improving them where possible.
I use AWS and GCP regularly and Azure sometimes as well. GCP is too damn slow by comparison not that others too would win any industry awards for speed but they are usable. On GCP however, the GKE screens are damn slow with spinner spinning for so long that I started to doubt my internet connection.
UI of a IaaS (or PaaS) certainly is a complex matter and I guess few iterations down the road, GCP might perform better. May be load lazy load the UI functionality (JS) on demand or something.
UI of a IaaS (or PaaS) certainly is a complex matter and I guess few iterations down the road, GCP might perform better. May be load lazy load the UI functionality (JS) on demand or something.
I was shocked the first time I tried Digital Ocean K8S. They are just serving the default K8s Web UI (or looks like it). It was just... so fast!
At this point I mostly use Vimium omni search to use the history to get exactly where I want to go and a simple script that opens my browser in the same context and namespace that kubectl is using. (e.g.: show all deployments, show a specific deployment, pod, logs, etc.).
At this point I mostly use Vimium omni search to use the history to get exactly where I want to go and a simple script that opens my browser in the same context and namespace that kubectl is using. (e.g.: show all deployments, show a specific deployment, pod, logs, etc.).
> The initial HTML request is very fast and only takes about 150ms.
Umm, Houston, we have a problem. That's way way way too long for a first page load of HTML only. It should be 30 ms.
Umm, Houston, we have a problem. That's way way way too long for a first page load of HTML only. It should be 30 ms.
Maybe its time to move from webapps back to desktop apps? Angular, React etc. all this JavaScript seems to slow everything down.
Everything in tech is so cyclical.
Everything in tech is so cyclical.
I usually work with React and you can make webapps fly. If you even try a bit you can double load speed fairly easily, and if you are willing to put effort you can reach an orders of magnitude of improvements in webpage load speeds.
Google controls the chrome browser, angularjs and google cloud UI. With the smartest engineers, we still see a shitty user experience.
Just goes to say hiring engineers doesn’t solve problems. Focusing relentlessly on user experience, having performance and reliability as an org goal gets things done.
As you add more people, each of them has less autonomy on the customer experience.
Just goes to say hiring engineers doesn’t solve problems. Focusing relentlessly on user experience, having performance and reliability as an org goal gets things done.
As you add more people, each of them has less autonomy on the customer experience.
Hey, at least you can easily find what you want in GCP. In AWS, you're left with Googling anything you want to do.
I keep waiting for some company to remember how fast desktop apps are and wake us all from our collective webapp delusion. I imagine native Swift on MacOS and C# on Windows desktop GUI frontends for Google Cloud wouldn't be hard to build or maintain. How often does Google Cloud change their webapp's UI?
I've come to the conclusion it's their way of telling me to use the API or the CLI. As in, why am I throwing all these meabytes of the line just to perform a single command that could be done with the API as well. If only their API wasn't as slow as well.
[deleted]
I originally didn't like AWS's console because it wasn't "consistent", but when I opened up GCP's console the first time, I immediately preferred AWS. Fast and usable is better than inconsistent.
I can find my way easier in Google Cloud than in AWS. The services are also more polished and seem more mature compared to AWS. I'm about to give Google Colab Pro a try because the free version has been deteriorating.
GCP's UI controls for adding/removing instances from instance groups is appalling. It's unbelievably slow and can even lie to you (i.e. telling you an instance has been removed when it actually hasn't).
Reminds me of the MS azure page taking 17 seconds to load: http://forwardscattering.org/post/41
Because more js and less html is always better. Also rendering html on server is very expensive for backend apps
Also if your company has many js and backend libraries, you need to use them, at least on one place
Also if your company has many js and backend libraries, you need to use them, at least on one place
> We can see that each page loads over 15 MB of JavaScript code.
It’s rumored that the compute Google sells is actually performed by that JavaScript code, running in customers browsers. :P
It’s rumored that the compute Google sells is actually performed by that JavaScript code, running in customers browsers. :P
Actually, looking at this I'm surprised that the mainstream browsers are still caching javascript, but not some pre-parsed/compiled version of the code.
It'd be glorious if there were a protocol to ship something closer to "machine code" from server directly to browser, but it doesn't exist. JS is the only language one can assume the browser can actually interpret.
An interesting proposal:
https://blog.cloudflare.com/binary-ast/
https://tc39.es/proposal-binary-ast/
https://blog.cloudflare.com/binary-ast/
https://tc39.es/proposal-binary-ast/
I wonder how many real-world pieces need to fall into place for WASM to become a realistically viable option.
Obviously browser support is one fairly big component. (I've long wondered how much of Chrome's ~65% is straight-from-dl.google.com evergreen, but I guess that's just commentary).
Then there's tooling... heh. That'll be its own eternal September just like JS has been I guess.
Obviously browser support is one fairly big component. (I've long wondered how much of Chrome's ~65% is straight-from-dl.google.com evergreen, but I guess that's just commentary).
Then there's tooling... heh. That'll be its own eternal September just like JS has been I guess.
They do, well at least Chrome does: https://blog.chromium.org/2015/03/new-javascript-techniques-...
> Chrome 42 introduces an advanced technique of storing a local copy of the compiled code, so that when the user returns to the page the downloading, parsing, and compiling steps can all be skipped.
Not sure what's going on in Google Cloud UI, though. It's a dumpster fire.
> Chrome 42 introduces an advanced technique of storing a local copy of the compiled code, so that when the user returns to the page the downloading, parsing, and compiling steps can all be skipped.
Not sure what's going on in Google Cloud UI, though. It's a dumpster fire.
Why would anyone think that hypertext browser and typesetting tools would be a good platform for modern, fast and rich UI apps?
20% of OPs analysis could be solved by tree shaking, something we've had in webpack and its competitors for some time now.
Ah yes, Angular.
Please explain? Or is this just a random useless ignorant comment?
You know a framework is bad when you just mention it's name and people assume it's an insult.
I'm surprised no one has mentioned the new AdWords UI yet, the load times are agonizingly painful.
Is there something Angular can do to help improve the performance before creating the page?
Angular has tons of things you can do to have great performance. I'm guessing the Google Cloud team just aren't prioritizing performance over features.
The reactivity detection mechanism of angular is not tree scoped like in Vue, it is global and therefore much more inefficient
The slow UI is one (of many) reasons why I moved away from Google Cloud Monitoring.
[deleted]
because it's the web, and thus loading everything every time, instead of a desktop application.
I think its fine at enterprise scale... has anyone experienced AWS console at enterprise scale? in 2015-17 it was awful.
That's what happens when you employ over-enthusiastic developers obsessed with their Javascript-framework-legacy. Things worked fast when HTML was the UI, and the logic was in the server.
I worked on a server rendered project in the 00s. There was a screen that took 7 minutes to render for about 100 list items.
You can make anything slow if you really try.
You can make anything slow if you really try.
Correction: you can many anything slow if you don't try.
[deleted]
Facebook also makes heavy use of frontend frameworks but all their stuff is fast because they are competent at it.
I just measured an uncached page load of facebook.com and it takes 3.5s which isn't stellar.
It doesn't really matter how fast an uncached page load is for Facebook. Why would they optimize it? A user will only see that a few times a decade when they get a new computer. It would be like trying to shave seconds off of a native app install time.
For Google, it's better when it's my CPU doing the work, than theirs.
just goes to show that working at google is overrated.
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!
And yet, that's the best they can do. It's just that hard and impossible to get it right. Sorry guys!
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.
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.
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.
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.
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.
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.
Now do it in Teams. You can share your screen without completing a voicecall.
[deleted]
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.
>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.
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.
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!
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'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.
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.
- 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.
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.
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.
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.
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
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.
[deleted]
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.
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.
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.
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.
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.
Probably the best they want to do because they do not want to allocate more resources to it.
They are optimising for something other than performance. E.g. ease of maintenance, or ease of scaling
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.
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 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.
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.
I think the UI is probably not a high priority on their side and they assign most of the work to juniors and outsourced.
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?
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.
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.
> 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.
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.
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.
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..
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.
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.
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.
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.
Attach a monetary concern directly to the performance and there will be improvements overnight. Otherwise this is the "best" we get, given the circumstances.
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.
"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."
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.
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 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?
I am on mobile; what are the Lighthouse scores for Google's own products?
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.
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.
[deleted]
I haven't used GCP for a long time. I regularly use AWS though. I also find AWS UI to be very slow. It always surprises me why.
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 logic is a direct consequence of this, as those components are ending up in the codebase as a side-effect of different segments of code, worked on by different teams, probably in different offices, "reusing" the same component---but not really, since they might be skewed on the version they're depending on. It's DLL hell in Javascript client form, basically.
And the product as a whole is chasing feature parity, not speed of UI.
The simplest way to not end up like Google Cloud UI is to not try to build a whole-product cloud solution. The second simplest way, if you're Amazon and you've already gone that road, is to have different sub-parts of your mega-architecture be different "apps" (really, different websites), each of which need pull in only the pieces it cares about, and be willing to take a whole-page refresh when the user transitions from one page to another.