4 ms·
I'd prefer to see this integrated into the AWS UX. For an external crowd-sourced version, I'd like to see something like this with a column for maturity, and w
by wegs 6y ago
I'd prefer to see this integrated into the AWS UX.
For an external crowd-sourced version, I'd like to see something like this with a column for maturity, and whether it actually works.
The classic AWS services are rock-solid, and perfectly sufficient to build a business on. Many of the newer ones are.... much less so. A green checkmark, yellow question mark, and red land mine icon would go a long way towards letting me know what I should and shouldn't use.
- imglorp 6y ago> integrated into the AWS UX Sure, it should be right in the headline of the service's "about" page. The fact that people need this at all is UX problem. If people are reading your "about" page and nobody understands what the hell your thing does, maybe your marketing, faux-tech, word salad is pointless.
- Frost1x 6y ago>The fact that people need this at all is UX problem. Is it a UX problem or is it intentional deep branding to further promote vendor lock-in? This is one reason I've been opposed to AWS since the early phases--I don't want to learn all of their stupid branded vendor-specific nomenclature.
- scarface74 6y agoIf you are any sort of real business, you already “locked in” to more than likely a dozen or more third party services. I worked at a company whose entire workflow was tightly integrated into Workday via APIs, not to mention SalesForce. If you have ever worked in healthcare, the level of “lock-in” that they have to their EHR/EMR and various other third party services. would make you cry.
- karatestomp 6y ago> The classic AWS services are rock-solid, and perfectly sufficient to build a business on. Many of the newer ones are.... much less so. A green checkmark, yellow question mark, and red land mine icon would go a long way towards letting me know what I should and shouldn't use. I’d like that and also the same thing for languages supported by various services and SDKs, which are sometimes supported and sometimes “supported”.