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

371–380 of 697 posts

Re: We lost 54k GitHub stars

#371

Post by aerovistae »

throwaway0x7E6 wrote: post #354

>There’s a confirmation box. It’s designed to stop users in a situation like mine from doing something stupid. It tells you that “You will permanently lose all stars and watchers of this repository.” That’s pretty scary. >The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a poten…

They did admit they fucked up. Then they tried to make the best of it by looking for possible ways of preventing other people from repeating their mistake.

What did you want? A blog post that says "I suck, I'm a failure, thanks for reading"? Why is this your response to someone trying to be contructive while post-morteming a failure?

Re: We lost 54k GitHub stars

#372

Post by ttty »

NorwegianDude wrote: post #326
bobbylarrybobby wrote: post #306

Earlier quoted context omitted.

You missed the nuance in the criticism of GitHub's UI. The issue is not the presence of a roadblock, but that the same roadblock is put up regardless of how "actually" destructive the action to be taken is. The same roadblock should not be used to guard against both benign and severe consequences, else you have no real way of telling what lies on the other side of the roadblock you're plowing through.

I didn't miss it, I just don't agree with it. With the name being different I'd say the roadblock is different, but you might not agree, and that's fine. I really don't care about the number of stars my project has if I'm going to make something private. It's not like most important projects sticks out by a very significant amount of stars. What percentile would? And what percentile of these occurances are on this sc…

I watched people use software for years. If you have the exact same Popup every day, you’ll get used to click ok. Has no meaning anymore. It’s in the muscle memory.

Re: We lost 54k GitHub stars

#375

Post by JJMcJ »

JJMcJ wrote: post #296
jdmichal wrote: post #114

Earlier quoted context omitted.

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 no…

> just replacing the "Yes" button Or the lazy web dialog popup with "Cancel" and "OK". So you click on "Cancel Glorping The Frobnitz" and up pops a dialog with "Cancel" and "OK". It always takes a moments thought does the "Cancel" on the popup mean cancel the cancel glorping or cancel the cancel. Since it takes literally seconds to change the button captions it might be nice to think of something clearer. Seconds if…

> mean cancel the cancel glorping or cancel the cancel.

Typing error, it should be

> mean cancel the glorping or cancel the cancel.

Re: We lost 54k GitHub stars

#376

Post by NeutronStar »

cmeacham98 wrote: post #225
wpietri wrote: post #123

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.

> 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 is applicable to almost any activity: "Sure he was driving drunk, but the car's manufacturer should have prevented that from causing any damage!" I agree that GitHub should improve the design here - privating a '10 star / 1 week old' repo shouldn'…

No post body was provided.

Re: We lost 54k GitHub stars

#377

Post by lfnoise »

bilkow wrote: post #365

I find it ironic that some people are blaming the author so bad given that Github has made the same mistake in the past and had to restore it from the backup, making it clear that the UX could be better. I get it, we should all be very cautious when doing destructive actions, but it's also specially easy to be confused by github's repository naming conventions and you're not seeing the actual repository you're making…

I find it ironic that you can't reverse a mistake on a site dedicated to a software that is all about reversing mistakes.

Re: We lost 54k GitHub stars

#378

Post by jakelazaroff »

lalopalota wrote: post #303
jakelazaroff wrote: post #267

Earlier quoted context omitted.

Just don't show them. Filter out private repos before showing a user's stars, notifying them of issues, etc.

Right, just more work. More tests. More edge cases. More time.

Sure. But that’s the cost of good UX.

Re: We lost 54k GitHub stars

#379

Post by jakelazaroff »

umvi wrote: post #274
jakelazaroff wrote: post #27

GitHub made a cardinal UX design sin here: never use a warning when you mean undo [1]. If they had given even a five minute grace period before starting the irreversible process of removing all the watchers, this wouldn’t have happened. https://alistapart.com/article/neveruseawarning/

It's understandable why warnings are used instead of undos though. Warnings are dirt simple to implement - probably a single line of code in most languages. Undo is very complex by comparison. You have to flag something for deletion and put it into some sort of deletion queue that somehow gets deleted at some future date, etc.

It’s definitely easier from the implementer’s point of view. That doesn’t make the UX any better, though.

Re: We lost 54k GitHub stars

#380

Post by apostacy »

steve_adams_86 wrote: post #301

Apart from it being clear that the UI and the user using it could have been better, I don’t agree with criticism like “GitHub should obviously do x” or “this would be easily resolved if the action didn’t caused cascading deletes” and so on. GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve hear…

Should customers who have had a bad experience just not give any feedback then?

Github should be grateful for this feedback. I know that it takes effort to make your product or service better, but that doesn't mean that customers shouldn't ever say anything. Customers are telling Github how it can improve its service. Github can choose to listen to them, or not.

With some simple frontend changes, they can probably reduce accidental destructive changes to customer's accounts.

I think Github cut some corners here. I would much rather that repo stars were treated similar to how resources on other platforms are. If someone makes it private, then return 403 "repos is private"

Post reply on HN