CUNY Academic Commons

Thanks for thinking through this, Colin.

A 'Friends' tab makes sense in the abstract, but the friendship feature on the Commons is fairly infrequently used, and doesn't really do much. So I'm unsure what the practical benefit would be of having them appear in one space.

My original thought about the Messages / Invitations / Notifications distinction was that this was a fairly neat way to describe the differences in the structure of each item:

1. Messages - Each item in the list is a "thread"; each thread has a title; threads can have multiple responses; there's a way to create new threads; there's a UI in each thread to respond to the thread; each post in a thread has text.
2. Invitations - Each item in the list is an invitation of some sort. Items do not have titles/subject lines in the same way as messages, though we could fake it with text like 'Boone has invited you to join the group...'. Invitations may come with some sort of custom text. Each invitation has available action buttons: Accept / Reject. I would argue that friendship requests belong here as well.
3. Notifications - Each item in the list is a notification. Notifications do not have titles/subject lines but we could build them similarly to Invitations. Notifications generally do not have any custom text, though in some cases they may have some text attached to them (as in the case of an @-mention, where we might include the snippet including the mention text). Notifications do not have any action buttons.

Messages are pretty clearly very different structurally from the others, and it's hard to imagine a single set of interface decisions that would cover both message threads and the other types of content. It's an interesting idea to put -mentions here, but (a) -mentions don't have subject lines, (b) they don't really occur "between" people in the same way as message threads, (c) they don't form a thread that can be replied to in the same way, while (d) they actually reference some other "primary" piece of content (such as the corresponding blog post) while in the case of messages, the "actual" content is the message itself. So they feel quite different to me.

A 'Friends' tab makes sense in the abstract, but the friendship feature on the Commons is fairly infrequently used, and doesn't really do much. So I'm unsure what the practical benefit would be of having them appear in one space.

We're currently in between designs at the moment; the current production version of bp-nelo has a "Friends > Requests" page viewable in our horizontal tab, navigation flow, but our current mockups of the new "Commons Profile" pages do not.

Depending on whether we are going to go forth with the entire Inbox page revamp as in Sara's mockups for v2.2.0, I suggested that we move the "Friends > Requests" page to "Inbox > Friend Requests" for the interim just so that there is something usable.

If we are completely reimagining the Inbox pages and not being focused on Notifications, I was kind of thinking along the lines of Colin to have an "Action Center" type page where the user needs to perform any type of important action such as approving or declining friendship requests, approving or declining new group members if you are a group admin or moderator, joining or declining group / site invites, etc.

I was also thinking the Inbox pages could be simplified to two sub pages: "Messages" and "Action Center". The main "Messages" landing page could be separated by three sections: Forum Replies, Private Messages and Mentions (although we're kind of leaving at-mentions undocumented I believe nowadays). To me, this would be better than having a waterhose of an "All Notifications" page where everything is jumbled together and items are hard to delineate what is important or not. That's my two cents, but would welcome some other thoughts.

A first pass of the new "Notifications > All" and "Notifications > Action Center" pages is ready for testing on cdev. Here's a link to Sara's mockups for comparison: https://www.figma.com/proto/c3v5FHId3eUAjZ2ennkN83/CUNY-Design---Summer-2023?page-id=3461%3A53191&type=design&node-id=3461-55432&viewport=8484%2C13384%2C0.25&t=sqKGsUW2nW5ZDQbn-1&scaling=min-zoom&mode=design .

• friendship_request
• new_membership_request
• new_invitation (this is new; see #18637)

So if you want to see any items on your Action Center page, please test by attempting to join a private group, adding a new friend or sending an invite.

• We might need to curb the number of notifications that are sent by certain types. For example, let's say I am private messaging a user and that user writes five replies to the thread, the BuddyPress Notifications module will create five separate notifications. So when I navigate to the "All" tab, you will see these five separate notifications, which can make the "All" page look rather noisy. I want to limit notification creation so only one is created per private message thread / forum topic.
• The "All" tab also mixes read notifications with unread ones. Generally, this would not be an issue except BuddyPress (and related BP plugins) errs on the side of caution and never deletes their notifications. So the "All" tab has the potential to be quite jumbled due to the number of read notifications and certain unread notifications might be missed. For testing, I have left the "Unread" and "Read" tabs so you can toggle between the different states.
• Due to limitations with BuddyPress Notifications, most notifications will need to be re-formatted to fit our new design. BuddyPress doesn't format the notification text in a user context and BuddyPress also hyperlinks the entire notification, while our formatted notification might have more context and we also do not want to hyperlink the whole notification. I've already formatted some of those notifications here: https://github.com/cuny-academic-commons/cac/blob/b7b1363767f4f694a52e7c4ba6bfb69aba64fed1/wp-content/themes/bp-nelo/members/single/notifications/notifications-loop.php#L83-L89 , but we will probably need to format a few more notification types as we spot them.
• At-mention notifications now link directly to the mentioned item. If you are mentioning someone in a forum topic, the notification will link directly to that forum post instead of the "Activity > Mentions" tab, which we are no longer using. I still need to work on marking that notification as read when you click on it though.
• We are currently hiding the older "Invites" nav item and have moved a few of the invite nav sublinks such as the "Invite Members" and "Claim an Invitation" links to the new "Action Center" page. For power users, I think we might need to re-surface a link to the "Invitations Sent" page so inviters can determine the status of an invite sent to other users. I'm not sure if many current users actively go to their "Invites > Invitations Sent" page, but I wanted to flag this for discussion. To offset this, I've added a new BuddyPress notification that is sent to the inviter whenever an invite is accepted or rejected (see #18637).

Awesome, Ray!

We might need to curb the number of notifications that are sent by certain types. For example, let's say I am private messaging a user and that user writes five replies to the thread, the BuddyPress Notifications module will create five separate notifications. So when I navigate to the "All" tab, you will see these five separate notifications, which can make the "All" page look rather noisy. I want to limit notification creation so only one is created per private message thread / forum topic.

Yes, I agree that these should be throttled. One per thread/topic sounds appropriate to me. Probably best to prevent the redundant notifications from being created in the first place, rather than trying to filter them out at the time of display, right?

Would it make sense to simplify it so that messages are excluded from the notification section

I love this idea, Sara! As well as excluding private messages from the Notifications page, we can also stop recording separate notifications for private messages. What do you think, Boone?

Yes, let's prevent those notifications from being created by BP.

Yes, let's prevent those notifications from being created by BP.

Done in https://github.com/cuny-academic-commons/cac/commit/c7a0ac13f43b393c0fc374a39dd65b3023bc50db .

but on my CDEV account I was getting a discrepancy between my count in the Notifications tab (4 count) and in what was being displayed in the Buddypress icon overlay badge (3 count)

The icon overlay badge was using a different count technique. I've just changed the icon overlay badge count to use the same one that BuddyPress uses for the Notifications tab. See https://github.com/cuny-academic-commons/cac/commit/0e4a4458022e036d25475e243718fa2a4b972284 .

I noticed a small bug: the search bar on the inbox page is broken a pixel off partway

Thanks Sara. Should be fixed now. This is available for testing on cdev.