Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We lost 54k GitHub stars

httpie.io

Post reply on HN
Print view View original

111–120 of 697 posts

Re: We lost 54k GitHub stars

#111

Post by cmeacham98 »

vaishnavsm wrote: post #70

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…

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 - the author had to _type out_ the name of the repo they wanted deleted into the warning box. At that point, it's hard to believe the author when they claim that this one addition to the warning UI would have definitely stopped them when they weren't paying enough attention to notice they had typed the entirely wrong repo into the confirmation box.

Re: We lost 54k GitHub stars

#112

Post by SnowHill9902 »

benjaminjackman wrote: post #110
vaishnavsm wrote: post #70

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…

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.

Rollbacks even better.

Re: We lost 54k GitHub stars

#113

Post by pharrington »

Brian_K_White wrote: post #97
pharrington wrote: post #79

Earlier quoted context omitted.

You can only confirm the dialog box by typing in that line you're saying he didn't notice.

Reads article and somehow misses it's entire thoroughly examined point, chides author for not paying attention.

If I understood the blog post correctly, the author wants the "You will PERMANENTLY lose: All stars and watchers from the repository" to be changed to "[...] X stars and Y watchers..." Which I agree would be a better UI.

Re: We lost 54k GitHub stars

#114

Post by jdmichal »

vaishnavsm wrote: post #70

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…

I ran into this in pgAdmin recently. When right-clicking on a server, the options to disconnect the server and remove the server are right next to each other. Clicking disconnect presents you with the following dialog box:

"Are you sure you want to disconnect the server? No / Yes"

Click remove presents you with the following dialog box:

"Are you sure you want to remove the server? No / Yes"

Good luck! I mean, it's not a super huge deal to recreate the server entry, but still annoying when you're in the middle of something and just realized what you did.

Honestly, just replacing the "Yes" button with the action being taken would be enough to improve this. "No / Disconnect" and "No / Remove". But my personal opinion is that disconnecting is not a destructive action unless there's an open transaction or running query. So the dialog box should be contextual on that scenario, and otherwise it should just disconnect.

"Disconnecting will cancel executing queries and rollback open transactions. Continue? No / Disconnect"

Re: We lost 54k GitHub stars

#115

Post by ncmncm »

Johnny555 wrote: post #106
nessguy wrote: post #67

Earlier quoted context omitted.

Just as AceJohnny said, the scope of this is entirely different. Restoring a backup for an internal project costs time/resources that the company can easily handle. If it became a problem it would be easy for github to tell their internal projects "No, we're no longer restoring from backups" Opening up the ability to do that externally would potentially require multiple people working full-time to handle the requests…

Or, knowing that it's the only way they have to recover from this situation, they could make the process easier to do and price it out as a service.

Or, just leave everything in place, always, and have the other code ignore the annotations for exactly as long as the repo is private.

Re: We lost 54k GitHub stars

#116

Post by mherdeg »

vaishnavsm wrote: post #70

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…

> While the author clearly feels bad about the fact that they've lost his community and that GitHub couldn'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.

Also, writing a solid blog post about a customer-service corner case and getting it to the top of news.ycombinator can be a great, if somewhat last-ditch, opportunity to escalate a problem.

Re: We lost 54k GitHub stars

#117

Post by mattcwilson »

burnished wrote: post #33
paxys wrote: post #9

"It's their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this." If a "type your repository name to confirm" box still doesn't make you double check that you picked the right repository, what else can they even do?

Yeah, I also found that tone sort of jarring, but they do bring up a good point; the warning banner and inputs should be contextual and having to input the number of things affected would be a UI improvement. And I can understand why they would write this in anger/frustration.

I’m curious which statements from the article carried that tone?

Re: We lost 54k GitHub stars

#118

Post by [deleted] »

qbasic_forever wrote: post #49
sefrost wrote: post #3

It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.

I wonder how different the response from Github would be if this blog post was instead, "Oops, Github's confusing UI made me delete the entire project metadata... so since we're forced to start fresh we decided to move to Gitlab/sourcehut/etc."

[deleted]

Re: We lost 54k GitHub stars

#119

Post by yowlingcat »

What an astonishingly poor design decision by GitHub. The intelligent design decision to making a repository private is to have private be a flag, and to have that privacy setting propagate down to the watcher level. Then, when a repository is made public again, all the watchers etc return.

Want to give users a way to remove all watchers? Great, make that /a separate action/ -- in no world and in no other application is it an intuitive UI/UX pattern to have make something private mean it gets deleted. That's absurd. Make private means "hidden for the indefinite future, but available to be made unhidden when I as a user see fit." That is the only reasonable definition I have ever seen (Instagram for example).

Whether you want to show a user that they watched a repository which is no longer public or simply have it disappear is up to the user, but I cannot understand why anyone thought that the straightforward solution was to /simply delete the data/. Between this and the now common downtime, I'm increasingly worried that GitHub is simply asleep at the wheel.

Re: We lost 54k GitHub stars

#120

Post by mherdeg »

cmeacham98 wrote: post #111
vaishnavsm wrote: post #70

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…

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…

My favorite example of this is that the cloudflare.com web UI has some extremely scary buttons, like a little "bypass CDN" button with a cloud on it that will rapidly increase traffic to your site 2-100x if you accidentally click.

I mean this isn't exactly how it works. But it's a bit scary.

Post reply on HN