These comments are fascinating to me.<p>I was responsible for designing, leading, and building the frontend for an AWS service. One of the challenges was with obtaining useful feedback from a diverse range of people. During the product definition phase, the majority of the feedback, input, and feature priority was for customers who were planning to dedicate a large budget towards using said service. I often felt that stakeholder decisions sacrified usability for feasibility.<p>Regardless, it was the responsibility of my service team to seek and obtain feedback, input, and data points that could help us inform our decisions. But from what I witnessed, it only went as far as to validate our exisiting concepts and user personas of how people use AWS services. Going beyond that was seen as unnecessary.<p>The universal thinking within AWS is that people will ultimately use the API/CLI/SDK. So, investment into the console is on a case by case basis. Some services have dedicated engineers or teams to focus on the console, but most don’t.<p>I’m proud of what I built. I hope that my UI decisions and focus on usability are benefiting the customers of that service that I helped build.<p>A little known fact, in the AWS console exists a feedback tool (look in the footer) that will send feedback straight to the service team. I encourage you to submit your thoughts, ideas, and feedback through that tool. There are people and service teams who value that feedback.
Since starting to use Google Cloud for bits and pieces I've come to appreciate the AWS UI approach much more than previously. All those little spartan pockets of UI means nothing gets overengineered, the tools feel more like a quick Intranet web app (and generally load as quickly!) than anything else<p>Meanwhile over in GCloud, almost /any/ operation whatsoever will spam you with an endless series of progress meters, meaningless notification popups, laptop CPU fans on, 3-4 second delays to refresh the page (because most of their pages lack a refresh button), etc., and the experience is uniform regardless of whatever tool you're using.<p>The uniform design itself was clearly done by a UI design team with little experience of the workflows involved during a typical day. For example, requiring 2 clicks and at least one (two?) slow RPCs to edit some detail of a VM, with the first click involving the instance name with any 'show details' button completely absent from the primary actions bar along the top. The right-hand properties bar in GCloud is also AFAIK 100% useless. I've yet to see any subsection that made heavy use of it<p>Underengineering beats massive overengineering? Something like that. Either way, the GCloud UI definitely pushes me to AWS for quick tasks when a choice is available, because the GCloud UI is the antithesis of quick
I hate AWS so much.<p>I spent 3 hours trying to get a bucket to host a static single page of html and failed completely.<p>I use amazon polly. I wanted to know how many characters I was using each month. I spent 2 hours searching through hundreds of pages and literally couldn't find that information.<p>I thought of trying to start a little text to speech service for dyslexics to make it easy to use Polly but one of the main thing putting me off is having to get my arms mangled in the AWS machine.<p>The whole thing is so totally maddening. I would love to be able to sit in on their meetings where they talk about usability, what do they say? Do they think everything is fine? Do they know it's totally broken and don't care? Are they unable to hire a UX designer? What is the problem?
I know many people will disagree, but I really miss the VMware fat windows client. (vsphere 5, before they ruined it with the weird flash hybrid that didn't work properly)<p>That, was a paragon of design reliability and speed compared to the AWS console.<p>What annoys me the most is the sheer weight of each page. If you have to context change, its multiple seconds before the page is useable.<p>A classic example is lambda. I click on the function, page reloads (no problem) 1-2 seconds later the page is fully rendered, I can _then_ click on the monitoring tab, another couple of seconds, and then I can jump to the latest log, in cloudwatch.<p>Cloudwatch can get fucked. Everything about it is half arsed. Search? all of the speed of splunk, combined with its reliability, but none of the usefulness.<p>The standard answer is "you should use Cloudformation" I do, it too is distilled shart. (anything to do with ECS can cause a 3 hour, uninterruptible hang, followed by another timeout as it tries to roll back.)<p>It also lazy evaluates the acutal CF, which means that parameter validation happens 5 minute in. Good fucking job there kids.<p>What I really want is a QT app in the style of the VMware fat client (you know with an inbuilt remote EC2 console, that'd be great...) that talks to AWS. The GUI is desgined by the same team, and is _tested_ before a release by actual QAs who have the power to block things until the change is released.
One of my pet peeves about it (might have since been fixed) is that AWS will gladly walk you through the wizard to set up an EC2 server, and only at the very end say “oh you don’t have permission to do that lol”.<p>I compared it to a bartender who immediately recognizes that you’re underage but offers you alcoholic drinks, gives you samples, asks about preferences, counts out your change, and only after all of that stops you from drinking it.<p><a href="http://blog.tyrannyofthemouse.com/2016/02/some-of-my-geeky-tech-jokes-with.html" rel="nofollow">http://blog.tyrannyofthemouse.com/2016/02/some-of-my-geeky-t...</a>
I am pretty sure the AWS business model is to get you to write your own code that interacts with the API so that when you think about switching to another provider, you realize that you're throwing away months of work and decide not to. They also make the API requests take so many parameters that are specific to your particular use case that nobody will ever be able to write a generic tool that does what you want. Ever run "awscli help" and find anything useful? Didn't think so. Write your own tool if you want help!<p>Amazon is very much in that "we were here first so we'll do whatever we want" mentality. They can provide worse service for more money, and people love them. Nobody ever got fired for picking AWS!
The example I ran I to the other day was so typical of AWS. I was trying to set a monthly budget for my account but the "Continue" button was greyed out. After staring at every field for a long, long time (and attempting to undisable the button through the dev tools) I realised that the value of "80" in the percent usage trigger field was not in fact a pre-populated value, but a value in the "placeholder" field. I needed to manually enter a value (and chose to enter "80").<p>This is not just bad UX, this is the territory of never even bothering to sit down with someone to see how they might use the product. Amazon love to tout their focus on the customer and amazing leadership principles, but they sure produce some mediocre experiences.
On the other hand, their CLI tool is very good.<p>I wrote some video training material 3 years ago that goes over setting up an ECS cluster and I decided to use the CLI for just about everything. We interact with a number of resources (S3, load balancers, EC2, ECS, ECR, RDS, Elasticache, etc.) and other than a single flag to login to ECR it all works the same today.<p>I'm happy I chose not to use the web console. The only time I used the web console was for creating IAM roles and I've had to make a bunch of updates since the UI changes pretty often. It would have been a disaster if I used it for everything.
It seems to me that there is a quite profitable business case in a thin abstraction over AWS/Azure/Google App Engine (or whatever it's called now).<p>There are lots of services like Zeit Now and Heroku that supply a complex abstraction to the point where it feels like an entirely different product. What I would want is something that allows me to host docker images/K8s on one of the big three (I guess others as well) and lets me to use configuration as code to the extent possible, but with UI/command line/API helpers that create a uniform abstraction so that can easily switch.
Search in the UI is my particular bane.<p>Sometimes it works great (searching for EC2 instances).<p>Sometimes you need to construct restricted search queries (slightly aided by a slow dropdown auto-complete) that look like `Name: Begins With: /blah/` (ParameterStore).<p>Sometimes search is client-side, and only searches the page you're currently on (ECR, I think? I can't remember what does this). I think in this case it's sometimes form just following the limited functionality of the API.<p>I have a _lot_ of scripts that are just ways to extract data quicker than I can in the UI.
Here is a startup idea for grabbing: Make a better interface for AWS/Google Cloud.<p>Since their APIs covers everything this should be possible. Be the first UXaaS.<p>A killer feature: a server by server breakdown of Google Cloud expenses. It is impossible to understand what you are paying for on Google Cloud. They lump everything together in an incredibly confusing bill.
The three things that annoy me the most about the console:<p>1) state management/sync is frequently terrible. E.g you are looking at a page with some health indicator and a log view. The last entry in the log is some variation of "transitioned from busted to not busted", but the state indicator doesn't update until you refresh.<p>2) if you have multiple tabs open at a time (pretty common use case) there is a good chance it will suddenly decide that you have to reload the page for some reason, often when you are in the middle of something<p>3) live updating. Why the hell do I have to sit there hitting refresh on so many of the views to get up to date data? I've often sat there waiting for something to finish, only to realise it's been done for a while but the page has not updated. This seems closely related to (1).<p>I find the overall design of the console fine, generally the UI is manageable, but the actual implementation is a steaming pile.
I've never liked the web console much either. Never found it very intuitive, or easy to use. But, once you navigate the maze, & learn where the few things you need are, it does get the job done. And to be fair it is fast.<p>Not sure why, but for some reason I like clicking around in the web app, so makes me wish it was a better experience. In contrast, compare this to the Digital Ocean web console. It has beautiful design that is nice to look at. It's un-complicated & clutter free. Overall a very pleasurable web app, I've always been inpressed with their UX.<p>But as people have pointed out, it seems Amazon expects us to use the CLI & APIs, and the web console is not a priority. So maybe I'll start moving in that direction with my AWS services.
The Law of Better is Worse:<p>User-friendly tools prevent skilled middlemen from monetizing their expertise, which stifles adoption of that tool. So on-sellable tools that are too easy-to-use, don't get on-sold.<p>Some examples by contradiction: tax returns, AWS Dashboard, many programming languages.
It's just so fragmented. Some parts are actually almost great (Lambda) while others are downright awful. Batch is the worst, and it's been like this for years. As soon as you go over a couple of hundred jobs per day, it becomes unmanageable quickly.<p>You still have to do some trickery with the CLI too. Let's say I want to get all logs from failed Batch jobs in the past day? This involves:<p>* Listing the Jobs (possibly paginated)<p>* Parsing out the log stream names from JSON (oh, and separate logs for separate attempts)<p>* Iterate through log streams and query Cloudwatch (each paginated)<p>* Parse JSON<p>I am sure we're all writing half-baked wrappers for our individual use-cases, I am surprised no one's published something generally useful for stuff like this.<p>Whereas with Kubernetes, that's all a single call with kubectl...<p>Don't get me wrong, we wouldn't be on AWS if it didn't make sense and they have been pushing development forward a lot. But it's unfortunately fragmented.<p>The only way to stay sane here is to use Terraform. That way you can stay out of it at least for creation and modification of resources and will have an easier time should you want to migrate.<p>EDIT: Another great example from Batch: Let's say you have a job that you want to run again, either a retry or changing some parameters.<p>AWS Console:<p>* Find job in question (annoying pagination through client-side pagination where refresh puts you back on page 1).<p>* Click Clone Job<p>* Perform any changes. (Changing certain fields will reset the command, so make sure you stash that away prior to changing)<p>* Click Submit<p>* Job ends up in FAILED state with an ArgumentError because commands can not be over a certain length.<p>Turns out that the UI will split arguments up, sometimes more than doubling the length of a string, and there's nothing you can do about it except resort to CLI or split it up into smaller jobs if you have that option.<p>CLI:<p>* Get job details<p>* Parse JSON and reconstruct job creation command<p>* Post<p>It baffles me how container fields and parameters differ from what you can GET and what you can POST; you really need to parse the job down, and reconstruct the create job request.<p>I completely understand that it will be like this when services launch. But it's been years now.
The problem with AWS teams in general is their arrogance. I dread having to deal with them. They are destroying Amazon’s reputation.<p>Don’t want to bother you with specific examples, but every interaction I had with them was dreadful.<p>I think this attitude gets reflected in their console design.
I don't find the console that frustrating, or when it is, I understand why. UIs are hard.<p>What I do find frustrating is how much of the docs are written in a console-first way. In most cases, the straightforward definitions of resources, attributes and the relationships between them are tucked away (or not present at all) in favor of "click this, then click that" style.<p>I am convinced that the best way to understand a cloud service is to understand its internal data model and semantics, but this is too often hidden behind procedural instructions.
Reading these threads make me realize I am either a victim of Stockholm syndrome or most developers are way more picky than me. I’ve never gotten frustrated at the aws console, though I have noticed some of the rough edges. I guess at this stage in my career I’ve internalized muddling through stuff without letting it bother me. The only exception to this probably is when I open the door and peek through to the latest insanity in JavaScript land, which I find impenetrable. (I’m looking at you, redux/saga/whatever)
Surprised nobody has mentioned AWS's official (but no longer updated) GUI client: ElasticWolf[0]. It is very much not-maintained but it does have some benefits.<p>My understanding is that AWS hasn't officially closed it because of US-Gov accessibility guidelines.<p>Are there any other similar clients?<p>[0]: <a href="https://aws.amazon.com/tools/aws-elasticwolf-client-console/" rel="nofollow">https://aws.amazon.com/tools/aws-elasticwolf-client-console/</a>
This is the specific one I never quite understood:<p>* Order column by X<p>* Type search into input<p>* Column order drops<p>* Can no longer apply ordering when search input is there<p>100% understand that larger companies will not typically, or at least shouldn't, be directly manipulating infra via the web console but there is 1000s of customers that use web for small business. It's a valid customer to think about it!<p>ps I logged into Reddit so to add to that thread. Felt this in my soul.
3 years ago i had some vague hope that things do improve although i am not aware of the bugfixes so i started tracking the bugs as GitHub issues<p>Soon after i gave up. Too many silly bugs, and no fixes.<p>Reference: <a href="https://github.com/andreineculau/fl-aws" rel="nofollow">https://github.com/andreineculau/fl-aws</a>
I use the web console fairly sparingly - iam, billing, browsing around s3 from time to time, etc. It's good enough - way better than it used to be, and better than the firefox extension that I started with.<p>This is probably not a popular way of doing it, but I write python to orchestrate the provisioning steps of a VM with specific roles, routes, etc in a VPC (with public/private subnets in multiple AZs) and then I use other tools for config-management and deploy.<p>I'm using few of AWS's services, it helps me do multi-cloud (another python script doing the same thing on another cloud), and it helps me keep my local dev environments in parity with production even on MacOS.<p>I do use S3 and route53 globally - they're simple enough to use using boto. IMO if infra is now code, you should probably write code to manage infra...
Maybe what the world really needs is a FOSS Framework that implements all the features on a swarm of VPS/Hardware servers? It's really disturbing to see the web reduced to a handful of giant cloud providers who also happen to suck at doing their job
I'm a solo academic researcher user and there's one thing even simpler than this that i can't stand: there is no way to check which EC2 resources are running all at once. You have to click on every single region in turn to see what is actually running. If you've had multiple types running across regions, trying shut everything down without closing the account is a real pain. I am not the only person with this problem: <a href="https://stackoverflow.com/questions/42086712/how-to-see-all-running-amazon-ec2-instances-across-all-regions" rel="nofollow">https://stackoverflow.com/questions/42086712/how-to-see-all-...</a>
People pay for an awful product. What incentive do they have to improve? None. It's not just aws. All Amazon products are this way. Two day shipping comes a week later if it comes at all. Products are cheap knockoffs that break and when you return them they close your account. Aws is aws: you know you're getting ripped off but someone else is paying the bill and aws has convinced them that the service is worth it. It's not but it'll take a week to migrate away to another provider and we can't afford that. Never mind that we're losing an hour each day in productivity. Perception is everything and perception is on their side.
I jokingly say that Amazon should have a couple of sessions at re:Invent where they talk about the things they fixed in Console. I generally find that I no longer mind most AWS UI quirks, but some things are really annoying like the broken Parameter Store search which has been broken for years or CloudWatch search which flat out doesn't work at times.<p>I really believe there is a business opportunity here. I think you could pick a general use-case for AWS, like serverless, and build an intuitive UI around AWS offerings typically utilized by the serverless stack.
Well I am glad I am not the only one who struggles to understand what is going on with AWS. Everyone is all over the place with cryptic howto's. I think I may have even "lost" a running container at some point. Google cloud also seems to be out to confuse people, maybe its a strategy to stop users from escaping :)
I have nothing against the AWS UI. I haven’t used it much, but it has never been a problem to me. It must be increasingly difficult to build an UI for a console like that, there are so many different users, use cases, services and perspectives.
I’ve been working at a company where I have had to fight with the infrastructure team because they see no reason why I would need programmatic cress to do anything on the cli or with the sdk. The reason why. They don’t use it so why would I?
If you think you are in such a strong position that you can keep customers even with the level of inconsistency of the AWS UI, siloed microfrontends might be something to consider. Otherwise it’s probably not such a good idea.
AWS has great APIs and SDKs and most of the time I use AWS services through the command line and not so much though the web interface.<p>Even though AWS web interface has it's flaws, it's still 10 times better than Azure's web UI.
It's been a few days but I'm still trying to figure out how to share access to the billing console with one of my organization's members. It's just baffling in every sense.
The console works, but the real power is in the API. The PowerShell API works extremely well and I write scripts for everything I need to do.<p>On the Python side, "boto" works well, too.