The author can argue that the UX is bad, but they can't say it's "faulty" or "inaccurate".
Edit... After fully reading the article, the author even says this: "If an interface doesn’t quite do what it appears to, it should give a warning." The warning is right there in the UI, captured perfectly by his own screengrab.
Which is presumably why the article mentions the below in the second paragraph.
"After this experience, I cannot honestly recommend using AWS unless you have a professional sysadmin operate it for you"
"Sure, what do they say?"
"Who?"
"The errors"
"I don't know, I clicked them away"
A UX that has a high probability of causing harm is accurately described as faulty. I'm with OP here, technical warning-box being present aside.
I also review my bills every month, which would have mitigated this issue significantly.
Admittedly the feature that Azure has that AWS doesn't is "kill everything when exceed X dollars". Not so great for prod, but superb for dev.
Please realize that when you hand devs with AWS keys, you're assigning an unlimited liability to your company with whatever accident a dev might do. (Accidents happens, and quite often when experimenting.)
A cursory look would've been enough, really. If this would have been 20$ or so, I would not fault anyone for missing it. But 800$ missing every month should definitely get some attention, especially when these are amounts endangering your ability to stay afloat, as the author seems to argue.
I'll elaborate: human error is not all reducible to a UX problem, at least not in any meaningful sense in casting blame at AWS here for causing the user's error. Giving users an explanation of their actions at the top of the page is not particularly bad UX, it seems adequate. If course they could do more, modals that say "here's your estimated costs for the action you're taking" and that might be better. But then again that might not be practical across the range of AWS modules, and a user that if ignores their bills and bank statements for most of a year might easily ignore those notices as well.
If you define every mistake a user makes as a UX problem then you've defined it broadly enough that it loses meaning. I doubt that's you're overall intent, but in claiming the user's failure to read the top of the page was a UX problem you're crossing over into that territory.
I might be more sympathetic if the user wasn't so lacking in awareness that they also didn't read their bills and bank statements for so many months, and didn't take the hour of time upfront that was ultimately necessary to understand part of a massively complex system. No reasonable level of UX design would have fixed all of that.
It's also a bit ambiguous-- it seems to be focused on how it will change the settings and last modified date. I could see how one could read that as "this action will create a copy of your files [and then delete the old ones] rather than moving them directly", warning you that your file metadata will be impacted.
There's also the problem that these warnings are everywhere in AWS console so you develop a bit of blindness to them.
So they have a pretty much wrong button name ("Edit Storage Class" --> "Copy to a different storage class") with an ambiguous warning message commingled with a bunch of other warning messages. I'd call that bad UX.
That being said, 8 months is too long for this bill to be considered AWS' fault. and the fact that he's been working really hard on his movie is irrelevant and comes off as whiny
Plus the following. UX is the umbrella term for "User Experience", not User Interface.
Therefore I'm not defining UX as users making mistakes. I'm defining UX as the user's motivations, journey, and actual experience with the site (and possibly extending to their interactions with the support team). This is not an 'overly broad definition', this is THE definition of UX.
If anything, what's happening here is the reverse. People are defending AWS' bad user experience, by narrowing down the definition to the narrow scope of UI-design and safety-nets. However, no amount of UI safety netting will salvage a website with bad UX (or rather, where UX never came into play during the design stage, except at the very late stages when it was only down to designing a UI).
So to reiterate. I'm not blaming AWS for the user's effective failure to read a technical warning message which then caused them harm. I'm blaming AWS for the fact that it even came to that in the first place. That is bad UX.
Also user experience follows pretty heavily from UI design, you cannot separate the two without losing something. But "experience" is also much more subjective: Some might have a bad experience digging through menus while another person might have a good experience, like the way it's all organized. As an example, I found the notification for this issue perfectly acceptable: it let the user know a copy would be made. That is a pretty clear indication that the originals will still exist, and new ones would end up in Glacier. My experience there would be fine.
User experience is unhelpful in this respect because you cannot design your system to satisfy the experience of every user.
If it doesn't operate like Dropbox under the hood, don't make it look like Dropbox in your interface.
If an action creates a copy of objects, call it "Copy Objects" or whatever.
I think that presenting an S3 bucket as a set of files that you can select and perform operations on sets up false expectations here. And not showing incomplete multipart uploads in the file listing or having any way to see they are there isn't great.
This is 100% negligence on their part, not AWS's fault. The cloud isn't magic, you still need to read documentation.
When you did the glacier operation, the GUI was telling you that it was COPYING the files to glacier. Those files also existed elsewhere, in normal S3 space. There's ways to cure this issue at the command line, primarily a list of all attributes per file - and there you can see the respective storage plans.
Secondly, do you have billing alerts set up, at 1.25x per average day's accrual? (30$/mo would be around $1.25/day, as not to email-bomb you). Billing alerts would NOT have solved the issue of improper storage class, but you would have seen a massive spike in costs. It probably would have cost you maybe $100-$200 to solve it early on.
Thirdly, how much of the 5 Pillars of Well Architected Framework are you following? ( https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-we... ) Admittedly some of these are "pay AWS double and get disaster prevention" style rules. However... pillar 5 is all about cost optimization. An ounce of prevention is worth a pound (or $7k) of cure.
My assumption when reading that message was that it would appear to update the storage class, but actually create a copy of objects with a different storage class and delete the old objects. It doesn't make sense that it would just duplicate my objects, and I still can't really imagine anyone wanting that. Why would a box called "Edit storage class" create a copy and then not destroy it? Why not make a dialog box that just...edited the storage class?
So maybe I had a previous version of all my files sitting in regular S3, with the current version sitting in Deep Glacier, and I may have just happened to delete previous versions of objects when I created the lifecycle rule.
To answer your question -- I don't think we're following any of the pillars of well architected frameworks. I'm a filmmaker who knows Javascript and PHP and not system architecture, and I was looking for a cheap way to not lose our movie to the ravages of time. I'm definitely not the only one.
> create a copy of objects with a different storage class and delete the old objects. It doesn't make sense that it would just duplicate my objects
Isn’t that exactly what 'copy' means in pretty much all IT contexts?
It seems that some "move" operations are "copy" operations, which is the context in which I understood this warning:
https://forums.aws.amazon.com/thread.jspa?messageID=455101#j...
The charges were caused because (a) selecting all does not select incomplete multipart uploads, which are hidden in the interface, and (b) I believe the operation is not recursive.
If it created a copy of the object as described, the charges would go away.
The warning may have well just said please note that the combothrombobulator may break existing encabulator nodes. If what you need is duckbill-style joints instead, use a thermocoupling-paradigm instillator instead.
When it should have said "THIS MAKES EXTRA COPIES WHICH COST MORE".
Is the argument that this should have been a pop-up that required you to click “ok” instead?
"This action creates a copy of the object with updated settings and a new last-modified date. You can change the storage class without making a new copy of the object using a lifecycle rule."