491–500 of 697 posts
This seems like bad design from a UX perspective. Projects I star are a characteristic of my account. If a project is made private, I still want to have the star in my account list; it feels almost like gaslighting to just remove a star.
Earlier quoted context omitted.
> 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 impor…
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.
- (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.
Earlier quoted context omitted.
How many years have we had to learn from people using programs to know that people make mistakes. Goodness knows how many people burned themselves using "rm". For that reason alone, "rm" is a bad tool, and should be replaced with something like trash-cli.
that would break billions of scripts and confuse the hell out of hundreds of thousands or millions of users. Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command.
An option that shows a y/n action. That's what GitHub does when you're about to make private/delete a repo (even more asking you to type out its entire name) and yet here we're.
I really like this post. While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from. Lesson 1 on UI design I think is really important. I often think scary popup boxes ar…
He did have to type "httpie/httpie" in the box to confirm, no? I'm rather surprised that that didn't snap him out of auto-pilot mode. There ought to have been a DING in the brain seeing that the repo this is being applied to was httpie/httpie? OTOH, I haven't been in such a mode, so I really got no right to comment on this. Best wishes to the team -- that those who saw his post will restar/rewatch the repo -- and (fw…
Earlier quoted context omitted.
For Lesson 1: I think the general pattern that ought to be followed is to "prefer undo to warnings." Undo is often harder to implement, however it's usually a superior experience.
Even better, flipping "public/private" has absolutely no need to delete any information at all. There could be separate buttons, "Delete all my stars", "Delete all my watches".
Of course it does. You can’t watch/star a private repo unless you have access, so all watchers/starrers should be removed. If you kept the data as-is watchers would still see the repo updates in their feed, which is the opposite of the 'private' feature promise.
Earlier quoted context omitted.
I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - t…
Agreed, and I'm genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn't want to p…
Earlier quoted context omitted.
I suggest you read "The Field Guide to Understanding 'Human Error'". You'd learn a lot. https://www.amazon.com/Field-Guide-Understanding-Human-Error... My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify those mistakes into large, irreversible impacts.
This, 1000x this. 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 t…
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.
>"The same goes for stars. If you’re one of those 54K people who’ve starred the repo any time in the past decade, the repo is no longer among your starred projects." // This seems like bad design from a UX perspective. Projects I star are a characteristic of my account. If a project is made private, I still want to have the star in my account list; it feels almost like gaslighting to just remove a star.
You can’t star a private project, so by definition you can’t "keep" a star on a project that went from public to private. That’s not bad design, that’s a logical behavior.