News for hackers. Stuff that matters.
Re:GitHub's new notifications: a case of regressive design by kasbah on Friday March 13, 2020 @12:32PM (#22568645)
I have been using it for a few weeks and really like it actually. It's much better than Github's old notification system, where I would click on something that I couldn't resolve there and then, it would get be marked as seen and I would inevitably forget about it. Now I am in control of what I see as done and I can easily unsubscribe from things I don't care about without unsubscribing from a whole project.

I also don't get on with Gitlab's system at all. Haven't tried git.sr.ht but this new Github design is way better than anything I have used before.

Re:GitHub's new notifications: a case of regressive design by cltsang on Friday March 13, 2020 @12:44PM (#22568738)
Agree. For me although it's not great as of now, it's already a huge improvement. I have confidence about my actions now. Notifications can be located and managed more easily.

It's good enough now for me. I hope they look into Gist next. So many missed opportunities there. Head over to Show HN and you'll find code snippet management softwares there from time to time. Almost all problems they are trying to tackle can be solved by a better GitHub Gist.

Re:GitHub's new notifications: a case of regressive design by eatonphil on Friday March 13, 2020 @12:18PM (#22568506)
I sent GitHub my own negative feedback. The worst parts for me are that I get notified about _my own actions_, and that clicking on the item that the notification is about doesn't immediately mark it as read/done. I have never seen an inbox system where clicking on an unread notification didn't automatically mark it as unread.

Additionally, clicking on "Done" once you're in the notification-specific page will navigate you away from the current page back to the notifications list. This is pretty disruptive to me.

Granted, I keep inbox 0 everywhere so my habits may be different than average.

I like that the notifications are removed in realtime from the list if you click "Read" there. (However, possibly due to varying line lengths, the page sometimes jumps while marking each item as read in the list. This is annoying.)

My guess is that the product team had a solid UX in mind but the engineering team was pushed to release before it was polished enough to be a solid improvement on the existing system.

Re:GitHub's new notifications: a case of regressive design by timdorr on Friday March 13, 2020 @12:22PM (#22568549)
> Additionally, clicking on "Done" once you're in the notification-specific page will navigate you away from the current page back to the notifications list. This is pretty disruptive to me.

But if you're done with that notification, why would you want to stick around? You wouldn't yet be done by definition.

Re:GitHub's new notifications: a case of regressive design by eatonphil on Friday March 13, 2020 @12:25PM (#22568574)
I guess that's just not how I think or how I'm used to using an inbox. I click done to get the banner out of my face. The important part was the notification not the requirement to buy into their task management system.
Re:GitHub's new notifications: a case of regressive design by est31 on Friday March 13, 2020 @03:09PM (#22570018)
Yeah that banner is annoying and takes away lots of valuable space.
Re:GitHub's new notifications: a case of regressive design by Rauchg on Friday March 13, 2020 @01:00PM (#22568905)
> I haven’t spoken to anyone who likes the new UI. Do you?

I've heard many people in our team rave about how the notifications overhaul has made them far more efficient.

https://twitter.com/timneutkens/status/1195176650008252416

https://twitter.com/timneutkens/status/1194675684020383744

Re:GitHub's new notifications: a case of regressive design by steveklabnik on Friday March 13, 2020 @01:54PM (#22569352)
I haven't heard many things about it, but what I've heard has only been positive.
Re:GitHub's new notifications: a case of regressive design by flohofwoe on Friday March 13, 2020 @01:33PM (#22569152)
It's better than the old system for sure if your code is spread over more than just a handful repositories.
Re:GitHub's new notifications: a case of regressive design by pythux on Friday March 13, 2020 @12:28PM (#22568611)
I could not really pinpoint why the new UI is bad, but it got me to finally switched 100% over to emails to manage all my GitHub notifications; I disabled them in the Web UI completely.

I find my email client (Thunderbird) and custom filters to be a much more powerful and flexible way to manage the hundreds of notifications I get every day. More than 99% of these emails are automatically sorted in folders, tagged, etc. So that I can efficiently prioritize what I look at. This saves me massive amounts of time. In the end I always have an empty inbox, which I find pretty satisfying and it helps me focus.

