Why is the Google Cloud UI so slow?
debugbear.com
debugbear.com
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.
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 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)
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.
Google does have a problem with management and the org-chart, but not the way you think.
But their focus is on spanning the feature-set, not making the resulting UI fast. And the feature set is incredibly broad.
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 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.
But they're far more focused on spanning feature set than the speed of the result.
This should be the default! What a world we live in.
Let my browser manage my workspace, please don't make a window manager inside my browser window.
[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 share your annoyance at all websites who don't allow for this though.
This is basically the definition of Conway's Law.
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?
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.
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
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.
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.
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.
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.
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.
It's really hard to wrangle the amount of feature growth cloud is experiencing and I expect they made tradeoffs to satisfy that first.
"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!"
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.
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
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.
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.
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.)
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 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.
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.
To me, it looks like a work of incompetent developers led by incompetent technical managers upon requirements of clueless and ignorant product managers.
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, ...).
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.
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..."
"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"
I guess it might speak to a solid, if somewhat slow, API.
https://www.hashicorp.com/resources/google-provider-new-terr...
It indicates that speed is not a priority for management.
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
B2 large business is different than b2c or b2 small business
It's all about who is making the decisions
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.
By now, it's too late to rewrite the whole thing from scratch, hence a new OS https://en.wikipedia.org/wiki/Google_Fuchsia
Microsoft did nail windows phone apis, 10 freaking years ago, too bad it didn't survive.
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.
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.
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...
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.
Give me a cluttered UI that has everything available any day.
The situation with primevideo.com is strange, but it seems to have something to do with non-US territories?
* 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.
Back and forward work great on GitHub. My mouse has additional buttons for these.
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.
* 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.
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...
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
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
which web frontend is good ? (except HN)
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.
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".
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...
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.
Googlers have been WFH since March on laptops and residential Internet & WiFi.
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 new one had a bunch of useless white space and the app has a loading bar!
Wtf?!
Boggles the mind how Google web apps have performance issues like this.
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 thought it was a broken page at first.
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.
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.
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.
They did the same thing for GC UI. They think it tricks the user into thinking it's fast, instead of making it fast.
Google made a superior replacement to the current gmail experience and then just threw it away like it never existed.
I enabled that a while back which makes navigating emails much more pleasant
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.
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.
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.
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
Good strategy to steal market share.
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).
What? Why are they not standard WebExtensions?
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
I left using chrome 3 years ago and I haven’t really missed out and I honestly love firefox
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 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 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.
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.
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.
(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?)
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.
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.
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.
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.
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 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 think that is GCP’s problem, though.
Those are people that get what problem they are solving.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
Come to think of it, that's how Google became so popular too.
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.)
> 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.
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?
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.
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 memory usage of the webpage often exceeds 1GiB.
But otherwise the platform is good. So I suffer through.
But I agree it’s annoying.
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).
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'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 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.
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.
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.).
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.
Everything in tech is so cyclical.
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.
Also if your company has many js and backend libraries, you need to use them, at least on one place
It’s rumored that the compute Google sells is actually performed by that JavaScript code, running in customers browsers. :P
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.
> 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.
You can make anything slow if you really try.
And yet, that's the best they can do. It's just that hard and impossible to get it right. Sorry guys!
There are companies with higher (arguably actually acceptable) quality standards, but they're few and far between.
Without seeing them do better there's no way to actually know that. You're assuming they're capable, but you could be wrong.
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.
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.
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.
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.
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!
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 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.
- 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.
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.
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.
Consumers can more easily make that choice since they're not part of a hierarchy.
The people making the decision aren‘t not often the ones who need to work with the product.
Also the AWS web ui has a lot of the same problems, so switching vendors wouldn't just fix the problem
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.
Try scrolling up in Teams. I'll wait.
Now do it in Slack - 10 times quicker, and thus usable.
I have to use both Slack and the Google Cloud UI at work. RIP.
Now do it in Teams. You can share your screen without completing a voicecall.
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 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.
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?
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.
> 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.
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.
It's not a priority with many of Google's current apps.
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.
Attach a monetary concern directly to the performance and there will be improvements overnight. Otherwise this is the "best" we get, given the circumstances.
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."
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 am on mobile; what are the Lighthouse scores for Google's own products?
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.