>On the other hand, I absolutely loathe every single UI that has ever come out of AWS, and there is absolutely no chance I give the editor they've built here a shot without hearing lots of positive reactions first.
I agree so much with this. I hate the AWS console UI so, so much and It blows my mind that such a large company can't seem to even get on the same page about what color scheme or menu bar position they want to use.
But actually, I'm messing around with Honeycode right now and although I haven't gotten a chance to really dig deep and test the long-term usability of it, I have to say that so far it is gorgeous and intuitive. If the UI team that worked on this just completely took over the AWS console, I wouldn't complain.
Can someone smarter than me explain why the AWS UI is so off-putting? I also find myself just put off by AWS UIs.
I can't even figure out why I hate it so much. Looking at the screenshots though immediately filled me with the sense that this thing would just be awful to use. When I go back to the screenshots to try to find objective things I dislike about the UI, I can't really find anything. It seems to do the stuff a UI needs to do.
Maybe it's just a negative association with the look & feel of AWS UI, because most of the time when I'm interacting with AWS I'm trying to get a service I haven't used before up and running. Going back and forth between dense documentation and the UI, clicking and failing, and staring at a spinner spin for far too long.
Perhaps all those hours spent fighting with other pages that look so similar to this one has given me a subconscious dislike for all AWS UIs.
I seem to be the only person who likes the AWS UI. So here's my defense of it.
AWS is like the hardware store. Who thinks Home Depot is elegant? It's not. Who think their organization scheme is a thing of beauty? It's clunky and just functional.
But the idea is, when you go to Home Depot, you're there to get work done. The interior communicates that. The real work comes after you leave - Home Depot understands it's just a facilitator.
AWS did that.
I personally give credit to AWS for looking at Google, and learning. They could've had some high-handed PM come in and roar ITS TIME TO HAVE A UNIFIED DESIGN SCHEME and then forced everyone to deal with UI updates nonstop, you know the game of 'where did it go now,' 'oh, they moved it here.'
AWS went in the opposite direction. At the risk of ugliness, they give you the most bare bones UI, basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results. We know the downside: it can be unpleasant. But the upside is, it rarely changes, its consistent, and (aesthetic concerns aside) it gets the job done.
It seems a little weird to commend AWS for their design sense, but when you phrase it as their design goals, I vastly prefer them to Google or any other 'opinionated' service.
You're not alone, and thanks for putting into words what had been the back of my mind.
I could not care less about the aesthetics of their dashboard, when I'm on it I'm there to get something done and I never seem to have an issue with that.
This is such a strange comment to me. The issue with the AWS UI isn't that it's "ugly", the issue IMO is that it is the exact opposite of the things you claim it is.
> the most bare bones UI
The AWS UI is one of the most cluttered, complex, complete-opposite of "bare bones" of almost any web app I can think of, except for maybe Salesforce.
>basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results.
My largest gripe with AWS is that it does not have a clean mapping of fields/pages/results. The flow of getting to "results" in one AWS service is completely different from the flow of getting to "results" in another. The launch wizard for ECS, for example, doesn't even follow the same paradigm that the launch wizard for EC2 follows. One of them has a clear vertical layout with successive config pages, while the other has a mixed vertical/horizontal layout with sub-pages.
When doing something as basic as launching an EC2 instance, the AMI selection page has "Select" buttons next to each AMI on the right side of the page, and clicking one takes you directly to the next page. And then on that very next page, the instance type selection, the format has changed. Now the way you select something is by clicking a radio button (which is on the complete opposite left side of the page!) and then clicking "Next" at the bottom of the page. Why do these two pages require completely different models of interaction when they are essentially accomplishing the same thing?
Even within the VPC service for example, some pages have clusters of information that are right-aligned on the page, while others put the same information at the bottom of the page. Some pages have the "Create new resource" button on the top left, while others have them on the right side. I could keep going... It's the total opposite of "clear mapping of results" to me, and certainly isn't anything close to "consistent".
I don't think AWS "nudges you as little as possible", I think AWS nudges you a lot, but nudges you in completely different directions for every single service, causing you to feel bounced around like you're in a mosh pit when you're having to switch between EC2, CloudTrail, S3, etc.
Even in Home Depot they at least have uniformity in how they arrange their aisles. The nail aisle has little buckets where nails are arranged by a specific ordering system, typically by type of nail and size. If you go an aisle over to plumbing, the pipe joints are all arranged in similar little containers, also with a sensible ordering system typically by type of pipe and size. If you go to the paint aisle, the displays are different but you can still expect them to be arranged in a sensible ordering system, such as by type of paint and color.
If they went the AWS way, the aisle of nails would just be 2-3 large tubs with a bunch of individual nails thrown in, while the plumbing aisle would have things organized in small tubs alphabetically by the name of the manufacturer, while the paint aisle would be condensed like a newspaper with the pages in order of Bob's favorite colors. It would be chaos.
Sorry for the rant. I respect that you apparently like the UI, but it's weird to me that we have such opposite experiences. You say "Home Depot understands it's just a faclitator" and that AWS is too, and I totally agree. But my opinion is that AWS completely fails at effectively facilitating.
A bit of backround: a service typically builds their API first, and then builds the console as a front-end to that API. For most services, everything you can do in the console, you can do via an API call. (I assume Honeycomb is an exception to this.)
That API-first doctrine is at the heart of the underlying problems, which are:
1. Machine-friendly data models.
2. Distributed-friendly data models.
3. Deliberately independent and orthogonal services.
4. A vast range of customer needs over a console that doesn't itself make money.
AWS really does put effort into making their console useful for getting work done. You'll find some workflows that are pretty usable.
But when you get outside a handful of extremely common workflows that were technically convenient for a specific team to implement, those problems become dominant and the console becomes painful if not f*ing useless.
That's why (I suspect) you hate it.
> ... and staring at a spinner spin for far too long.
Oh yeah, fundamental cloud problem #5: "A few minutes" is absolutely forever when you're troubleshooting.
You probably didn't hate it the first or second time you opened it up. Only after recognizing that many operations are extremely sluggish did you start to build an aversion.
I think the same this can be said about JIRA and many other sluggish, enterprise-y tools. The UI design is typically more-or-less OK, it's the experience of clicking on things and having no idea when it will be done, why it's taking so long, or what a faster alternative is that makes you feel trapped.
The UI might not have major aesthetic problems but they could probably be more consistent between services.
I think you might have hit the main issue on the head though, unless you use a service regularly it's difficult to do much without the hefty manuals and while the services may be complex they could make the common or "beginner" paths more obvious.
Having sane defaults where possible and splitting basic and advanced settings could make it more accessible while allowing users to get familiar with the tools. Ideally a good UX should cater to a variety of proficienies and help users learn.
> If the UI team that worked on this just completely took over the AWS console, I wouldn't complain.
This is the fundamental misunderstanding. There is a centralized AWS console team/organization. They are responsible for the UI libraries, guidelines, common elements, mezzanine, etc, across all of AWS.
They dont write the actual "service pane" UX that you interact with when you start an EC2 instance or upload an S3 object. That surface area is so large, varied, and changes at a frantic velocity that there's no way a single team or group could ever keep up. Even a single "service" like EC2 or Systems Manager actually has multiple front end teams responsible for different portions of the UX or functionality.
You're right, and I did think of that after I clicked "reply". What I meant was that a company with so much resources doesn't seem to have that capability. Even with such a large size, I would imagine Amazon of all companies would have the resources to say "this is the design, now get on board" and make it happen.
This goes for other aspects of AWS as well, such as consistency in the way services report to CloudTrail or are referenced in CloudFormation. Overall there just seems to be little coordination amongst AWS teams, and that's always surprised me.
Teams at AWS are almost like individual companies of 5 - 15 people. When integrating with each other they do it in almost the same way external apps would. The frontend of each app is decided by each team using a shared library for UI styling and some guidelines.
This helps with iteration speed and not getting bogged down in middle management approval hell, but it does lead to inconsistency problems.
I have read this is the intended trade-off. They want each AWS service to release new features as quickly as possible. If they were required to coordinate with other teams on UI decisions, that would slow them down.
I agree so much with this. I hate the AWS console UI so, so much and It blows my mind that such a large company can't seem to even get on the same page about what color scheme or menu bar position they want to use.
But actually, I'm messing around with Honeycode right now and although I haven't gotten a chance to really dig deep and test the long-term usability of it, I have to say that so far it is gorgeous and intuitive. If the UI team that worked on this just completely took over the AWS console, I wouldn't complain.