Re:GitHub's new notifications: a case of regressive design by listsfrin on Friday March 13, 2020 @12:29PM (#22568626)
People with Thunderbird are not their target. They want the Outlook people.
Re:GitHub's new notifications: a case of regressive design by pythux on Saturday March 14, 2020 @12:19AM (#22573150)
Re:GitHub's new notifications: a case of regressive design by einpoklum on Friday March 13, 2020 @12:57PM (#22568883)
I had tried the beta/preview, and it was terrible.

It was as though they had created a mailbox, and I was looking at a long, small-font, mailbox message list.

I'm not a design expert, but I felt annoyed and, somehow, a bit confused (?) ...

I don't understand why they would do this. Kind of reminds me of the supreme folly that is Microsoft's Metro designs.

Re:GitHub's new notifications: a case of regressive design by yxhuvud on Friday March 13, 2020 @01:42PM (#22569225)
My first reaction was similar to yours, but after using it a few weeks I much prefer it over the old notifications. Those were really bad. These are functional and I expect them to be further polished as things go by.
Re:GitHub's new notifications: a case of regressive design by jkrems on Friday March 13, 2020 @01:27PM (#22569112)
I've seen a lot of active open source users talk positively about the new design. I personally disabled email notifications completely and wouldn't want to go back. Having a clear separation between unread, read, and archived is a huge step forward.

Also, I'm not sure why it matters to have notifications grouped by repo. At least for myself it rarely made sense and only wasted space in the UI.

Re:GitHub's new notifications: a case of regressive design by wildpeaks on Friday March 13, 2020 @02:38PM (#22569765)
For me, grouping by repo was useful because I don't care about every repo equally: some produce few notifications but are extremely important, while other repos (that happen to produce a lot of notifications) aren't that important.
Re:GitHub's new notifications: a case of regressive design by jakub_g on Friday March 13, 2020 @02:34PM (#22569731)
Good thing about GitHub is that if you have email notifs enabled, they put a fake CC in the email

    {review_requested | author | assign | mention | your_activity | subscribed} @ http://noreply.github.com
Then you can create filters in your email client and sort this stuff into different subfolders.

IMO this is still not enough granular (https://twitter.com/__jakub_g/status/1222918835172495360) but overall it's quite ok. Feel free to ping GH support if you agree with my tweets so maybe this gets prioritized.

Re:GitHub's new notifications: a case of regressive design by di4na on Friday March 13, 2020 @02:40PM (#22569771)
I gave them the same exact feedback a few weeks ago. Got zero follow up so i suppose it worked for some. I will just stop using notifications i suppose.
Re:GitHub's new notifications: a case of regressive design by anonfunction on Friday March 13, 2020 @12:34PM (#22568655)
I agree and sent my own feedback, where before I had one button to click "Mark all as read" but now it's three clicks and hidden, I actually didn't know it was possible until just now when I tried it out again.

Also what does "done" even mean? If I'm mentioned in an issue but it's not closed should I mark it done?

Re:GitHub's new notifications: a case of regressive design by mugsie on Friday March 13, 2020 @04:47PM (#22570772)
I think the new one is OK for a quick overview, but I still prefer email. Sieve + this rule[1] files emails from each repo in a folder (following org structure), and I can flag things I need to come back to, mark things I don't care about as read, and have thunderbird pop a notification in the top of my screen for repos I really care about.

(I know I am definitely not the target audience for the page)

1 -

  # GitHub
  if allof(exists "X-github-recipient",
           header :regex "List-Id" "<([a-z_0-9-]+)\.([a-z_0-9-]+)[.@]") {
      set :lower "organisation" "${2}";
      set :lower "repo" "${1}";
      fileinto :create "INBOX.GitHub Code Review.${organisation}.${repo}";
      stop;
  }
Re:GitHub's new notifications: a case of regressive design by strict9 on Friday March 13, 2020 @01:12PM (#22568998)
It is still light years ahead of the slipshod UX of Gitlab.

Gitlab checks off all the feature boxes that managers love to see, but for devs that use it, it's a disjointed and inconsistent experience compared to github.

Re:GitHub's new notifications: a case of regressive design by lbotos on Friday March 13, 2020 @01:38PM (#22569182)
Examples? Would love to get your feedback to our UX team.
Re:GitHub's new notifications: a case of regressive design by ddevault on Friday March 13, 2020 @02:11PM (#22569518)
For my part, my main complaints with GitLab's UI are:

1) It's too slow. If the same UI were 2x faster it'd be a lot easier to use.

