I think the most important point is to mark as read notifications when we open a post in the single post view. Even if the user doesn't touch to the notification panel or page.

I read Ruxton's comment as warning against making a change which might break code/functionality for users. If this is not a danger/possibility, I would be happy to see the notification behaviour changed. But I'd like that clarified before voting.

@morgenstern you can see a preview of how this would work in @steffenvanbergerem's video here: http://videobin.org/+7h1/9s2.html

I think that's quite intuitive.

@goob The code I used for the video has not been pushed to the branch and I think I lost the code. However, rewriting that shouldn't be a lot of work.

I read Ruxton’s comment as warning against making a change which might break code/functionality for users. If this is not a danger/possibility, I would be happy to see the notification behaviour changed. But I’d like that clarified before voting.

I think Ruxton meant was not break code, but change functionality. YES keeps current functionality as default, NO changes it.

@steffenvanbergerem Oh, thanks for the clarification. I thought your video was to show me that this is how your PR will work if implemented. I could only vote for a change of functionality if it worked in the way shown in the video. If you could please clarify whether or not the functionality shown in your video would be implemented with your PR, that would help me decide how to vote on this proposal.

When I say ‘like in the video’ I mean that there needs to be a means of marking individual notifications as read in the notifications drop-down itself without clicking on a notification to be taken to that post or clicking ‘view all’ to go to the notifications page.

If this were the case, I don't think we'd need to build an option to choose between this and the current system - just change it to work in this way (which is far better, I think).

@goob I won't be able to add the user setting so I won't be able to finish my PR. Right now you can click on the notification and you won't be taken to that post. This is only the case when you click on the "post" link.

I can work on my PR again and create a similar user experience to the one you see in the video. However, like I said we still need someone to finish the PR.

Automatic is bad, but mark as read every notification one by one is not nice. We should improve the system by auto mark as read every notifications related to a post when it is open in the SPV.

If i can something else; another small improvement to notification would be the pop-up to show the last 5 UNREAD notifications instead of the last 5 notifications.

This would allow to check one by one all the notifications without having to go to the notifications page.

@morgenstern I'm still waiting for confirmation from @steffenvanbergerem as to whether the functionality shown in the video will be included in this PR. I thought it was, but apparently it is not (yet) part of it. Apologies for the confusion.

@goob

I can work on my PR again and create a similar user experience to the one you see in the video. However, like I said we still need someone to finish the PR.

Again: I am not the one who will finish this PR so I am not able to promise anything. As soon as there is someone who would like to finish the PR I will volunteer to help getting that functionality you see in the video.

Again: I am not the one who will finish this PR so I am not able to promise anything. As soon as there is someone who would like to finish the PR I will volunteer to help getting that functionality you see in the video.

@steffenvanbergerem if you could add the video functionality to the PR now, before it it taken up by someone else, that would, I think, be enormously useful. Then the other person would only need to add a user setting, and the full functionality should survive into the final merged code. Would you be happy to do that?

Would it be useful to make a post about this from the diaspora* HQ account to get some wider feedback?

@flaburgan it already works this way

@goob we are not voting on changing anything else than what should be the default way if the PR is merged in (once someone adds user settings to it). What is it that is not clear about the functionality? In any case, no functionality will be removed.

If we make the new way default it will also be consistent with the mobile page since that is how it has always worked there. Also the "mark as unread" now actually works, since it doesn't get marked read again. Having this on my pod for a while now I can say the notifications are so much more useful now.

@goob I implemented that functionality with some additional improvements in a new PR.

Thanks a lot, @steffenvanbergerem. With that, I'm happy for the auto-mark-as-read to be removed.

@goob it will not be removed - it will be available via user settings if NO passes here. If we want to remove it - we should vote separately.

@thomasl That has already been implemented and will be available on your pod after the next update.

yaaay \o/ :)

Flaburgan said:

We should improve the system by auto mark as read every notifications related to a post when it is open in the SPV.

Jason said:

@flaburgan it already works this way

@jasonrobinson no it doesn't. I open my notifications using the link in the e-mail, and my notifications counter doesn't go down. You can make the test easily, when you receive a email about a notification, check on diaspora how many unread notifications you have in the header, click on the link in the email and check again the unread notifications in the header, and you will see that it is the same number.

@fla

@flaburgan that sounds like a separate bug - I'm quite sure when clicking a post notification from the notifications menu it marks all notifications as read related to this post. I'm actually very certain. If it doesn't work that way when coming from emails then it's a bug :)

@rich1 it's only a few lines of javascript to remove from the code. Bringing in a new user setting would be extra code to maintain.