It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".
As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it.
But it shouldn't be possible to make this mistake if this was designed properly and in a way that made it clear that what you're about to do is actually dangerous and not "dangerous" like the other dozen times you've seen the same message.
Yeah. A warning that can be pattern matched by a human brain, that is just a routine action, will result in autopilot behavior. Flipping early repo visibility is common, I assume. Flipping visibility of 100+ star repos is likely much less common. So having a separate warning in that case might help you snap out of autopilot due to novelty.
A common knee-jerk reaction to "users aren't taking our warnings seriously" is making the warning look more scary and involving more (mechanical) steps – such as two confirmations instead of one. Well, that's pattern matchable and subject to desensitization.
Like the article states, it's more efficient to instead show what you're about to remove, i.e. a summary of the content as opposed to an identifier, then you get both novelty and proportional scariness, depending on how "big" it is.
Pretty much agree— Universal human fallibility is not an avoidable moral failure, but looking down on those who've made, admitted, and taken responsibility for simple mistakes sure is. Unrealistic assumptions about people's attention, processing capability, and physical capabilities may be the greatest hurdle when trying to actually solve people's problems with software. It can even be a safety issue— consider the Therac 25 incident.
That said, superlatives like "impossible" aren't realistic here. As long as an action is possible, it is also possible to fuck it up. The challenge screen does require typing in the repo name which is a pretty solid attention-getter. It would be nice to list the important side effects in big angry letters but I'll bet the list of side-effects that are important to some people would be pointlessly long. Maybe a sanity check requiring repos with extremes in certain metrics to get a sanity check from support first— but I have had some preeeeettty protracted response times from GitHub support.
> I'll bet the list of side-effects that are important to some people would be pointlessly long.
There's many good ways to design this that wouldn't result in pointlessly long lists (which is another problem). You don't need to expose everything that will happen when you do an action, just the "most important".
With unlimited budget, you could compare a bunch of metrics to a baseline to figure out what might be important. Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that. At the end of the day, Github repos aren't extremely unique. Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken. Everything else can be hidden behind a "... and X more" if people are curious.
This both highlights the most important things that might happen, and also provide people with an action to do before confirming, hopefully helping to break the autopilot at the same time.
Warnings are good but not perfect. At the end of the day, you can’t help everyone with just warnings. You could make the UI bright flashing red, with a skull and crossbones, have it say “Never invoke this: it will delete all your data and kill your dog. Please type ‘I_WANT_CANCER’ to continue.” And users will do it. It can’t be helped. The only (admittedly hard) way is UNDO.
Undo. If it's possible, you want undo. If it's difficult, you still want undo. Only when you've satisfied yourself that it's outright impossible should you reluctantly design the UX with the "Are you sure?" prompt instead.
Also, if you must have I_WANT_CANCER type prompts, try to make them involve expressing what it is that the human is agreeing to, because sometimes it's only at that point the human realises their plan was very stupid. GitHub does that here (you have to type the name of the repo, to delete main_project you'll need to type main_project) but many things do not.
This is why I like Git's force-with-lease. When I try to forcibly overwrite the state, because I know Jim's push was wrong and must be undone, force-with-lease makes me express that, "--force-with-lease=jim-daft-change". And when in fact what I'm going to overwrite is Lisa's urgent bug fix, not Jim's erroneous change, the force-with-lease fails and to get it to apply this way I'd need to say "--force-with-lease=lisa-bug-fix" and that's one last opportunity to say "Wait, what? That's not what I want to do".
I think from UX perspective it is unbelievably more convenient as well. Plain popup warnings with "press Ok if you mean it" are bad enough, but quite recently the new even worse "type delete, if you want to delete, then press Ok" popup has been spreading about... If I want to delete over a couple of things I get incredibly irked.
- (not intrinsic) many interfaces only give you a few seconds to undo your action, which wouldn't help in this case
- (intrinsic) some events can be layered on top of your change, meaning that you have to either block the undo or reverse all the subsequent events too. This wouldn't be the case for this HTTPie incident, but does prevent UNDO functionality from being a silver bullet.
You assume the metrics you have are sufficient to determine intent and importance, that your users needs are uniform enough for those determinations apply, and discount the possibility of making things worse by communicating the wrong thing. These assumptions perennially land developers and inexperienced designers in hot water designing things like this.
> "most important"
Yes— the problem is determining the most important metrics for the human who's reading the dialog. Sorting the second part is a lot more difficult than the first.
> With unlimited budget
This framing is only useful to determine what behaviors would be great, not feasibility. We seem to both agree on the ideal behavior but not on the feasibility.
> you could compare a bunch of metrics to a baseline to figure out what might be important.
Important to whom?
> Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that.
Average for what? Just average for everybody? For the deprecated SlackTextViewController which has vastly higher numbers overall than the unmeasurably more important net-snmp? What about for repos that serve as core functionality to frameworks that only care about forks? XML Schemas that people refer to but never interact with? What about for a company that doesn't care about stars because they're incredibly popular outside of that repo but it's critical for them to monitor the small number of people who've forked their repo?
> Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken.
The repo about which you said this mistake should not have been possible was an extremely rare edge case. The article went to great lengths to explore just how fantastically different this repo was. And if you're talking about painting pictures you're using the wrong medium. More information can make the message more pointed but only if it's brief and extremely relevant. If it's not, it's going to reduce the focus on the danger message.
> Everything else can be hidden behind a "... and X more" if people are curious.
Aaaand we come full circle. The whole point of this is to put the metrics most important to that user right in front of their face in bold type because that's going to stop autopilot mistakes. If it's hidden, it failed. Beyond that, the order in which you list things connotes importance— closer to the beginning means more important. Being hidden connotes far lesser importance. If you put the wrong things at the top and the right things behind a click then the autopilot user subconsciously assumes they'd care about the hidden things even less. You're increasing the risk of failure rather than decreasing it. If you're going to highlight anything, you better highlight the right thing.
The existing dialog is pretty clear that you should investigate what it does before you actually execute the command without giving people false clues, and that may be the best compromise. You don't convey false impressions but still convey danger.
> At the end of the day, Github repos aren't extremely unique.
From a quantitative perspective they're not incredibly diverse, even if they're probably more diverse than you imagine. What is immeasurably diverse is the roles those software packages serve, the people who interact with them, and what they need to accomplish their goals. Assuming you can boil that down to a heuristic using available data is something that needs to be concretely proven— not assumed.
It sounds like you've never been part of an engineering organization (I know you have since you bring up unlimited budget ;)
It is obviously possible to design a much better, contextual warning with (more) relevant details highlighted. How much time is usually set aside for those?
And yet, it's never going to stop mistakes.
And how many other places like these are there in a large service like GitHub?
A much better way to fix this is to expect mistakes and make it possible to revert instead. Soft deletes can make that trivial to implement for the most part too (except in GDPR like cases where you've got to really remove stuff).
> The challenge screen does require typing in the repo name which is a pretty solid attention-getter.
This is not quite correct. In requires inputting the repo name. It's attention-getting the first time. But recently with some colleagues as part of a handoff we went through 50+ repos and archived the irrelevant ones. Very quickly the person doing the actual archiving went from typing to just copy-pasting the repo names. For programmers, copy-pasting from one spot to another can become very mechanical.
So I think this UI choice works well for something that is done very occasionally. But it's no better if people are in the habit. Whereas showing novel information about the cost of the choice would be helpful in breaking the routine. Then could then also make it so that they had to type something only when the operation has a high cost, and what they typed could be something not directly copy-pasteable.
That's fine. The goals of designing a sanity check prompt to snap people out of autopilot are entirely different from goals you might have in a security system— their being defeatable isn't even a flaw. Jersey barriers vs rumble strips.
If someone deliberately doing the same thing over-and-over can avoid the manual effort, that's fine. Their frustration would likely make them think about it less. You don't, and shouldn't get prompted to do the same thing using the API, either.
That’s not quite it. The solution isn’t to stop them from doing it or warning them more aggressively; it’s to make it genuinely less dangerous. For example, make the stars all come back when you reverse the switch.
Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.
True "Undo" is, IMO, a pipe dream for all but brand new projects. That will pretty much require you to rearchitect a decent chunk of anything that wasn't built with it explicitly in mind.
In this case, I don't quite understand why stars and forks need to be deleted when switching visibility, since it seems like the two shouldn't be linked. I can star and fork my private repos just fine, so it seems like it was just easier to clear it out than to deal with RBAC at that level.
Many people won't notice some of their stars having disappeared, but many would be surprised to see their forks deleted without their consent, especially those that are not merely a mirror. People can have diverged forks after adding substantial changes without feeding them back to the original for a variety of reasons.
Just not deleting them in the first place, or not deleting them until explicitly asked to, would suffice, and would be, ultimately, less code. So, I am not buying the apologetics.
The issue tend to be services who are not upfront about it. "This is potentially really damaging, so in case it's a mistake we'll just hide it for 24 hours during which you can undo" or something to that effect would be sufficient.
The counterpoint is that tools like that can be abused. Just as a hypothetical, if I have an open source product and do something the community doesn't like, I can make the repo private til the storm blows over so people can't un-star it. The number of people that remember to un-star it a week or two later is going to be a lot less.
I still think you're right, but it's not even as simple as UX and small backend changes. Allowing the repo owner to re-play other peoples' actions comes with complicated policy decisions. GitHub could make it so only support can restore those, but now they're in the awkward position of having to say when it's okay to restore and when it isn't. Still, it may be the best compromise.
> It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".
It's sort of equally easy to say Github should do X or Y to improve the UX in this (rare?) case without actually knowing the effort or opportunity cost.
Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.
> Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.
I doubt the engineers working on the stability issues or billing have anything to do with UX and vice versa. It's not like there's a singular focus that everyone at the company must prioritize above all else. Multiple people can work on multiple projects and not impact one another at all.
I am surprised so many people treat losing stars as "dangerous": I can certainly emphatize with the designer coming up with this pop-up while looking at a sample project with 12 stars.
Considering this project was out of ordinary in having 54k stars (article mentions being in top 80), they should not be surprised that their case is not top of mind.
Sure, it would be nice to highlight the most destructive of actions, but they already had to type out full project path as confirmation.
I do believe it would be better if Github allowed restoring data in the next few days (soft deletes ftw) once they hit this issue themselves in the past.
And Github support should have recognized that this project is a special, out of ordinary project, and afforded it some engineering time to restore everything.
> I am surprised so many people treat losing stars as "dangerous": I can certainly emphatize with the designer coming up with this pop-up while looking at a sample project with 12 stars.
Lots and lots of websites and companies use the number of stargazers as a strangely important metric for success, so losing them can be really bad.
It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".
As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it.
But it shouldn't be possible to make this mistake if this was designed properly and in a way that made it clear that what you're about to do is actually dangerous and not "dangerous" like the other dozen times you've seen the same message.