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.

Unless you are trying to search, and have to wait for 5000 items to load 50 items at a time :/

Oh, and then you find that search only supports either exact matches, or (for some reason) suffix matches.

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.

I think a big part of it is this:

> staring at a spinner spin for far too long.

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.

5 clicks to accomplish something is fine if each takes 10ms. 5 clicks to accomplish something if each takes 5s is an eternity (JIRA).

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.