Back in 2015 I worked at AWS for 3 years. I was assigned to a small team that was researching the state of web components and the feasibility of developing custom components to share across consoles. This same project that they now call Cloudscape. It's amazing the progress they made since.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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?
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 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 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.
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 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.
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.
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.
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 ;-)
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.
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?
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.
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.
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.
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.
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.
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
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.
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.
> 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.
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.
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.
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.)
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.