AWS open sourced the AWS console design system(github.com)
github.com
AWS open sourced the AWS console design system
https://github.com/cloudscape-design/components
96 comments
I was working to solve this exact same problem while I was at AWS on the design team from 2012 to 2014. I had spent the previous two years working on the SDK team (2010-2012). I’m a software engineer, who got his start in user experience, so I was able to work on the visual and interaction design with the designers, and then turn around and write the code for it as CSS classes, JavaScript, and components. It was called Plutonium.
Myself and my manager were constantly at odds with the Director in that area of AWS. He had no respect for designers or design, and kept pushing GWT, because he didn’t think web developers even needed to be working at AWS in the first place. We were actively and regularly working with the core Console team, as well as individual engineering teams who were building their specific sub-consoles (EC2, SQS, etc.).
I left in 2014. My manager left in 2015. Even though this doesn’t appear to be a direct extension of our work, this is absolutely a spiritual successor to the project we kick started all those years ago. Congratulations to the people at AWS who continued the good fight, and did what was best for customers against the whims of middle-management.
Myself and my manager were constantly at odds with the Director in that area of AWS. He had no respect for designers or design, and kept pushing GWT, because he didn’t think web developers even needed to be working at AWS in the first place. We were actively and regularly working with the core Console team, as well as individual engineering teams who were building their specific sub-consoles (EC2, SQS, etc.).
I left in 2014. My manager left in 2015. Even though this doesn’t appear to be a direct extension of our work, this is absolutely a spiritual successor to the project we kick started all those years ago. Congratulations to the people at AWS who continued the good fight, and did what was best for customers against the whims of middle-management.
Is this a step towards making AWS console plug-ins? That would be really handy.
Why is react so popular? It’s just covering a small part of the stack and doesn’t bring much to the table? There were so many other solutions before and so many other solutions now. Are people attracted by the name Zuckerberg? Srsly I don’t get the react hype. Didn’t get it 7 years ago. Don’t get it now…
Zuckerberg had nothing to do with the development of React other than being the CEO of the company that developed it. Jordan Walke created React. React was revolutionary in the day of Dojo and Angular 1 complexity and jQuery spaghetti. It was a small library that let you build declarative UIs. It was simpler and easier to use than most anything at the time. It also brought along with it the virtual dom, which at the time was the fastest way to render an app of any sort of complexity. At the time IE6 was the dominate browser, enterprise or otherwise, and Chrome and Firefox were still the new kids on the block. IE6 did not have JIT compilation and still ran Javascript in purely interpretive mode, so simply by using React made your app 2x as fast.
The complexity, the feature sets, and the move more towards FP-land came later. There is still a pretty straightfoward path to using React rather simply as your UI library.
If you don't get why it became so popular, it just means you haven't had to use much JavaScript to develop apps for at least a decade.
The complexity, the feature sets, and the move more towards FP-land came later. There is still a pretty straightfoward path to using React rather simply as your UI library.
If you don't get why it became so popular, it just means you haven't had to use much JavaScript to develop apps for at least a decade.
It is interesting that you automatically assume that I didn't have many touchpoints with JS just because I don't get the hype.
Actually quite the opposite is the case. I was happily writing loads of vanillajs, tons of Angular(1) and wrote several years codebases in emberjs. Besides that I worked with Vue and yes also React once.
React brought nothing to the table that was helping me ship faster and make less unimportant decisions. Back when I had to touch react every week there was a new flavour how to handle routing, state, validate forms and sync to the backend. Ember and Angular had a good default there and were not harder to use.
(Nowadays I tend to stay away from fat js frameworks but mainly because I went indie dev and need to be resource efficient building full stack apps with Rails. But that is a different story. And yes I worked with Go, Python, Java and C# in the backend too.)
Actually quite the opposite is the case. I was happily writing loads of vanillajs, tons of Angular(1) and wrote several years codebases in emberjs. Besides that I worked with Vue and yes also React once.
React brought nothing to the table that was helping me ship faster and make less unimportant decisions. Back when I had to touch react every week there was a new flavour how to handle routing, state, validate forms and sync to the backend. Ember and Angular had a good default there and were not harder to use.
(Nowadays I tend to stay away from fat js frameworks but mainly because I went indie dev and need to be resource efficient building full stack apps with Rails. But that is a different story. And yes I worked with Go, Python, Java and C# in the backend too.)
Well I only made that assumption because you seem to have assumed people use React because of Mark Zuckerburg, apologies there.
In either case, kudos to you for actually enjoying the early days of using Ember 1 and Angular 1. I only look back on those days in horror.
In either case, kudos to you for actually enjoying the early days of using Ember 1 and Angular 1. I only look back on those days in horror.
It also introduced syntax that did modular components and made more sense compared to Angular 1.
Of all design systems I'd be curious about, the AWS console may be the last one I'd choose to mimic/leverage.
I liked the AWS console so much better when it looked like it was made in jQuery (not sure if it was). It was more information-dense and so much more performant. Now it looks and works pretty badly.
Still leagues better than Azure, which causes brain damage.
Still leagues better than Azure, which causes brain damage.
It’s not better but more consistent than GCP cloud console.
If you're building a platform, have a design system and the platform ends up inconsistent, you're doing something wrong. Consistency is the entire point of design systems.
Don't you mean the Firebase cloud console? It is Sunday, after all.
That was my wonder - AWS has a system to it's design?
What are some of your favorite design systems?
As someone who is very critical of it internally, for all its a faults it’s very consistent and easy to use if you’re React focused.
As a user of the AWS, consistent is not a term I would use to describe the console.
This might not be a fair argument against this design system, since it was created to combat the inconsistencies between products in the console, and I believe it's doing a good job, perhaps just slower than we'd all like.
Having been in the AWS console on a nearly daily basis for the past 3 years, I've definitely seen some of their screens that are terrible, some services that are hard to use and I've also seen screens get worse/harder to use with design updates even if they're more consistent. Often this is followed by consistent and better functionality, but that varies per service. I definitely understand where you're coming from as it feels like support for any given service in AWS is a game of chance, but the designs are absolutely converging over time.
Having been in the AWS console on a nearly daily basis for the past 3 years, I've definitely seen some of their screens that are terrible, some services that are hard to use and I've also seen screens get worse/harder to use with design updates even if they're more consistent. Often this is followed by consistent and better functionality, but that varies per service. I definitely understand where you're coming from as it feels like support for any given service in AWS is a game of chance, but the designs are absolutely converging over time.
The console is surprisingly terrible, ugly and basic... although for something that deals with so many unrelated services, I guess it's better to have ugly symmetry than no symmetry at all. I usually need to open it in several tabs just to not get totally off track in security groups and lose whatever services I was looking at, since the back button is unreliable. But it does helpfully remind me of the fact that any of the myriad things I rely on from Amazon right now could just be temporary, half assed implementations on their end that are setting me up for forced updates and technical debt... and that my job isn't supposed to be fun.
[deleted]
Just what I've been looking for! A component framework to make my app even slower! /s
In seriousness, this is a great net benefit. Looking forward to the improvements inherent in open sourcing the framework!
In seriousness, this is a great net benefit. Looking forward to the improvements inherent in open sourcing the framework!
While it isn’t a design I like, open sourcing is at least a good step in getting feedback and engaging with the community.
This is a very good step from AWS. It's good that Accessibility [1] is being given proper attention. In many UI toolkits it's mostly a neglected area.
Will check it out in detail and might even use it in a project.
[1] https://cloudscape.design/foundation/core-principles/accessi...
Will check it out in detail and might even use it in a project.
[1] https://cloudscape.design/foundation/core-principles/accessi...
Here's a talk by Peter Korn, Accessibility Officer at Amazon.
#TDIConf21 Peter Korn (Amazon) "Customer Obsession for Customers with Disabilities":
https://www.youtube.com/watch?v=JgysDOR3SPU
#TDIConf21 Peter Korn (Amazon) "Customer Obsession for Customers with Disabilities":
https://www.youtube.com/watch?v=JgysDOR3SPU
They actually released this months ago[0] but didn't have any documentation or press around it. I believe the original motivation was that certain embed libraries for AWS widgets relied on this design system.
To be honest, it was pretty pleasant to work with. I used it internally at Amazon for years. The journey of reaching that point was considerably more painful, but steady improvements over the years were really noticeable.
The internal component library playground/preview was also much nicer to use than a stock Storybook setup. Nice to see that's gone public as well.
[0]: https://www.npmjs.com/package/@awsui/components-react
To be honest, it was pretty pleasant to work with. I used it internally at Amazon for years. The journey of reaching that point was considerably more painful, but steady improvements over the years were really noticeable.
The internal component library playground/preview was also much nicer to use than a stock Storybook setup. Nice to see that's gone public as well.
[0]: https://www.npmjs.com/package/@awsui/components-react
Where’s the component preview code hosted? I’m interested in Storybook alternatives.
That doesn't look like it's been open sourced yet, unfortunately.
https://github.com/cloudscape-design/components/discussions/...
https://github.com/cloudscape-design/components/discussions/...
Given a new component library I always look for a lazy-loading tree view, and a windowed grid. I'm usually disappointed... Am I simply overlooking them in this case? It seems like AWS would have implemented them at some point.
Windowed grids probably aren't very common because most services with tons of data just have DynamoDB backed table views where pages are lazily fetched rather than sourcing data all upfront. A tree UI would make sense for the S3 console, but they currently just nav to a new page for each subtree path. I just remembered that I actually built a windowed grid implementation on top of the provided table component as well at one point. Can't really point to it, since it's on a console page only visible to a few enterprise customers.
It's worth pointing out that patterns in the AWS-wide design system take some time to get included. If a single team has a use-case for something, they'll often make a feature request and build their own bespoke component to use before things get standardized. Back in the day, neither the table nor datepicker components were available, so I had to roll my own, for example.
It's worth pointing out that patterns in the AWS-wide design system take some time to get included. If a single team has a use-case for something, they'll often make a feature request and build their own bespoke component to use before things get standardized. Back in the day, neither the table nor datepicker components were available, so I had to roll my own, for example.
This has been the the of the major gripes I've has with the web in recent years. In 2022 every single UI framework re-implements the same half-a-dozen to a dozen elements: buttons, alerts, avatars, a dropdown here and there.
Not a single one has reached the level of Sencha/ExtJS [1]. It's still insurmountably hard to create anything beyond the simplest of components despite hundreds of millions of dollars poured into hundreds upon hundreds of new APIs yearly.
[1] https://www.sencha.com/products/extjs/
Not a single one has reached the level of Sencha/ExtJS [1]. It's still insurmountably hard to create anything beyond the simplest of components despite hundreds of millions of dollars poured into hundreds upon hundreds of new APIs yearly.
[1] https://www.sencha.com/products/extjs/
I've used and customized ExtJS a lot, but Sencha the company didn't make it entirely easy. Even after paying the license fees they were still kind of a pain (except one or two awesome people I can think of).
I am not a designer but I've learned from and worked with many. Overall I'd be disappointed if a designer would only look at buttons and typography to make an opinion on a design system.
Actually, picking a design system by going through its components would be the last thing a serious designer would do. They would start with working alongside the product team for requirements.
Actually, picking a design system by going through its components would be the last thing a serious designer would do. They would start with working alongside the product team for requirements.
I believe Orgs and/or Control Tower have a tree control use case.
Glad they did this. It should be taught in UX/UI design classes as a cautionary tale.
It’s a lot better now than it used to be. If anything, I think it would be useful as an example of how some concepts don’t scale when you hit more than 20-ish services. Or how difficult it can be to design a consistent UI/UX for a wide variety of different services.
For what it is and all it does, it’s a miracle that it works as well as it does.
For what it is and all it does, it’s a miracle that it works as well as it does.
[deleted]
This design system played a crucial role in turnaround of CX at AWS over the last 5 years.
People like to bash it but few realize the challenge of creating brand new purpose-built design system from scratch that can work at scale and complexity of AWS.
Is it perfect? No (what is perfect though?) Not a lot of people have been around long enough to understand how bad the situation was prior to Polaris (internal name for Cloudscape). On top of it, the team that owns it is highly competent and opinionated (hey Boris) and they are committed to support and evolution of it.
When I’ll have fitting use case, I will use it in a heartbeat in my own projects.
People like to bash it but few realize the challenge of creating brand new purpose-built design system from scratch that can work at scale and complexity of AWS.
Is it perfect? No (what is perfect though?) Not a lot of people have been around long enough to understand how bad the situation was prior to Polaris (internal name for Cloudscape). On top of it, the team that owns it is highly competent and opinionated (hey Boris) and they are committed to support and evolution of it.
When I’ll have fitting use case, I will use it in a heartbeat in my own projects.
https://polaris.shopify.com/
Amusingly, Polaris is Shopify's design system (which I quite like!)
Amusingly, Polaris is Shopify's design system (which I quite like!)
Shout out to the Polaris team! Personally I was already using the open sourced AWS UI components, looking forward to the refresh.
[deleted]
As a cautionary tale?
Delighted to see the developers at AWS incorporating react w/ TypeScript.
I hope this project stays active and the framework keeps a low overhead: I've spent some time ripping out chakra-ui from my sites due to its complexity making it hard to diagnose styling bugs between styled-system, emotion, etc. Mix that with a monorepo of UX components where packages depend on each other, and them being prebuilt. I could never find out why certain style rules wouldn't apply.
It looks like this project has an interesting thing: style-dictionary (https://github.com/cloudscape-design/components/tree/7433543...)
I'd be interested in reading a dev blog post on the architectural decisions (and lessons learned). Is there any decisions from other major UI frameworks that were trying to be avoided?
One more thing I've never seen before in a framework's documentation: Patterns (very practical and case-specific examples), https://cloudscape.design/patterns/patterns/overview/
Good job to the AWS team on this, will be studying it!
I hope this project stays active and the framework keeps a low overhead: I've spent some time ripping out chakra-ui from my sites due to its complexity making it hard to diagnose styling bugs between styled-system, emotion, etc. Mix that with a monorepo of UX components where packages depend on each other, and them being prebuilt. I could never find out why certain style rules wouldn't apply.
It looks like this project has an interesting thing: style-dictionary (https://github.com/cloudscape-design/components/tree/7433543...)
I'd be interested in reading a dev blog post on the architectural decisions (and lessons learned). Is there any decisions from other major UI frameworks that were trying to be avoided?
One more thing I've never seen before in a framework's documentation: Patterns (very practical and case-specific examples), https://cloudscape.design/patterns/patterns/overview/
Good job to the AWS team on this, will be studying it!
> One more thing I've never seen before in a framework's documentation: Patterns
I really appreciate this! btw some DS have that too
https://ant.design/docs/spec/overview
https://carbondesignsystem.com/patterns/notification-pattern...
I really appreciate this! btw some DS have that too
https://ant.design/docs/spec/overview
https://carbondesignsystem.com/patterns/notification-pattern...
Appreciated these examples, thank you!
[deleted]
The look-and-feel of the AWS console reminds me of some low budget sites of the late 2000s / early 2010s, which is common across cloud providers. Although I understand that this document refers to the design system, not its implementation.
There are samples on the demo page [1].
[1] https://cloudscape.design/demos/overview/
[1] https://cloudscape.design/demos/overview/
I take interest in open source 'business UI' friendly UI frameworks, this is actually a very good choice (besides the weirdness of looking like AWS). A lot of people don't realize there's a lot of basic things that go into this.
Blueprint (https://blueprintjs.com) made by Palantir has been my go-to otherwise but it misses some common things (like a table).
Elastic's recently open sourced framework (https://eui.elastic.co/) looks pretty good too, though I haven't tried it.
Blueprint (https://blueprintjs.com) made by Palantir has been my go-to otherwise but it misses some common things (like a table).
Elastic's recently open sourced framework (https://eui.elastic.co/) looks pretty good too, though I haven't tried it.
Thanks for the recommendation. I've used VMware's Clarity professionally (https://clarity.design/) and it's pretty bad (design and code wise). There's also IBM's Carbon (https://carbondesignsystem.com/); I love its design but it's incomplete in some areas. Microsoft has Fluent UI (https://github.com/microsoft/fluentui) which I have never used.
Would love to see an "awesome" list for all business UI frameworks like this.
Here’s a list I maintain of UI frameworks: https://gist.github.com/manigandham/34154e63dc3c1b8747fab40d...
> Blueprint (https://blueprintjs.com) made by Palantir has been my go-to otherwise but it misses some common things (like a table).
I see a table package for Blueprint - what’s missing from that? (I know nothing about Blueprint)
https://www.npmjs.com/package/@blueprintjs/table
I see a table package for Blueprint - what’s missing from that? (I know nothing about Blueprint)
https://www.npmjs.com/package/@blueprintjs/table
Yeah it's kind of confusing, Blueprint's table is more like a spreadsheet ( https://blueprintjs.com/docs/#table).
Curious to hear more about your experience with blueprint? Any common issues, bugs, etc? Is it frequently updated? Performant? Intuitive?
Pretty good otherwise, very frequently updated since it looks like Palantir actually uses it internally.
Another issue is it's completely mobile incompatible, which is kinda sad but usually not practically a big deal for the usecases it's used for.
Another issue is it's completely mobile incompatible, which is kinda sad but usually not practically a big deal for the usecases it's used for.
I've found https://preview.tabler.io/ to be really good for a business-friendly UI though I haven't used it extensively
I used Tabler in my last role, but their react wrapper seems to have been abandoned so for my more recent efforts I’ve used core ui which has been an ok experience.
Oof, despite the comparison to the AWS console which is kind of a UX mess, Polaris components (the old internal name) are really nice to use.
This is the aws console? Like EC2 and S3? With crap design and scrolling and refresh delays and tons of bugs?
The OLD one was better (which I think was mostly server side rendering) is still better than the new one that you're basically forced to use.
It really says something that when you complain about it, the only good response is "well you're not supposed to use it, you're supposed to use something else like terraform or the API (don't get me started) or ansible".
I REALLY hope this means they are dumping it for another rebuild, and the open sourcing is a fig leaf to the people that worked hard on the current redesign.
The OLD one was better (which I think was mostly server side rendering) is still better than the new one that you're basically forced to use.
It really says something that when you complain about it, the only good response is "well you're not supposed to use it, you're supposed to use something else like terraform or the API (don't get me started) or ansible".
I REALLY hope this means they are dumping it for another rebuild, and the open sourcing is a fig leaf to the people that worked hard on the current redesign.
"The old UI was better" should be a bus people who say it get on and that bus should drive off into the sunset so the rest of us never have to hear such a boring take ever again.
Alternate take, the people who keep mucking up the perfectly fine UI[1] that I've been using for years should get on that bus, so the rest of us never have to worry about waking up and everything is in a different place for absolutely no reason.
[1] In general, I mean - I actually don't use AWS.
[1] In general, I mean - I actually don't use AWS.
As someone who actually does use AWS, it was not "perfectly fine". Far from it, in fact.
The biggest benefit from this redesign is the very clear insight into billing you now get. Right on the main page, you see your billing breakdown, both from a "here's what you've spent this much" and "here's your projected spend" perspective.
That, alone, was huge, and required a new UI to display that information cleanly and clearly.
Cognito's UI is now substantially better, as well. Before it was very different from the rest of the site and therefore unintuitive, and it's now matching.
There are other examples, but suffice it to say the folks claiming the "old UI was better!" are not doing so from any place of reasonability.
So yes, can all of the folks who fear change please hop on whatever mode of transportation you prefer, and leave those of us who understand that progress is, generally, good alone?
The biggest benefit from this redesign is the very clear insight into billing you now get. Right on the main page, you see your billing breakdown, both from a "here's what you've spent this much" and "here's your projected spend" perspective.
That, alone, was huge, and required a new UI to display that information cleanly and clearly.
Cognito's UI is now substantially better, as well. Before it was very different from the rest of the site and therefore unintuitive, and it's now matching.
There are other examples, but suffice it to say the folks claiming the "old UI was better!" are not doing so from any place of reasonability.
So yes, can all of the folks who fear change please hop on whatever mode of transportation you prefer, and leave those of us who understand that progress is, generally, good alone?
The basic EC2 is definitively not better. If anything, they wasted a massive amount of effort moving to a new framework rather than just improving the old UI.
Oh, cost savings on the front page? Yes that must have been IMPOSSIBLE in the old UI framework.
Was the old UI perfect? Hell no. What is amazing with the redesign is how little usability boost it provides, and how much aggravation and bugs it has. Very serious bugs, like lists of infrastructure changing under your cursor just as you're about to do something.
There are still bad bugs with screen refreshes that don't remember search criteria.
Text inputs not allowing certain characters to be inputted, or not working at all.
You'd think a redesign would improve readability, flow, speed, and capability, and that a 60 billion dollar a year enterprise held up as the gold standard of industry IT could reengineer their core UIs effectively.
Oh, cost savings on the front page? Yes that must have been IMPOSSIBLE in the old UI framework.
Was the old UI perfect? Hell no. What is amazing with the redesign is how little usability boost it provides, and how much aggravation and bugs it has. Very serious bugs, like lists of infrastructure changing under your cursor just as you're about to do something.
There are still bad bugs with screen refreshes that don't remember search criteria.
Text inputs not allowing certain characters to be inputted, or not working at all.
You'd think a redesign would improve readability, flow, speed, and capability, and that a 60 billion dollar a year enterprise held up as the gold standard of industry IT could reengineer their core UIs effectively.
Totally agree. The old UI was much better. I think they ignored who uses the console. If I’m trying to load a UI with thousands of resources server side rendering is much faster.
The new UI is frustrating. Luckily we mostly use cdk for terraform and don’t have to use the console much.
Seeing a lot of mixed feelings about the AWS UI here. Just my two cents: a good project shouldn't need it for anything much beyond fiddling during development and poking around during problem solving.
In the latter case, I deeply appreciate the minimalism compared to something like GCloud. You can pump the refresh button on many AWS consoles and they refresh in a second or two. Progress spinner cancer while present is minimal compared to many popular platforms, and in particular relatively nonexistent compared to the white elephant that is GCloud
Given the choice between a half-developed AWS console basically emitting some raw XML in a <pre> tag, and the overengineered overdesigned monstrosity of GCloud, I'd always prefer the fast hacky option especially while trying to figure out why something is broken.
While the GCE panels look visually fantastic, there are so many cases that make it obvious actual engineering workflows weren't considered during the design process. Be it missing buttons from the context-sensitive toolbars, pointless sidebars, or screens you can't refresh except by hitting F5 before leaving for lunch. I've yet to see any part of GCE that could be described as "snappy". Plenty of AWS bits come much closer to that (although I notice AWS has started slipping down the GCE road to hell in a couple of their newer service UIs)
AWS is far from perfect, I can't stand CloudWatch, but relatively speaking it is perfection compared to stackdriver
tldr I'm glad it's ugly, it means they were focusing on the important stuff
In the latter case, I deeply appreciate the minimalism compared to something like GCloud. You can pump the refresh button on many AWS consoles and they refresh in a second or two. Progress spinner cancer while present is minimal compared to many popular platforms, and in particular relatively nonexistent compared to the white elephant that is GCloud
Given the choice between a half-developed AWS console basically emitting some raw XML in a <pre> tag, and the overengineered overdesigned monstrosity of GCloud, I'd always prefer the fast hacky option especially while trying to figure out why something is broken.
While the GCE panels look visually fantastic, there are so many cases that make it obvious actual engineering workflows weren't considered during the design process. Be it missing buttons from the context-sensitive toolbars, pointless sidebars, or screens you can't refresh except by hitting F5 before leaving for lunch. I've yet to see any part of GCE that could be described as "snappy". Plenty of AWS bits come much closer to that (although I notice AWS has started slipping down the GCE road to hell in a couple of their newer service UIs)
AWS is far from perfect, I can't stand CloudWatch, but relatively speaking it is perfection compared to stackdriver
tldr I'm glad it's ugly, it means they were focusing on the important stuff
To me the benchmark is digital ocean. Obviously it's not anywhere near as powerful, and maybe it shouldn't be anyways, you can use the API to do anything extra. But I almost never find myself lost using DO in the ways that I do with AWS.
Dear. God. GCloud/GCP. What a total mess. I work on the ui console all day. It hangs, errors out, its slow, it breaks. Every new hire complains, they assume it is their browser or internet connection - it isn't it is just horrible. I want to list the servers - TOO BAD, hundreds of thousands of lines of javascript run to display a list of servers. Let's load up javascript hipster transitions instead. https://i.imgur.com/8ZhYRwS.png Search? Don't even bother you need to use the command line and grep it. The product wasn't built to have 1k vms, so I large customer - suffer [which doesn't make sense as a business]. When I go on AWS i am just amazed at the speed. GCP doesn't reach out or care, they ask "SEND us a network diagram" - then ghost you. GCP: no perks, no help, no cool tshirts, no 'how is it going?', no anything except 24 year old 'representatives' who cannot put clear sentences together. Let's have interns run multimillion dollar accounts. I used to hang out at AWS loft - those people helped right there on the spot - would jump in call their network guy to debug something. They just gave a shit. GCP will sunset eventually that must be their strategy.
IMHO, google doesn't use GCP. Amazon does use AWS. They care- if it sucks, they are using something that sucks. GCP couldnt' care less if something doesn't work after all they don't use it. And the amount GCP is behind is unreal. Need a database reader loadbalanced endpoint? Make it yourself. Cloudrun has network issues?, no one else complained, ghosted. What about your career? You think your next employer will use GCP: nope.
IMHO, google doesn't use GCP. Amazon does use AWS. They care- if it sucks, they are using something that sucks. GCP couldnt' care less if something doesn't work after all they don't use it. And the amount GCP is behind is unreal. Need a database reader loadbalanced endpoint? Make it yourself. Cloudrun has network issues?, no one else complained, ghosted. What about your career? You think your next employer will use GCP: nope.
Google arranged a meeting with me to discuss migrating to GCP from AWS. I wasn't especially interested, but I decided to humour them anyway as some of our AI workloads may be better suited to GCP.
At the arranged meeting time, none of the three people on their side showed up. No emails, no follow up.
I've had similar experiences every single time I've tried to work with Google.
At the arranged meeting time, none of the three people on their side showed up. No emails, no follow up.
I've had similar experiences every single time I've tried to work with Google.
[deleted]
Yeah for real, AWS may be deeply flawed but by God five minutes using the GCP flight control NASA computer UX and I was about ready to hit Mars.
> While the GCE panels look visually fantastic, there are so many cases that make it obvious actual engineering workflows weren't considered during the design process.
I truly believe that no one at Google uses Google Cloud Console.
Otherwise they wouldn't even end up with things like labels with unselectable text: https://twitter.com/dmitriid/status/1513572047909183499
Because, and I kid you not, it "has a clean, modern experience for a clean, modern cloud" https://twitter.com/rseroter/status/1349781777875836928
I truly believe that no one at Google uses Google Cloud Console.
Otherwise they wouldn't even end up with things like labels with unselectable text: https://twitter.com/dmitriid/status/1513572047909183499
Because, and I kid you not, it "has a clean, modern experience for a clean, modern cloud" https://twitter.com/rseroter/status/1349781777875836928
[deleted](1)
I heard a lot about design systems the past few months, would one of you have a recommendation for a good read that would explain the challenges and/or the process to create such a system?
[deleted]
In case this is about the new console UI, I have to say Ive not yet seen worse UX.
So much space on the screen is wasted, have to use resize scrolls to make screen readable, things dont load fluently and you wonder whether something in your infra broke or „ups” it was simply not loaded yet.
Sorting by name till not long ago only worked for loaded items (hello AWS I have 2000 VMs I want to sort)..
I can go on and on because almost every new screen I was forced to opt into proved itself to be a complete UX nightmare.
So much space on the screen is wasted, have to use resize scrolls to make screen readable, things dont load fluently and you wonder whether something in your infra broke or „ups” it was simply not loaded yet.
Sorting by name till not long ago only worked for loaded items (hello AWS I have 2000 VMs I want to sort)..
I can go on and on because almost every new screen I was forced to opt into proved itself to be a complete UX nightmare.
[deleted]
I am really surprised how fast/responsive it is. Most UI frameworks feel clunky/slow and react ones feel even slower sometimes.
I think the trick is cutting down animations
This looks pretty good.
Seems people have baggage from bad experiences. I guess remember how large the scope & pace of AWS. And remember that this was their solution to those UX issues not the cause!
Seems really complete.
Pro-tip you may not have thought of: this is really well suited to internal debug/admin/troubleshooting tooling.
Seems people have baggage from bad experiences. I guess remember how large the scope & pace of AWS. And remember that this was their solution to those UX issues not the cause!
Seems really complete.
Pro-tip you may not have thought of: this is really well suited to internal debug/admin/troubleshooting tooling.
This looks IDEAL for information-dense internal tooling UI (admin, debugging, troubleshooting, power-user etc.)
Looks very well executed overall, but the demos really show it off.
Looks very well executed overall, but the demos really show it off.
I am a devops engineer and I respect the AWS console.
After runnning a long Terraform run, rather than use the Describe* APIs on the command line, I use the console to check that everything was created correctly.
The AWS console therefore is powerful automation ;-)
After runnning a long Terraform run, rather than use the Describe* APIs on the command line, I use the console to check that everything was created correctly.
The AWS console therefore is powerful automation ;-)
It's funny, rather than use the console, awscli, or AWS docs even - I often reach for Terraform or its docs.
The documentation aspect in particular is interesting I think. So often I find AWS concepts or interactions between resources are more clearly explained by the AWS provider for TF than by AWS itself. The latter too often reads like salesman mumbo-jumbo to me, devoid of actual detail or what actually is it.
The documentation aspect in particular is interesting I think. So often I find AWS concepts or interactions between resources are more clearly explained by the AWS provider for TF than by AWS itself. The latter too often reads like salesman mumbo-jumbo to me, devoid of actual detail or what actually is it.
This - 100%. Don't give me all the mumbo-jumbo. Just give me what each nob and dial is and what settings it accepts.
[deleted]
People are conflating consistency of a design system with consistency of ux metaphors. I worked on the team that built the new home page dashboard and my experience with the components and associated guidance was excellent.
It is not the fault of the design system that service teams, for example, created 5 different interactions for deleting a resource.
AWS leaned hard into building as many services as possible, at the expense of console ui consistency. There is now a swing back toward consistency, and I expect to see more improvements at the "consistent metaphors" level soon.
It is not the fault of the design system that service teams, for example, created 5 different interactions for deleting a resource.
AWS leaned hard into building as many services as possible, at the expense of console ui consistency. There is now a swing back toward consistency, and I expect to see more improvements at the "consistent metaphors" level soon.
Yeah, nobody cares about the console. Its really unfortunate. Adding console parity for new features was always an afterthought, and code quality was absolutely terrible for my service. Also we used nodejs 8 up until last year. What a mess.
I think it is getting better, but it’s incredible that it was neglected for so long.
I think it is getting better, but it’s incredible that it was neglected for so long.
I hate how slow the console’s search is. Seems like every character is a request sent to a server. Don’t know why it’s not done client-side only.
Or maybe it’s just my Mac, but I doubt it.
Or maybe it’s just my Mac, but I doubt it.
curious how lightweight or not this is? can't find it in bundlephobia so i assume its not on npm yet, what is the kind of size it adds?
It was such an honor to work with them, and even though little to none of my code must be there (I've heard it had to undergo a full rewrite) it makes me proud to have been part of that. It was a humbling experience to work alongside such smart people.