AWS icon quiz(docs.google.com)
docs.google.com
AWS icon quiz
https://docs.google.com/forms/d/e/1FAIpQLSdnEEo0o2JgnIt8VOGffhkcYj-C2h9m5_NFzM0Q1AU-P8d0zA/viewform
192 コメント
I agree with both points.
I think the whole quiz is a joke, to prove a point.
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 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.
Amazon badly needs some serious UX power...
Amazon badly needs some serious UX power...
They've been tweaking the UI of the AWS console recently at least, but, they still have a loooong way to go.
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.
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.
If the icons were good, the quiz wouldn't need to exist, right? So the mere fact that there is a quiz already biases the result.
Even if the title was "AWS icons are awesome" my results would have been the same
But you might not have taken it, then.
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.
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 am terrible with colors but I thought "slightly but not too radioactive green" was a perfect description.
Well, I for one, think the icons ARE AWESOME.
Admittedly, I can't use them to identify any specific services, but they're cool looking.
Admittedly, I can't use them to identify any specific services, but they're cool looking.
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.
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.
The quiz is called AWS Icon Quiz. "AWS has terrible icons" is only the title of the Hacker News post.
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.
I think the point was that the fault may lie in the poster on HN and not the author of the survey, provided they're separate individuals.
The questions and candidate answers themselves are also heavily biased. The survey is clearly not intended to be an unbiased scientific poll.
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.
Dammit dwolb you missed the point!
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.
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.
Console is just for checking stuff. Real infra is managed by APIs.
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.
The “No True AWS Guru” ( https://en.wikipedia.org/wiki/No_true_Scotsman) argument...
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.
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.
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.
The key thing is a repeatable process that's checked in, which pointing and clicking in the console is not.
Not always.
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 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.
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.
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.
Terraform import is pretty painful but at least it can handle this.
For some. For others it’s indispensable. “You should be smarter” isn’t something I’m prepared to tell newcomers to AWS.
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.
Right. And "here's a thing we make available to you but it's horrible and you should never use it" is terrible messaging.
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.
I don’t think Alexa is considered an AWS product/service. While you need AWS’ Lambda to make it work, Alexa is an Amazon (versus AWS) product.
Ok, fair point, but you can see the same pattern with other services. Look at any of the AI services for example. Everything was console first.
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.
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.
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.
This is a bit of a myth.
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. 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.
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.
The funny thing is, some of the AWS services are indeed quite primitive compared to their Amazon internal equivalent.
To state the obvious, you really should not be using that console to do anything. Basically browsing the console is already technical debt.
Truth!
Names and Icons on AWS were made by people who don’t realize who helpful names and icons can be.
If it’s a database, use the cylinder icon that everyone knows is a database and then add some identifier to show which database it is.
If it’s DNS, don’t be too clever and name it Route 53. Name it Amazon Cloud DNS. Then anyone knows how to look for it in the console, web search for it, etc.
If you want something that the marketing folks can feel proud about wasting time on, add the silly name to the descriptive name: Amazon DNS Potato
Names and Icons on AWS were made by people who don’t realize who helpful names and icons can be.
If it’s a database, use the cylinder icon that everyone knows is a database and then add some identifier to show which database it is.
If it’s DNS, don’t be too clever and name it Route 53. Name it Amazon Cloud DNS. Then anyone knows how to look for it in the console, web search for it, etc.
If you want something that the marketing folks can feel proud about wasting time on, add the silly name to the descriptive name: Amazon DNS Potato
what about calling the database app "database"
There isn't just one database app. They have Aurora, DynamoDB, ElastiCache, Neptune, RDS, and Redshift.
"fast sql database," "fast nosql database," "redis cache nosql database," "graph database," "rds (is actually named right lol)," "big analytics SQL database."
As a longtime supporter of Remote Desktop Service in Windows, seeing AWS RDS took a while to get used to.
They could have named WorkSpace as Remote Desktop Service, which it is. Instead, many of my co-workers think AWS means only Amazon WorkSpace.
They could have named WorkSpace as Remote Desktop Service, which it is. Instead, many of my co-workers think AWS means only Amazon WorkSpace.
Amazon Relational Database
Amazon Keystore
Amazon Warehouse Database
Amazon Analytics Database
I agree these would be much more descriptive.
I agree these would be much more descriptive.
RDS doesn't scream DB at me.
It could have been AuroraDB, DynamoDB, NeptuneDB, RDBS, and RedshiftDB. At least people would be able to tell that all of those are databases.
Case in point, Aurora is a type of database within RDS. RDS and Aurora are not separate database apps.
They list it as a separate product and they have slightly different logos. https://aws.amazon.com/products/databases/
There are multiple database apps, but yes they could have been a bit more generic.
which database app?
I've probably spent at least 3 hours collectively trying to find the DNS only to find/remember it is called Route 53. I rarely use it outside of initial setup and trying to recall the name of it each time is maddening.
And why "Amazon" EC2 but "AWS" Lambda? It throws me off every time I look at an alphabetically sorted list of the services. Granted, Microsoft slaps "Azure" in front of some of their services, but Amazon seems to optimise for having "AWS" and "Amazon" mentioned together as many times as possible, as if we need to be reminded.
`Amazon` named services are core building blocks (e.g. ec2 is just servers). `AWS` are services built on top of the `Amazon` services (e.g. Lambda runs on their EC2 machines, Batch runs on EC2 machines). usually
“Some exceptions may apply.”
I don't believe that's the reasoning; and although I worked at AWS in the past I don't know for sure what's the reasoning behind choosing "Amazon" or "AWS" prefix for a service name.
For example, RDS is definitely a service built on top of other core services (EC2, S3, KMS, Route 53), its name is "Amazon RDS" and not "AWS RDS".
For example, RDS is definitely a service built on top of other core services (EC2, S3, KMS, Route 53), its name is "Amazon RDS" and not "AWS RDS".
i before e except when you run a feisty heist on a weird beige foreign neighbor
Glacier and Snowball were both the internal code names for the products pre-launch, and only ever intended to be such.
When things came close to launch, AWS Marketing decided to just roll with those code names. I've a suspicion that some teams deliberately used copyrighted names for their internal pre-launch project names, just to force the matter.
When things came close to launch, AWS Marketing decided to just roll with those code names. I've a suspicion that some teams deliberately used copyrighted names for their internal pre-launch project names, just to force the matter.
But then they would have to take the marketing questions out of their associate level certification exams.
1. Which service would you use for DNS record creation?
A) Route 53
b) Amazon Cloud DNS
I joke, its an extremely low quality question regardless of the name. Some of the questions on the exam were pretty insightful, especially the ones that covered problems and what steps you would take to resolve them. Overall, the AWS associate level certification did feel like a giant marketing ploy, but my company wanted me to have it and paid for me to study and take it, so it was a nice relaxing break from the day-to-day.
1. Which service would you use for DNS record creation?
A) Route 53
b) Amazon Cloud DNS
I joke, its an extremely low quality question regardless of the name. Some of the questions on the exam were pretty insightful, especially the ones that covered problems and what steps you would take to resolve them. Overall, the AWS associate level certification did feel like a giant marketing ploy, but my company wanted me to have it and paid for me to study and take it, so it was a nice relaxing break from the day-to-day.
> If it’s DNS, don’t be too clever and name it Route 53. Name it Amazon Cloud DNS. Then anyone knows how to look for it in the console, web search for it, etc.
Please no. The unique AWS product names while occasionally inconvenient mean that you can at least find relevant information about them when searching, and you know that someone isn't confusing an AWS product with another platform or another style of deployment.
If you really don't like the AWS product names, then Azure is for you. Now go try to search for help with "Azure web apps" or "Azure sql database". Wade through the posts about locally deployed IIS, SQL server and the like.
Please no. The unique AWS product names while occasionally inconvenient mean that you can at least find relevant information about them when searching, and you know that someone isn't confusing an AWS product with another platform or another style of deployment.
If you really don't like the AWS product names, then Azure is for you. Now go try to search for help with "Azure web apps" or "Azure sql database". Wade through the posts about locally deployed IIS, SQL server and the like.
I have no problem finding documentation for google cloud which has a similar naming scheme.
I don’t use a search engine though because they have made a good documentation site.
Adding a small identifier (as I suggested, even though jokingly) solves your problem as it’s easy to index:
Azure Cloud SQL Photon
That’s easy to understand it’s a Database and easy to search
I don’t use a search engine though because they have made a good documentation site.
Adding a small identifier (as I suggested, even though jokingly) solves your problem as it’s easy to index:
Azure Cloud SQL Photon
That’s easy to understand it’s a Database and easy to search
What would be even easier to search is to use things that aren’t common words like:
Azure Cloud SQL R364T11
That’s hard to remember but likely narrows the search content drastically
Azure Cloud SQL R364T11
That’s hard to remember but likely narrows the search content drastically
[deleted]
It definitely has “Potato Quality” moments.
It’s not jus the icons. It’s the names too since a lot of them are completely unrelated to the product itself.
I actually find myself referring to “Amazon Web Services in Plain English” [0] every once in a while.
[0]: https://www.expeditedssl.com/aws-in-plain-english
I actually find myself referring to “Amazon Web Services in Plain English” [0] every once in a while.
[0]: https://www.expeditedssl.com/aws-in-plain-english
Seconded. This link was huge to me when learning AWS products.
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.
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!)
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!)
AWS do put a lot of work into their icons set. That said, we (draw.io) get a lot of direct complains about the icons because:
1) They can't find certain AWS icons (the problem is it's there, they didn't expect it to look like that).
2) They change and move between sets rather a lot. That was more a problem previously, the set hasn't actually changed yet this year.
If there's a designer out there willing to create an alternative set, we're more than willing to add it in and see what people prefer. Probably more constructive than just saying "they are bad", show us something better.
1) They can't find certain AWS icons (the problem is it's there, they didn't expect it to look like that).
2) They change and move between sets rather a lot. That was more a problem previously, the set hasn't actually changed yet this year.
If there's a designer out there willing to create an alternative set, we're more than willing to add it in and see what people prefer. Probably more constructive than just saying "they are bad", show us something better.
sleepybrett(1)
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 probably isn't too far off from how they were picked
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.
I feel like Adobe has a similar problem but handle it much better.
And similarly, Jetbrains. Having the product intitials in the icon is incredibly helpful.
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.
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.
Oh, let's not confuse the product icons with the in-app icons. I can't believe they're taking color away. It's just stupid.
They do have many services, but 95% of their icons, including the early ones, make no sense at all.
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.
I'm not sure where one goes in the AWS web interface to view these icons. Poking around the EC2 menus for a while, I don't see an icon anywhere.
I wouldn't say the icons are _good_, but I wonder if part of the reason the quiz is so hard is that Amazon doesn't really care if you know what the icons mean anyway. Seems like they're mostly used for branding and marketing, not anything users will see regularly.
I wouldn't say the icons are _good_, but I wonder if part of the reason the quiz is so hard is that Amazon doesn't really care if you know what the icons mean anyway. Seems like they're mostly used for branding and marketing, not anything users will see regularly.
If you click the pushpin icon in the web interface, you'll get a dropdown with the services and their icons. You can drag icons into your top bar as shortcuts.
To me, the icons are far too abstract to mean anything. They all look like the results of someone playing around randomly in a 3D modeling tool. For example, look at the CloudFront icon. I'd expect something more evocative of clouds or similar, but it's just a cube that's been cut and exploded with the rear two subcubes removed.
That said, they're probably extremely easy to generate procedurally:
http://iquilezles.org/www/articles/distfunctions/distfunctio...
That said, they're probably extremely easy to generate procedurally:
http://iquilezles.org/www/articles/distfunctions/distfunctio...
There's a famous story about early UI fail in some CAD software.
Icons had just come into vogue (yes, there was a time before icons). The CAD system in question used a puck on a big mat to choose functions from a grid of names, which were labels like GRAPH and CONNECT and DEL and so forth. But all-caps names weren't very sexy, so the company decided to replace them with more intuitive icons, cool little pictures of the operations. Getting rid of the tiresome and uncool simple text labels was going to win back market share!
Predictably, users complained that they had a hell of a time trying to figure out which of the tiny, intuitive pictures corresponded to the concrete operations.
The company's response? Supply users with a printed cheat sheet that let them find the icon for each operation. To do a CONNECT, you'd look at the cheat sheet and find the corresponding essentially arbitrary (but intuitive!) squiggle, then search for the intuitive squiggle in a sea of other intuitive squiggles. ("No, not that one!")
Icons had just come into vogue (yes, there was a time before icons). The CAD system in question used a puck on a big mat to choose functions from a grid of names, which were labels like GRAPH and CONNECT and DEL and so forth. But all-caps names weren't very sexy, so the company decided to replace them with more intuitive icons, cool little pictures of the operations. Getting rid of the tiresome and uncool simple text labels was going to win back market share!
Predictably, users complained that they had a hell of a time trying to figure out which of the tiny, intuitive pictures corresponded to the concrete operations.
The company's response? Supply users with a printed cheat sheet that let them find the icon for each operation. To do a CONNECT, you'd look at the cheat sheet and find the corresponding essentially arbitrary (but intuitive!) squiggle, then search for the intuitive squiggle in a sea of other intuitive squiggles. ("No, not that one!")
Where is the "no fucking clue" choice for each? I only use S3 for personal archive and I forget what its icon looks like.
They must have the nicest automatic 3D icon generator out there....
I've always imagined it is like Skyrim character generation and they just hit the randomize button until something "cool and modern-looking" generates
I use AWS every day and got 17/20. Thanks to a couple of lucky guesses.
But, I believe that at least two of the questions have incorrect/incomplete answers:
One of the questions that requires a typed answer (instead of multiple choice) shows an icon that is used for both EC2 & Appstream. However, only EC2 is considered correct.
In the Route53 icon question - there are multiple versions of the Route53 icon used in different places (do a google image search and you'll see a dozen variant). The icon in the top left ("Pole with two offset rectangles") is used in the console - but this is considered an incorrect answer. The icon in the top right ("Pole with two slightly less offset rectangles") is sometimes used elsewhere and is the only answer considered correct.
But, I believe that at least two of the questions have incorrect/incomplete answers:
One of the questions that requires a typed answer (instead of multiple choice) shows an icon that is used for both EC2 & Appstream. However, only EC2 is considered correct.
In the Route53 icon question - there are multiple versions of the Route53 icon used in different places (do a google image search and you'll see a dozen variant). The icon in the top left ("Pole with two offset rectangles") is used in the console - but this is considered an incorrect answer. The icon in the top right ("Pole with two slightly less offset rectangles") is sometimes used elsewhere and is the only answer considered correct.
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.
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.
I think the icons actually are cool and futuristic but there are so many of them an average person cannot realistically keep track of them all. I can only assume they're for marketing purposes to show in slide decks or websites.
I also wonder if they painted themselves into a corner early on by having them for their early services. I guess they're a big-boy company and have stopped doing this earlier but who knows.
I also wonder if they painted themselves into a corner early on by having them for their early services. I guess they're a big-boy company and have stopped doing this earlier but who knows.
SPOILER: AWS inspector has a magnifying glass icon[1], but the correct answer in the quiz is incorrectly marked as "some boxes"
[1]: https://aws.amazon.com/inspector/
[1]: https://aws.amazon.com/inspector/
If you go to AWS inspector in the AWS web console then you'll see why they chose "some boxes" as the right answer.
For those that want to see
https://imgur.com/a/OuNiT2O
Wow ok, that’s just egregious. Using two different icons for the same product/service?
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 think AWS icons are great and I vastly prefer them over Google Cloud’s icons.
Every icon in Google Cloud is a nearly-identical blue hexagon. They might as well not even have icons.
Every icon in Google Cloud is a nearly-identical blue hexagon. They might as well not even have icons.
17/20 But I'm in AWS all day every day. I also question a one or two that I missed :)
People suggesting that they follow Adobe's lead. That's all well and good, until you release like 1000 products a year. You tend to run out of two letter combos for your icons.
People suggesting that they follow Adobe's lead. That's all well and good, until you release like 1000 products a year. You tend to run out of two letter combos for your icons.
Speaking of AWS, shouldn't they also hold a poll on naming? I've seen some saner alternatives in the wild:
https://www.expeditedssl.com/aws-in-plain-english.
https://www.expeditedssl.com/aws-in-plain-english.
A lot of those names are actually pretty sensible, but who thought "Amazon Unlimited FTP Server" was a good alternative to S3?
Since there seems to be a lot of negative sentiment here about the icons, I'd like to offer a different perspective.
While using AWS services and leading huge migration projects, I've never thought to myself: "These icons are terrible and slowing down my progress". As in to say, sure the UX icons are a little wonky, but at the end of the day, do are they really impacting people from getting the value out of the services and using them quickly? Maybe Amazon is partaking in what is often sentiment around here: not optimizing things too soon.
Summary: while icons might be confusing and not great, I find zero impact in me architecting systems and communicating designs.
While using AWS services and leading huge migration projects, I've never thought to myself: "These icons are terrible and slowing down my progress". As in to say, sure the UX icons are a little wonky, but at the end of the day, do are they really impacting people from getting the value out of the services and using them quickly? Maybe Amazon is partaking in what is often sentiment around here: not optimizing things too soon.
Summary: while icons might be confusing and not great, I find zero impact in me architecting systems and communicating designs.
In most cases, the icons are more closely related to the service than the names are, even if they are pretty abstract. Aurora? Fargate? Kinesis? Snowmobile? Sumerian? Obelisk? Gravelbean?
(Ok, I made the last two up, but I bet you would've had to look ...)
(Ok, I made the last two up, but I bet you would've had to look ...)
I couldn't even name 10% of the AWS services themselves.
Just hover over the products menu at the top: https://aws.amazon.com/
Just hover over the products menu at the top: https://aws.amazon.com/
I do not think it is plausible that, for most complex abstract things, there must be an icon that intuitively represents it. The most you can hope for is that the icons are sufficiently distinctive and memorable that a frequent user would come to recognize them without confusing one for another.
I am more bothered by names that do not give you any clue as to what they are about, though there is also a limit to the amount of information you can put in a name.
I am more bothered by names that do not give you any clue as to what they are about, though there is also a limit to the amount of information you can put in a name.
The author of the survey should have allowed "don't know" as an answer. I didn't finish the survey because I didn't want to choose responses I knew probably weren't the right ones. If there are others like me who refrained for this reason, this will skew the results.
(The main point of the survey came across very well, though.)
(The main point of the survey came across very well, though.)
The worst part of the AWS UX is the login page. I regurarly have problems logging in with my accounts
I hop between several accounts daily and its a cumbersome process.
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. i have never used aws. most of my points were from the matching section.
those are some garbage icons.
those are some garbage icons.
This is only tangentially related but it seems that many of the shapes are built in some sort of 3d program and then exported to svg. If you inspect the official released svgs you can see tons of artifacts in most of the shapes[1]. You would think that Amazon would have the resources to release very optimized icons for its public facing documentation.
[1] https://preview.ibb.co/dd86RK/aws_dms_inspected.png
[1] https://preview.ibb.co/dd86RK/aws_dms_inspected.png
This reminds me of those children's puzzles on diner mats to "spot the difference". You either see it immediately or stare at it for 5-minutes with no results.
I just started using AWS a few months ago, professionally, had a couple hobby projects before that.
I don't think I could answer any of those questions. I actually gave up because it started to feel ridiculous, like I was just looking at random geometric shapes.
But my point is that I still use AWS and I find what I need without ever having seen those icons or remembered them. The console remembers my most used tools so usually I find them in that shortcut menu.
I don't think I could answer any of those questions. I actually gave up because it started to feel ridiculous, like I was just looking at random geometric shapes.
But my point is that I still use AWS and I find what I need without ever having seen those icons or remembered them. The console remembers my most used tools so usually I find them in that shortcut menu.
I mean, is there anywhere in the console where you select/identify a service by its icon alone, without the name next to it? I don't remember any such place.
If not... who cares? They're not branded consumer products that need recognition, just a bunch of services and it's not like I'd have any even remotely good ideas for most of these jargony things anyways... :P
If not... who cares? They're not branded consumer products that need recognition, just a bunch of services and it's not like I'd have any even remotely good ideas for most of these jargony things anyways... :P
Im always typing the name in search because its the fastest way for me ; _ ;
5/20
Working without any issues with aws daily.
5/20
Working without any issues with aws daily.
You can configure the top bar in the AWS console to show icons only, but that would be madness. (I usually do the opposite and have it show no icons and only text.)
[deleted]
I thought this was going to be about the infamous AWS Service Health Dashboard[1] icons.
Would be cool to do a similar quiz describing different failure modes of various services and having the user select which icon should be showing.
This is great though!
[1] https://status.aws.amazon.com
Would be cool to do a similar quiz describing different failure modes of various services and having the user select which icon should be showing.
This is great though!
[1] https://status.aws.amazon.com
In Amazon's defense, there's a lack of design consistency from Google and Microsoft as well:
https://landscape.cncf.io/grouping=organization&organization...
https://landscape.cncf.io/grouping=organization&organization...
[deleted]
Amazon, like many enterprise tech companies treat UX designers as second-rate citizens. One of the best UX designer I know left Amazon to work at a startup because he was tired of Amazon's policy of assigning UX designers to work under engineering managers.
I've always had issues telling the icons apart, but in fairness the recent UI updates have already been phasing out the icons. They're no longer on the management console home page, and they've been replaced with much improved category icons.
I got 3 right, even though I currently have the AWS console open and was checking every now and then.
The services don't even have consistent icons displayed between them, I tend to think the icons are actually completely meaningless.
Sorry if you worked on these icons I guess.
The services don't even have consistent icons displayed between them, I tend to think the icons are actually completely meaningless.
Sorry if you worked on these icons I guess.
4/20 not bad !
As a survey design principle, there should be an option for "I don't know"
This makes an excellent point, but is a bit out of date, as AWS have already revamped the user interface.
They got rid of the myriad of abstract icons, and now use a smaller set of recognisable icons, with related services grouped under the same icon.
They got rid of the myriad of abstract icons, and now use a smaller set of recognisable icons, with related services grouped under the same icon.
Icon are funny, agree, but nobody actually uses them in design diagrams. WONTFIX :)
For those who don't use AWS ...
I use the AWS console all day every day, and I couldn't name a single icon. So my guess is they are just intended to be art icons, nothing purposeful. Or they're too similar to be mnemonic.
I use the AWS console all day every day, and I couldn't name a single icon. So my guess is they are just intended to be art icons, nothing purposeful. Or they're too similar to be mnemonic.
I won't bother taking the survey, I only use a couple of services (EC2, RDS, SES, S3, Cloudfront) and I have no idea what the icons are for any of those services, even if I login on AWS daily.
This is so on point. I can't recognize more than 1 or 2 AWS things by icon. I've always wondered if I was the only one who found it kind of impossible to tell what's what in AWS.
Amazon would never care about this stuff unless someone independently did enough unpaid work on the project proving it they could determine an economic value to changing it... so congrats?
This is amazing and I’m jealous of the idea. Wonderful!
I've been in the AWS ecosystem for a _long_ time and I actually got frustrated and abandoned the quiz. Thought I'd ace this no problem!
Nice one.
Nice one.
> how well do you actually know AWS? How many AWS icons can you correctly identify?
I know this is mostly for fun, but that is a wildly faulty premise.
I know this is mostly for fun, but that is a wildly faulty premise.
Unrelated, I'm looking for a "Save File" icon that doesn't use a floppy disk. Does anybody here have any good ideas?
I've seen icons out in the wild of container-ish shapes (box, etc) with an arrow pointing into the container. Seems to work well enough.
Downwards arrow towards a disk: https://imgur.com/a/dMrixoi
Aren't many of the services in the quiz unrelated, so a user wouldn't have occasion to have seen the icon in context?
I may have heard of map reduce, but I have no idea what EMR is; turns out its map reduce (not sure what the E is for).
For most AWS stuff, "E" stands for "Elastic".
My favourite AWS naming was when E became EC2, as in ECS.
ECS is Elastic Container Service.
Which is good, otherwise ECS Fargate wouldn't have made a lot of sense.
[1] https://aws.amazon.com/ecs/
Which is good, otherwise ECS Fargate wouldn't have made a lot of sense.
[1] https://aws.amazon.com/ecs/
Equally, who can explain what most of the AWS services do in less than 10 words? Therein lies the problem I think.
@elfakyn Please submit a follow of the funniest answers. I imagine you're going to get some jokesters .
I would guess text labels with services' names are supposed to be part of those icons
In that case, what point is there in having a non-descript icon? Just select a nice font and turn the text itself into a logo...
Because, while I might not remember/recognize all their obscure logos, I actually remember/differentiate between the few frequently-used ones.
Also, the logos are color-coded by "service category" if I'm not wrong
Also, the logos are color-coded by "service category" if I'm not wrong
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)
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 :)
Ref offtopic: nu e cinstit, eu sunt usor de recunoscut dupa ID (plus am mailu' in profil). Nu stiu cine esti :)
It is almost like the auto generated gravatar icons.
I didn’t think I’d do great, but amazingly, I got every single question wrong.
I got a solid 3. When using AWS I only look at the colors... Not the symbols.
3/20. It was all wild guess as I didn't recognize any of them.
Looking at those icons makes me physically uncomfortable haha
But excellent platform. Much prefer it that way :)
I think I only made 7/20 from guessing.
[deleted]
Hilarious quiz. Thanks for the laugh
aws icons are just noise to me: totally useless
got 5/20 with the help of google photos search,
They should do an Adobe and put 2/3 letters inside a box, maybe also color coded
https://i.imgur.com/e4BJrne.png
https://i.imgur.com/e4BJrne.png
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.
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.
> Adobe made a really gutsy move IMO.
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.
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.
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.
https://i.imgur.com/wSqVMp4.png
https://i.imgur.com/wSqVMp4.png
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.
Which is why they also have different colors. You just pick the right color.
Same way with color coded money in most non-US countries, you just pick a note based on color.
Same way with color coded money in most non-US countries, you just pick a note based on color.
It has terrible naming too: a lot of services are acronyms, it makes them difficult to understand for outsiders. Microsoft who is traditionally bad at naming too is surprisingly good at it for its Azure services. App Services, DocumentDB (CosmosDB now), DataLake, ... are more easily remembered than cryptic 3 letters acronyms.
>It has terrible naming too: a lot of services are acronyms, it makes them difficult to understand for outsiders.
I almost think this was a deliberate choice. Makes the services sound more important than what they are. At any rate, many engineers I know love to smugly use this acronym soup.
I almost think this was a deliberate choice. Makes the services sound more important than what they are. At any rate, many engineers I know love to smugly use this acronym soup.
hahaha, this is great
Hosting this quiz on GCP / G Suite ... hilarious :)
Why they don't use normal naming? Like why they don't call the DNS manager "AWS DNS Manager" but "Route 53"?
Because they are cool internet people and you are not.
:( Why so much hate on hacker news?
Leave amazon alone!
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.