AWS open sourced the AWS console design system
github.com
github.com
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.
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.
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.
https://github.com/cloudscape-design/components/discussions/...
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.
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 see a table package for Blueprint - what’s missing from that? (I know nothing about Blueprint)
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.
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.
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.
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.
Amusingly, Polaris is Shopify's design system (which I quite like!)
Will check it out in detail and might even use it in a project.
[1] https://cloudscape.design/foundation/core-principles/accessi...
#TDIConf21 Peter Korn (Amazon) "Customer Obsession for Customers with Disabilities":
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.
I think it is getting better, but it’s incredible that it was neglected for so long.
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 really appreciate this! btw some DS have that too
https://ant.design/docs/spec/overview
https://carbondesignsystem.com/patterns/notification-pattern...
Or maybe it’s just my Mac, but I doubt it.
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.
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.
[1] In general, I mean - I actually don't use AWS.
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?
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.
Looks very well executed overall, but the demos really show it off.
For what it is and all it does, it’s a miracle that it works as well as it does.
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 ;-)
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.
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.
Still leagues better than Azure, which causes brain damage.
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.
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
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.
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.
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
In seriousness, this is a great net benefit. Looking forward to the improvements inherent in open sourcing the framework!
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.
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.)
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.