This safety mechanism is not there if the drawer is embedded in a larger frame where tipping over is not possible.
Sometimes it's not bad UX, it's just the thing trying to protect you from your stupidity.
Think about that: children have died from 𝘥𝘳𝘦𝘴𝘴𝘦𝘳𝘴. It's easy to be smug power user complaining about design when you only consider how you interact with things.
This very thing happened to me decades ago: I walked into parents' bedroom to find my fearless younger brother, ignoring my yells, climbing up the handles on the front of my father's dresser. I yelled for my parents but I couldn't stop him fast enough. As the dresser began to tip I got between him and it and pushed upward, both removing him from the dresser and tipping it back to rest.
I was truly shaken and astonished that this child might have killed himself, since I knew that the top drawer was filled with my father's most valuable (and heaviest) WWII memorabilia and that the entire dresser, about 5 feet tall, was hardwood with decorative protrusions on the front.
I know I become hyper aware of any small black specks in my peripheral vision since they resemble spiders that could have posed a threat to our ancestors so we evolved these heightened senses to avoid them.
And in nature you do not really have much big objects that could fall on you if you climb them.
Maybe a large boulder loose ... but they are very rare in my experience. So I guess it makes sense we are not prepared for it. What is much more likely, a loose rock which breakes off at climbing .. we are prepared for. Instinct reflexes are pretty fast in that case, I noticed ..
I would hope the ability to sense loss of balance equilibrium would innately result in having the strong urge to bail from that activity to sturdier ground, given you knew you could safely land on the ground without a worse outcome.
A tipping cabinet takes much longer to fall unlike a rock dislodging when you are climbing the side of a cliff in nature. Maybe it is simply a blind spot in our evolution like you suggest, evolution never optimized us for this edge case scenario not experienced in the wild.
Cunningham's Law states "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
The most common sighting of this in action is OSs (ask "how do I do Y with Linux" and you'll be pointed at documentation, say "Linux can't do Y but Windows can" and you are more likely to get a couple of pre-baked solutions sent your way, and the same works the other way around and with other OSs) but I've seen it work for scripting languages/environments (powershell, bash, ...), databases (postgres, SQL Server, Oracle, ...) and other tools.
I am amazed there is a law describe this. This is so accurate. I couldn't be bothered to answer questions even if I knew the answer, but I would be bothered to correct it if the answer were wrong.
Update could legitimately mean upgrade of course and you could have it essentially auto-correct, but I'm generally wary of software trying to do what it thinks I mean rather than what I explicitly say (and not doing anything if what I explicitly say doesn't match up with its language). At some point it will mis-guess and do something I really didn't want.
Now suppose instead of "update" they used called the functionality "sync". I don't think I would have the same problem, since linguistically and contextually, I wouldn't use Brew to _sync_ packages. But it does make sense to use "sync" when talking about getting updated information about which packages are available--we're syncing the local catalogue with the remote catalogue.
So I agree with grumpy blog that their use of "update" here is suboptimal. There are better fitting words that both better describe the functionality and avoid the confusion.
I'm not a heavy brew user, but if it works like other package managers then the "update" command is a fairly casual, frequently used, and typically reversible kind of action. If you pull in too high a version of something, oops, remove and redo. Whereas "upgrade" is something you probably only do when you have a specific reason.
I mean, it's sometimes sensible for apps to auto-correct on inputs, but a frequently used "muscle-memory" kind of action should never auto-correct into something heavy and non-reversible. I imagine that's the thinking there.
It's not something very intuitive since we generally expect furniture to be stable in normal usage. To make it worse, when it starts tipping all drawers slide open and bang into you, compounding the effect and accelerating the move.
Anyway, you need to close those drawers eventually, right? Why not before opening the next drawer?
Put another way, the alternative is to support the general use-case of disorganization: "I'm not sure where the thing I'm looking for is, but I need it in a hurry!" Do you really want to categorically assume in such situations that people have mitigated the tip-over risk in some external way? Just to allow for high-speed riffling?
Your castor idea only really helps if the search happened to start with the bottom drawer first. That's sorta logical, at least in some cases, but I don't think you can come anywhere close to assuming it's going to happen all the time.
The one illustrated isn't deep enough for hanging files -- maybe the odd ream of A4, pens and pencils. Will need an awful lot of carefully placed paperclips and pencils to tip. Which is why you rarely see those locking each other out. If you use it for storing your collection of lead weights you bring it on yourself (the base of the drawer would probably fall through anyway)... :)
Even if there's a top drawer with folders, to open more than one drawer, a bottom one would be open anyway, with the same result.
That set of drawers is not sizeable enough to warrant tipping protection that is so unfriendly to the user. If it were a 2m high filing cabinet, I would agree, but it isn't.
Dressers made of thin, light wood, filled with drawers full of clothes and/or toys never have this safety feature, and those are the things which need it most; they all require (or recommend) that you instead strap the top of the dresser to the drywall, assuming that it is both against a wall and that the wall is finished with drywall, and not some other wall material, such as brick, which is common in certain geographies.
Too many people commenting here completely missed the point of the linked website entirely, immediately homed in on some minutia, commented with some variant of "uh, actually...", and even got that wrong, arguably.
It's really amazing to me.
Thinking about people as stupid, as a designer, is suboptimal and miguided in my opinion.
I agree that using the world "stupid" could be ill-receive and other words could avoid this problem, but with the right audience this shouldn't be a problem.
We are also dumber when stressed, when sick, and absolutely so when we are both at once.
In my opinion, it is bad UX, but for a reason. There might be better solutions.
How about a pulley system which does not require locking the drawers but instead pulls the other drawers shut when i open a new one. No locking, no tipping, better UX.
The system is clever and had its importance.
But people don't, so these companies introduce measures "for safety" by compromising the UX for all their users (can't open multiple drawers at once even if you wanted to) in order to prevent a dangerous scenario that the operator failed to address (leaving the dresser unanchored and ready to topple over).
And what do we think is the goal of the manufacturer? Is their goal to provide a public service and preventing people from injuring themselves? Unlikely, as it's still entirely possible to overload the drawers, or put something on top, that will still provide a dangerous result. No, their goal isn't safety because the safety is out of their hands. Their real goal twofold: First, to prevent situations where their products can be associated with dangerous or fatal situations, even if the fault has nothing to do with them (operator error, not product error). Second, in events where dangerous or fatal scenarios do happen, be able to say "we've taken measures for safety, so don't look at us".
This "feature" isn't for their users' benefits, it's to protect themselves, and they do so at the expense of all the users that _do_ use their products safely and as intended.
Also, it still doesn't prevent toppling over from a single heavily loaded drawer.
Don’t make drawers?
This is my filing cabinet. I put a bunch of papers in it. It's not going to tip over. Your assumption of a worst-case scenario is getting in the way of how I actually use the cabinet that I own.
It is still bad UX, when the result is frustrating.
And some people do not need nor want to be protected from all forms of stupidy. I mean if you would accidentally blow up something by pressing the wrong button, then yes, safety first. But some people actually can use drawers without letting them fall. And if the worst case happens .. it probably won't be catastrophic either. I mean you can break a leg or ancle falling down on any road anyway, if you don't pay attention.
That's grumpy-worthy I find ;-).
So, add "JS is required for crucial, rather than merely useful, features."
Enter this into console. Happy Holidays.
> Five other people are reading this doc, right? Wrong! The user with a white avatar is actually a button to start a chat! Why does it look like a user and is placed where all other users are, we’ll never know.
> But wait, isn’t there a chat button next to Share? No, that’s comments! What’s the difference? Comments are square, while chat bubbles are oval!
> Also, if you ever wanted to check how your stocks are doing, there’s a button for that too.
E.g. when closing a file with unsaved edits, you typically get a dialog with three buttons:
[Don't save] Cancel [Save]
The same system would make perfect sense if it only had one focus target. Dialog comes up, the "main" action is focused, tab cycles the focus, space/enter select it, and escape cancels the dialog. There'd be nothing to learn and nothing to remember.
Complaining about this is like complaining that the computer is reading the text out loud.
I know there's a setting to prevent the keyboard from affecting dialogs at all, but obviously that's not what my comment was about.
This is why it's complicated: it's not aimed at regular users, only at people who need it for accessibility reasons, or power users.
(One wonders: if the tab system didn't make two focuses, whether it wouldn't be intuitive enough to be on by default :D)
Anyway, I thought this only happens when you opt-in by enabling tabbing between all types of controls (the default is that only edit controls can get focus). What you're describing here, I think, is that the "Don't Save" button has focus, which is why spacebar activates it.
I hope this doesn't get nerffed. "Space => don't save, Enter => save" is part of my muscle memory now. Why would you enable focus on any control and then bang randomly on the keyboard anyway? If you aren't sure, leave the defaults as-is.
Sure, but how is that intuitive?
As such, the relevant question isn't "is it logical?", but rather "is having two UI focus targets so useful that it justifies cases where the user will lose data if they choose incorrectly between two superficially similar options?". And obviously that's down to opinion, but it seems like a pretty huge glaring no to me.
(Ellen's Millennial challenge.)
On a desktop that is mildly annoying. On a Windows tablet it is extremely annoying, because the onscreen keyboard closes when the focus leaves the text entry field.
For Chrome startup you can fix this by changing the startup page from the new tab page to a specific URL, and simply give the URL for the Google front page as that specific URL.
But Chrome doesn't seem to have a way to set the new tab page itself to start at a specific URL (without installing a third party extension) so you still have this focus changing idiocy on subsequent tabs.
A further Chrome annoyance on Windows tablets: if you tap the address bar to bring up the virtual keyboard and then try to paste something by typing CTRL and then V (CTRL on the virtual keyboard acts as a one-shot CTRL lock, so you can invoke control keys with one finger), Chrome somehow loses the CTRL part, and you get a "V" in the address bar. If you then backspace, and try CTRL V again it works.
Usually with no basic protocol backup, such as a basic web api, cli, or filesystem interface.
Of course that's a feature for hardware manufacturers. No one wants a device used for decades, even though that's exactly the level of support necessary to make IoT successful in consumerland.
That apple intentionally breaks things that aren't broken / forces upgrades within its walled garden is even more despicable
I agree with Google, that it is more important to show how much overall storage you have left, than how much is being used in this particular service, but there needs to be an overview that can show where storage is used. And clicking around on Google Drive it appears there isn't such an overview.
So yes, bad UI, but for different reason than what grumpy website says.
Good UX/UI should provide intuition to the user, especially in more complex circumstances.
If you click on Buy Storage, it does say where it's used. Not the most obvious, but good enough.
This is on Android BTW, not sure how iOS does it. But instead of the newest notification appearing at the top of the list, maybe it should appear at the bottom. Problem solved.
A similar issue is in Twitter for Android, I search for an account, want to click on an item and then the list updates.
I can't believe this is not fixed yet.
In a world of devs that has to wrap their head around pointers or references, having copies of references, in a distributed system, doesn’t exactly come naturally to most, especially new, developers. This is pretty bad for what should be baseline dev tooling. It’s like having to learn regular expressions just to be able to edit your first hello world program!
That being said, git is complex, and trying to idiot proof a complex system with more abstractions only makes it more confusing when the abstraction leaks (which it will)...
The UX crowd embraces this for the same reason hardware people don't support their software long-term.... it keeps people buying their services at a higher premium.
Stupid UX / programming decisions documented since 2004
Actually I really appreciate someone collecting collective stupidity in one place. I am constantly frustrated by terrible design and product decisions every day (both at work and in general) that I can't do anything about. Maybe shame will work.
What makes me sad is that it seems like us who appreciate & demand good quality, no-nonsense software seem to be a minority, and the masses don't seem to care. I've noticed most non-tech people just accept their fate, either they've already came to terms with the idea that "tech sucks and will always suck", or they legitimately don't know how the experience can be improved (a lot of things may look absurd to us as developers, but might not to someone not familiar with how those things are built) or that they think software is delivered by gods or equivalent superior entities and that they, the "peasants" have no way to call for change even though voicing discontent in feedback sometimes works and is at least worth a try.
A lot of people in tech enjoy being the "ultimate power user" and are proud of using things that look or feel complicated.
You just have to look at HN itself to read trough rationalisations of why software is bloated and why bigger software is probably better. It's never driven by data or by facts, it's purely by anecdotal experience.
You're all sheep.
Not being able to open all drawers at once is actually a safety feature preventing it from tipping over (see Ikea MALM fiasco). I suppose the UX could still be better.
Saying that people should learn the concept is not helpful. I know what it means and I just disregard the message as noise. Wait, I think I often reflexively write "git pull" when I read that message. So you could say it does serve some purpose.
I know it doesn't, but the message IS misleading for the inexperienced. If i need to read a user manual first to understand it they might as well replace the message with some status-code written in hex.
In the case of git status, I think the UX is simply bad, as evidenced by the replies and my usage of git. A text update could improve the command substantially - and perhaps a suggestion to run a git pull to update the tracking branch. I don’t think it’s reasonable to read a 456 page book on git
- on a phone, long press on that hyperlink. Bingo, you've got your sharing screen to the post
- on a PC: right-click, copy. Bingo, you've got your shareable link to the post
(Yes, I realise your post is /s :) )
In the same vein, I've been thinking of having some universal bug/annoyance reporting tool where you'd tag each annoyance with the software/hardware/website and optionally its version.
Some real gems in there.
When the developer uses that on the body tag...
> 2019. All fights retarded.
Why don't you suggest alternate products that don't have these problems?