Hacker News Reader

Comment by jakelazaroff | Hacker News Reader

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/

View on HN

Which comes with its own problems. What if I just published something I wanted to be secret? Then I need to be able to switch it back to private, and it has to be quick, not after five minutes. Distributed systems with eventual consistency already make fixes like that hard, not to mention caches and whatever.

The GP didn’t mean “wait 5 minutes before making any action”, they meant “stage the change so the user can see the result of their action but they still has a grace period to undo it”.

Or, have there be no need to undo anything. Why should ticking the "private" flag have any effect on anything else? If you wanted an effect on something else, a separate button "Nuke all 53,675 star from this repo", with its own protections, would suffice.

How would stars and watchers work on a private repo, though?

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.

Well, they put in the time to test a massive cascading delete operation. Surly a flag would have offered far less possibility of catastrophic outcomes and therefore would been significantly easier to confidently develop and test.

Cascade delete is a less risky operation from a security stand point. There are so many edge cases where potentially sensitive information could get leaked with regards to subscribed private repos if not handled correctly. In fact I have personally filed a bug bounty with GitHub after discovering just such a bug.

I’m not saying there isn’t a better way Github could handle this situation. Just that I do sympathise with the decision to cascade delete.

If they are using a database's built in support for cascading deletes, and if the star tables are simple m2m tables (basically just 2 fk's per row), the work to implement and test cascading deletes is trivial.

Could just make them inactive for a while, but still registered.

Stop sending notifications to watchers, and replace the repo in the stargazer's starred list with a "The following starred repos are currently private and cannot be viewed:" and make the stars be remove-only for a while.

There is no undo there. 5 mins seems like a long time to you but to the bots that scrape GitHub repos for secret things, the time it took you to notice and reverse something yourself was already the time they needed.

If you made something public on GitHub that shouldn’t have been, it was immediately compromised, you just might not notice.

Making a private repo public could also be delayed.

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.

Warnings can be done completely within the frontend, that probably makes them way more desirable for the company.

Hi newbie developer here, where do i find and learn about ux design priciples like this? Just curious, thank you thank you.

"Design of everyday things" is a great book to start.

Reply on news.ycombinator.com