2) It doesn't meet the bare minimum of "at least do something useful" if JavaScript is turned off

3) Getting around the various tools available for a single repo is difficult

Pot calling the kettle black a bit with that 3rd one, though.

Re:GitHub's new notifications: a case of regressive design by Slippery_John on Friday March 13, 2020 @01:30PM (#22569134)
It's been great for me for one major reason: I used to work on a pretty active project, but have since moved on. I don't have time or energy to look at things from that project anymore, but notifications from issues I participated in drown out the things I'm working on now. The new UI lets me bulk unsubscribe from those issues, which has been great.

Of course, being able to just bulk unsubscribe from an entire project and all its issues from the outset would be better.

Re:GitHub's new notifications: a case of regressive design by jakear on Friday March 13, 2020 @03:30PM (#22570184)
I've been using it for several months now and at first I found it cumbersome but now its quite nice. Working on a very large OSS project, I end up with quite a few notifications. I need to be able to work through them and decide if I want to act now, later, some day, or never. The new system works perfectly for that. The article's complaints seem to be mainly about the UI/UX of the project, which IMO is not nearly as important as the Concepts (in the Jacksonian sense [1]) it empowers. UI/UXs are relatively easy and can incrementally improve over time. Concepts are difficult and heavy.

Do I have complaints regarding the UI/UX? Of course. But it's beta software, it would be insane for me not to.

[1] https://mitpress.mit.edu/books/software-abstractions

Re:GitHub's new notifications: a case of regressive design by geniium on Friday March 13, 2020 @01:11PM (#22568990)
I haven't been using it myself yet, but this afternoon a colleague just said "Whoooohaa, the new notifications screen on github's great".

Seems he was very happy to be able to manager his notifications with more "fine tuning" than before.

And you, what do you think of it?

Re:GitHub's new notifications: a case of regressive design by jeremy_k on Friday March 13, 2020 @12:53PM (#22568836)
Where is the sticky header? Scrolling down the page I don't see anything sticking to the top.

Also I didn't even know where to look to find the page. I guess I relied far more on checking my email and seeing notifications for things there and then bouncing over to Github to look at changes. Definitely going to spend a little more time trying out the notifications.

Re:GitHub's new notifications: a case of regressive design by jorams on Friday March 13, 2020 @01:41PM (#22569217)
It's on the page you see after you click on a notification.
Re:GitHub's new notifications: a case of regressive design by romanovcode on Friday March 13, 2020 @01:10PM (#22568977)
The only thing that made me go back to old design is "Mark all as read" is gone.

Who thought it is a good idea to remove that button?

Re:GitHub's new notifications: a case of regressive design by yxhuvud on Friday March 13, 2020 @01:44PM (#22569245)
You can mark all as read. To do that select all, click the ...-button and then Mark all as read.

Not super streamlined, but it definitely is there.

Re:GitHub's new notifications: a case of regressive design by lioeters on Friday March 13, 2020 @06:39PM (#22571488)
This reminded me to write some feedback for the new notification UI in GitHub. I requested a feature that was in the classic version, to hover and preview latest comment without going to another page to view what trigerred the notification. Otherwise, I'm pretty happy with some of the new features.
Re:GitHub's new notifications: a case of regressive design by eating555 on Saturday March 14, 2020 @04:22AM (#22573938)
I miss the old way that organizing notifications by repos, so that I can work on the repos in higher priority.
Re:GitHub's new notifications: a case of regressive design by simplify on Friday March 13, 2020 @01:40PM (#22569210)
I didn't like it at first, but after actually using it I find it very helpful in keeping on top of all types of things to do/watch/respond.