A note on methodology: typically in experimental surveys you don’t want to prime your subjects with words or phrasing that could lead to positive or negative bias.
Additionally, negatively-biased phrasing on a public survey could also attract mostly those with negative views. This would skew your sample even further than solely priming.
With that said, I have no idea what any of those icons are.
I am not a AWS user but I am familiar with what several of the AWS services do. I looked over the quiz and I could not answer even a single question.
I also think the quiz is to prove a point. Those icons are not helpful at all. The opposite of the MS Office icons which are so recognizable all other office suites copied the color scheme.
I'm an AWS user, I've been using their service for almost 5 years now. I also had a hard time with many of their questions. I agree completely with your assessment.
I was happy that they finally added a simple search tool for their tools on their homepage.
It wouldn't be a very sustainable business, but you could make good money selling a chrome extension that cleans up AWS similar to what Reddit Enhancement Suite does.
That might just be the most dangerous extension ever, or at least one that could get very messy very quickly if it was hacked. Or someone would be willing to pay big money to have it subverted, looking at you cryptonuts.
At first I agreed with you but taking the quiz I admit the title didn't really influence how I already felt about AWS icons. At least I remember AWS' service names like Firehose and Kinesis; GCP's are hard to remember when they don't use mnemonic devices for most of their products.
Also, presenting options such as "dried arterial blood red" and "slightly but not too radioactive green" might also make you less likely to put in effort to select the real one, rather than just picking randomly.
I'd agree with you if the point of the survey was to collect information, but I think the structure of the survey makes it pretty clear that this isn't the intent.
Just from my own experience, I have used the overwhelming majority of these services and even worked at Amazon for several years and I could not answer more than a couple of those questions. The icons are so divorced from any real world meaning that when I make systems diagrams in Lucid Charts I use the AWS icons to represent abstract systems rather than the real AWS-specific meaning.
It's still priming the responses. If the interest is in drawing a truly 'scientific' result, the hypothesis/wanted-conclusion shouldn't be in the prompt used on participants.
Sure - either way it's not a "fair" survey. If I were making this survey trying to be scientific and somebody posted it to HN with this title I would be quite upset at them for priming a large number of my participants.
I agree with you about that in a smaller bunch you do recognize the target icon relatively quickly, but they could have just used the color for the text itself :)
Off-topic (and sort of translated):
Salut Virgile, complet de acord cu tine, dar dacă făceau textul colorat în culoarea "service category", viața era mai simplă pentru toată lumea :) (lume mică, domne, uite de cine dai pe net :D)
Lots of vividly-colored text is hard to read and makes a pretty bad interface, too. Also, apparently the whole quiz is kinda' moot - here's how my console looks now: https://imgur.com/n9Ohtri (apparently they moved to "one icon per service category").
Ref offtopic: nu e cinstit, eu sunt usor de recunoscut dupa ID (plus am mailu' in profil). Nu stiu cine esti :)
I have SSO with Okta. It's literally a browser plugin and I select which account to enter, and I'm in. You should definitely look into setting up something like that. It takes away all the pain of logging in.
7/20, and my correct/failed guesses seem uncorrelated with services I've used or ones I never touched. Anecdotal evidence about how arbitrary these icons are.
I don't think they have a 'bad icon' problem as much as a 'too many services' problem. I'm not necessarily saying that they need less functionality, just that they need to divide it up into fewer named/iconed chunks of functionality.
Jetbrains products' icons are OK, but there's clearly a gradual Adobification going on.
Their designers recently declared that colored icons were distracting (?) and are currently moving most of the them to gray. Quite confusing when gray usually means disabled.
Yup. 4/20 made me realize how much I use the new type-ahead feature on the dashboard. Not sure it's even worth using icons with so many services being offered.
Aws feels like it was built by a bunch of siloed teams. There's a lot of design inconsistency I notice every time I'm in the console. For example, deleting entities is never consistent. Some just do it, some ask you to type in the name, some as you to type "delete me".
Some entities have a name and a description field that are immutable on creation, even though they also have a unique id. I now have drop downs everywhere that list "Rds creation wizard VPC" or something long those lines.
Its not clear what fields are drop downs so I have to type stuff into them to see if they'll give me a list of options.
The UI uses the same styles but inconsistent language. In ECS there's a list of entities. To delete an entity you have to go into it and delete all its children. Then the entity disappears.
I know there's engineering reasons for all this, but I feel like they can do better than settle for engineer grade UI.
I feel like AWS’s MO is to eschew things like usability and consistency in favor of getting features out as quickly as possible. Perhaps it doesn’t have to be an either/or, but as an observer from outside the org, it’s hard to know
At the beginning they only had a page about the pricing and it looked as if they intentionally made it very technical-minded so as to make it only accessible to experts. Which would have been a good thing, to avoid too much support load from the endless wordpress beginner crowd.
Hah. Guess it depends on what siloed means. With a certain size you need to figure out ways of aligning/comunnicating things - whole AWS is probably thousands of people. You will get siloes.
On top of that: it’s not like all services were build at the same time. Some of them are the “bedrock” of Aws (S3, EC2), some of them are experiments that went viral.
On top of that: Aws is meant to give you building blocks. The magic happens at API/sdk level. The console is there to help you discover and play with the service in a few basic scenarios (and to maybe observer your resources). If you click your way through settings things up you’re going to probably have a bad time.
AWS was built by a bunch of siloed teams. In the mid 2000's there was a mandate for each separate infrastructure team to open their infrastructure as a service, and they were given tight deadlines. This was meant to solve internal issues but was opened up to the world and AWS was born.
Yes, there was a mandate for everything to be SOA. However, AWS built almost every service from scratch. For example, S3 and EC2 were NOT used for production in Amazon until well after launch (it was a huge migration when the company did it years later).
My team built a world class transcoding service for video and were surprised to find later that AWS had built it's own (much less good) transcoding service. As part of that we also built a 5-10x optimization to multi-part fully-encrypted S3 uploads with a user-friendly client and the response from the S3 team was a shrug, they just weren't interested.
It is actually really common at Amazon for five teams to be building almost the same thing. Some of it is on purpose as a sort of insurance policy or bake-off.
But almost every AWS service was built in the AWS org, even if there was something similar in place at Amazon, at least when I was there (2006-2015).
> Yes, there was a mandate for everything to be SOA. However, AWS built almost every service from scratch.
I think it's more true than false though; tldr: there was effectively a super-fugly internal set of services that were the prototype for many of the real AWS services.
Some of the computing capacity AWS itself used was built on the internal services that Amazon had been using. Provisioning capacity on those internal services required weeks as the API was very primitive compared to EC2. I think also it wasn't until VPC became quite stable that they could start to move Amazon to AWS.
So for a long time, you essentially had AWS service teams having to file paperwork for capacity (decommissioning capacity could sit in a queue for months just like in a regular data center) while AWS customers could spin up capacity via EC2. As you can imagine, AWS would build on AWS, and then they promptly ran into problems when they had to stand up new regions because they had dependency cycles... There was also a ton of tooling built around requesting all the capacity and dependencies, and maintaining the configuration for all that.
So the SOA story is really that there were a bunch of AWS-like services that were absolutely awful, and those were often the prototypes for the AWS services themselves. And many services like Lambda are now possible because they've been solving all the obscure security issues and dependency problems associated with having AWS be their own customer.
For instance, the genesis of one service was that a large customer was using EC2 and had some specialized hardware; they were big enough they said, "hey, we'd like to move this hardware out of our datacenters" and AWS stood up an incredibly primitive service that literally routed some specialized racks into this customer's VPCs. There was no API, you'd email the service team and they'd run some scripts. That's gradually morphed into a real service that's unrecognizable from the early days.
This is true. Each team owns their service end-to-end. It just happens that the console is usually an afterthought. Something to be left for the interns to work on.
The funny thing is, some of the AWS services are indeed quite primitive compared to their Amazon internal equivalent.
Yes, Cloudformation is my main tool too. I just simplified my comment. Read it as managed by code, be it CF, python, awscli from shell, and all of it in the end boils down to specific API calls.
For instance we have a process that sends sns messages for alerts. It’s just as easy to go into the console and subscribe to the sns event notifications (emails and sms).
Second example. I initially configure passwords with CF (of course with parameters that are added when you run it.) It’s easier to go into the console afterwards to change passwords as it would be to update the stack and renter the passwords.
You aren’t going to store passwords in source control anyway.
For SNS I'd use the API just to make sure every new team member gets signed up for every appropriate deployment (test, prod, whatever) and every old team member gets removed.
I agree it doesn't add much value for a single user rotating their own password.
The console is absolutely indispensable. You need it for your majority of aws users who are doing it for the first or second time. You need it for quick lookups, prototyping, experimentation.
Then when you have the Lego design you want, yes, you whip out cloudformation or bash scripts or Python scripts or ansible or whatever else.
I was astonished to learn that you can sort of scrape your from-console resources into a CloudFormation template, but you cannot get a stack to manage them inplace. Instead you have to blow them away (manually!) and have CloudFormation create a new stack from scratch, because it only touches stuff it created with hidden stack tags.
Terraform import is pretty painful but at least it can handle this.
I've been to two AWS Summits (Stockholm) and most if not all AWS employees explicitly point out that you should never use the console for anything serious. It might be good for presentations, but it's horrible when you need to manage infrastructure.
Not every service has an API, especially new ones. They tend to launch things console first. Look at Alexa. It took over a year to get API, and it still doesn't have CloudFormation support.
That's not accurate. There are some things you cannot even do in the API and it must be done in the console. I agree with others here that you should be using Cloudformation as much as possible, but even that isn't 100% supported and sometimes you need to click around the console to set things up.
You can still have siloed teams, and I think you need them in this case. AWS has many different products and they don't all relate to each other. It sounds like they simply need to adopt some UX/style guides and enforce them across the company.
In general, I would not expect questions around expect people to remember details about a logo just from a name to work very well. People in general can't do that even with extremely famous logos: https://www.signs.com/branded-in-memory/ Nor can they generally even draw a bike, with physical necessity available to guide them: http://www.gianlucagimini.it/prototypes/velocipedia.html
However, it is absolutely a reasonable request of a logo that you be able to go from logo to designated product, and while quizzing about details like "which horizontal pole is higher" is definitely a bit of an ask, you should still see a lot of people getting that right from just "feeling" which seems right.
I agree with both parts of this. My biggest frustration is that even after I looked at the answers, I couldn't explain many of the logos.
There's a clear attempt to create logical connections: 'directory' manages to evoke a bunch of cards in a file, EMR is a solid reduce block above a bunch of map blocks, and so on. The MediaFoo family is actually quite good - I swapped Package and Store, but otherwise got them all right despite never using the service. The family color scheming is genuinely very good, despite the weird outliers like grey.
But then there's all the rest. Kinesis and Cloudwatch are each a bar graph with a base, but Kinesis is rotated, and has 2 layers of floating base instead of 1 joined layer, so that totally clears things up. (And Athena is 1 layer floating base, with bars going both directions, to help confuse the existing two.)
ELBs and ECS are both multiple full-size layers on the left with a 4-rectangle split layer on the right, but ELB is 3 filled layers and a flat split layer. ECS is hollow layers and a 'long' split layer. Memorable!
Database Migration Service is a mix of Direct Connect and RDS theming, which actually makes sense, but also Elasticache is a disjoint version of Direct Connect in database coloring?
(I had a hell of a time looking these up to check, because about half the guides on Google Images are simply wrong about some services. Check out Elastic IP, which is listed with the icons of 3 other services!)
I work with AWS every day, and I just realized that even though all the symbols have a consistent look, the style is so generic I don't mentally associate it with AWS. To me it looks like symbols from a design diagram where somebody was in a hurry and picked random symbols from their drawing program's image library.
That's the route JetBrains went as well and while I wasn't happy with it when they initially started doing it, I have grown to greatly appreciate knowing which icon represents which product at a quick glance.
Works fine, but it does make it harder to pick an icon at a glance since you need to spend those 200ms thinking about what the abbreviation means or what abbreviation you're looking for.
Adobe made a really gutsy move IMO. Some of their products had very memorable icons, which they chose to ditch in favor of the fully unified look. Ultimately I think it was a good one - Amazon’s current struggle to properly iconify their dozens of abstract services illustrates this perfectly.
I actually would be curious now to see how a company like Apple might approach the problem. Apple’s well-known icons are largely focused on popular apps, which have very distinct and concrete functions. I wonder if there really is a clear and unambiguous icon for something esoteric like a NoSQL database store - I suspect that there isn’t, largely because (unlike apps) it just isn’t something that is in the public eye.
Icons are the least of AWS's UX problems. The AWS console is godawful. It should be a case study in terrible design. I hate every second I spend on it.
Route 53 looks like it was designed by the Marquis de Sade. Not only was it designed by a sadist, it looks like it was designed last century.
They’d be better off putting up a text file because then at least the IT guys would already know how to use it. And making changes would be a hell of a lot faster too.
Very entertaining and bludgeons you over the head with the point of the survey. I got 6/20 and several correct answers were lucky guesses. I only really recognized EC2, Lambda, and VPC. That doesn't mean the icons actually convey what those are to me though - it's just memory since I use them often.
192 comments
[ 3.0 ms ] story [ 229 ms ] threadAdditionally, negatively-biased phrasing on a public survey could also attract mostly those with negative views. This would skew your sample even further than solely priming.
With that said, I have no idea what any of those icons are.
I also think the quiz is to prove a point. Those icons are not helpful at all. The opposite of the MS Office icons which are so recognizable all other office suites copied the color scheme.
Amazon badly needs some serious UX power...
It wouldn't be a very sustainable business, but you could make good money selling a chrome extension that cleans up AWS similar to what Reddit Enhancement Suite does.
Also, presenting options such as "dried arterial blood red" and "slightly but not too radioactive green" might also make you less likely to put in effort to select the real one, rather than just picking randomly.
Admittedly, I can't use them to identify any specific services, but they're cool looking.
Just from my own experience, I have used the overwhelming majority of these services and even worked at Amazon for several years and I could not answer more than a couple of those questions. The icons are so divorced from any real world meaning that when I make systems diagrams in Lucid Charts I use the AWS icons to represent abstract systems rather than the real AWS-specific meaning.
Also, the logos are color-coded by "service category" if I'm not wrong
Off-topic (and sort of translated):
Salut Virgile, complet de acord cu tine, dar dacă făceau textul colorat în culoarea "service category", viața era mai simplă pentru toată lumea :) (lume mică, domne, uite de cine dai pe net :D)
Ref offtopic: nu e cinstit, eu sunt usor de recunoscut dupa ID (plus am mailu' in profil). Nu stiu cine esti :)
Which is good, otherwise ECS Fargate wouldn't have made a lot of sense.
[1] https://aws.amazon.com/ecs/
Their designers recently declared that colored icons were distracting (?) and are currently moving most of the them to gray. Quite confusing when gray usually means disabled.
Some entities have a name and a description field that are immutable on creation, even though they also have a unique id. I now have drop downs everywhere that list "Rds creation wizard VPC" or something long those lines.
Its not clear what fields are drop downs so I have to type stuff into them to see if they'll give me a list of options.
The UI uses the same styles but inconsistent language. In ECS there's a list of entities. To delete an entity you have to go into it and delete all its children. Then the entity disappears.
I know there's engineering reasons for all this, but I feel like they can do better than settle for engineer grade UI.
On top of that: it’s not like all services were build at the same time. Some of them are the “bedrock” of Aws (S3, EC2), some of them are experiments that went viral.
On top of that: Aws is meant to give you building blocks. The magic happens at API/sdk level. The console is there to help you discover and play with the service in a few basic scenarios (and to maybe observer your resources). If you click your way through settings things up you’re going to probably have a bad time.
Yes, there was a mandate for everything to be SOA. However, AWS built almost every service from scratch. For example, S3 and EC2 were NOT used for production in Amazon until well after launch (it was a huge migration when the company did it years later).
My team built a world class transcoding service for video and were surprised to find later that AWS had built it's own (much less good) transcoding service. As part of that we also built a 5-10x optimization to multi-part fully-encrypted S3 uploads with a user-friendly client and the response from the S3 team was a shrug, they just weren't interested.
It is actually really common at Amazon for five teams to be building almost the same thing. Some of it is on purpose as a sort of insurance policy or bake-off.
But almost every AWS service was built in the AWS org, even if there was something similar in place at Amazon, at least when I was there (2006-2015).
I think it's more true than false though; tldr: there was effectively a super-fugly internal set of services that were the prototype for many of the real AWS services.
Some of the computing capacity AWS itself used was built on the internal services that Amazon had been using. Provisioning capacity on those internal services required weeks as the API was very primitive compared to EC2. I think also it wasn't until VPC became quite stable that they could start to move Amazon to AWS.
So for a long time, you essentially had AWS service teams having to file paperwork for capacity (decommissioning capacity could sit in a queue for months just like in a regular data center) while AWS customers could spin up capacity via EC2. As you can imagine, AWS would build on AWS, and then they promptly ran into problems when they had to stand up new regions because they had dependency cycles... There was also a ton of tooling built around requesting all the capacity and dependencies, and maintaining the configuration for all that.
So the SOA story is really that there were a bunch of AWS-like services that were absolutely awful, and those were often the prototypes for the AWS services themselves. And many services like Lambda are now possible because they've been solving all the obscure security issues and dependency problems associated with having AWS be their own customer.
For instance, the genesis of one service was that a large customer was using EC2 and had some specialized hardware; they were big enough they said, "hey, we'd like to move this hardware out of our datacenters" and AWS stood up an incredibly primitive service that literally routed some specialized racks into this customer's VPCs. There was no API, you'd email the service team and they'd run some scripts. That's gradually morphed into a real service that's unrecognizable from the early days.
The funny thing is, some of the AWS services are indeed quite primitive compared to their Amazon internal equivalent.
I don’t think I’ve ever used the CLI to manage infrastructure on AWS.
I usually use the console for one offs. When something needs to be repeatable, I’ll create a Cloud Formation template.
Anything that’s more conplicated, I’ll either use Python directly or create a custom resource that gets called from CF.
For instance we have a process that sends sns messages for alerts. It’s just as easy to go into the console and subscribe to the sns event notifications (emails and sms).
Second example. I initially configure passwords with CF (of course with parameters that are added when you run it.) It’s easier to go into the console afterwards to change passwords as it would be to update the stack and renter the passwords.
You aren’t going to store passwords in source control anyway.
I agree it doesn't add much value for a single user rotating their own password.
Then when you have the Lego design you want, yes, you whip out cloudformation or bash scripts or Python scripts or ansible or whatever else.
Terraform import is pretty painful but at least it can handle this.
[1]: https://aws.amazon.com/inspector/
However, it is absolutely a reasonable request of a logo that you be able to go from logo to designated product, and while quizzing about details like "which horizontal pole is higher" is definitely a bit of an ask, you should still see a lot of people getting that right from just "feeling" which seems right.
There's a clear attempt to create logical connections: 'directory' manages to evoke a bunch of cards in a file, EMR is a solid reduce block above a bunch of map blocks, and so on. The MediaFoo family is actually quite good - I swapped Package and Store, but otherwise got them all right despite never using the service. The family color scheming is genuinely very good, despite the weird outliers like grey.
But then there's all the rest. Kinesis and Cloudwatch are each a bar graph with a base, but Kinesis is rotated, and has 2 layers of floating base instead of 1 joined layer, so that totally clears things up. (And Athena is 1 layer floating base, with bars going both directions, to help confuse the existing two.)
ELBs and ECS are both multiple full-size layers on the left with a 4-rectangle split layer on the right, but ELB is 3 filled layers and a flat split layer. ECS is hollow layers and a 'long' split layer. Memorable!
Database Migration Service is a mix of Direct Connect and RDS theming, which actually makes sense, but also Elasticache is a disjoint version of Direct Connect in database coloring?
(I had a hell of a time looking these up to check, because about half the guides on Google Images are simply wrong about some services. Check out Elastic IP, which is listed with the icons of 3 other services!)
https://www.expeditedssl.com/aws-in-plain-english.
Just hover over the products menu at the top: https://aws.amazon.com/
https://i.imgur.com/e4BJrne.png
https://i.imgur.com/wSqVMp4.png
Same way with color coded money in most non-US countries, you just pick a note based on color.
I actually would be curious now to see how a company like Apple might approach the problem. Apple’s well-known icons are largely focused on popular apps, which have very distinct and concrete functions. I wonder if there really is a clear and unambiguous icon for something esoteric like a NoSQL database store - I suspect that there isn’t, largely because (unlike apps) it just isn’t something that is in the public eye.
Indeed. It's hard to make changes like that since it often results in existing users getting pissed off. Even if it's for the better in the long run.
those are some garbage icons.
They’d be better off putting up a text file because then at least the IT guys would already know how to use it. And making changes would be a hell of a lot faster too.