Project

General

Profile

Actions

Design/UX #18150

closed

Design/UX #17385: Profile CV & Account Settings

Inbox tab

Added by Colin McDonald 11 months ago. Updated 2 months ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
-
Target version:
Start date:
2023-08-21
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Deployment actions:

Description

Setting up another subtask of #17385 to talk more about the Inbox tab, since Ray has moved the Settings tab along so much in #17769 and we have some time to look at Sara's unfinished-but-substantial work on the Inbox tab here still before she returns. Sara left this mockup:

https://www.figma.com/proto/0Ke5bCwheE5SXXkT6wDd2l/CUNY-Design---Spring-2023?page-id=2900%3A84364&node-id=2903-93408&viewport=4098%2C6553%2C0.13&scaling=min-zoom

Ray had this point a while back in the Settings ticket:

- I remember Sara showing a mockup of a Commons Profile with three navigation rows. Right now, some of the Commons Profile and Inbox pages would benefit from having three rows such as "Commons Profile > Events" and "Commons Profile > Friends" and all the "Inbox" pages. I guess the subnav items for Events such as "Events > Manage" and "Events > Create" can be moved up to the Events Directory level, although "Events > Manage" has some items that are more specific to the current user such as the private iCalendar URL. The "Commons Profile > Friends > Requests" will probably be replaced with the new "Inbox" page, however we could probably move "Commons Profile > Friends > Requests" to "Inbox > Friend Requests" for now?

Boone helped get this planning started in #17677 when he broke out current notification types and cut a few out. Sara's page 3 mockup lists all of those out. I think we still need to decide on how to distribute those across the three proposed Inbox tabs of Messages, Notifications, and Invitations.

Boone also made the point that notifications can be divided up into those that require followup (like someone requesting group membership, and you're the admin) and those that are just informational (like someone accepting your friendship request).

I'm now wondering, looking back at all of this, if Messages, Notifications, and Invitations is the proper logic/language for the Inbox sub tabs. It seems like a lot of items would end up under Notifications, like this breakdown, and it may be difficult for users to differentiate between them at a glance:

Messages:
11. new_message - Created by BP for user A when A receives a private message

Notifications:
1. bbp_new_reply - Created by bbPress for user A when user B posts a reply to a forum topic or reply written by A.
2. friendship_accepted - Created by BP for user A when user B accepts a friendship request that A sent to B.
3. friendship_request - Created by BP for user A when user B sends a friendship request to A.
5. membership_request_accepted - Created by BP for user A when A requests membership in a group, and the group's admin approves the request
6. membership_request_rejected - Created by BP for user A when A requests membership in a group, and the group's admin rejects the request
7. member_promoted_to_admin - Created by BP for user A when A is promoted in a group from 'member' to 'admin'
8. member_promoted_to_mod - Created by BP for user A when A is promoted in a group from 'member' to 'mod'
9. new_at_mention - Created by BP for user A when A is at-mentioned anywhere tracked by BuddyPress. Notably for our purpose, this includes blog posts, blog comments, forum posts.
10. new_membership_request - Created by BP for user A when A is the admin of a private group, and user B requests membership in that group
12. pending_booking - Created by the events-manager plugin for user A when user A has created an event with booking, and user B books for that event. events-manager is not a plugin that we run on the main site, so this must be something that happens on secondary sites

Invitations:
4. group_invite - Created by BP for user A when user B invites A to join a group.
***Should/can private site invites be shown here?

Is another possible breakdown something like this, with more specific tab titles?

Messages
1. bbp_new_reply - Created by bbPress for user A when user B posts a reply to a forum topic or reply written by A.
9. new_at_mention - Created by BP for user A when A is at-mentioned anywhere tracked by BuddyPress. Notably for our purpose, this includes blog posts, blog comments, forum posts.
11. new_message - Created by BP for user A when A receives a private message

Friends
2. friendship_accepted - Created by BP for user A when user B accepts a friendship request that A sent to B.
3. friendship_request - Created by BP for user A when user B sends a friendship request to A.

Groups & Sites
4. group_invite - Created by BP for user A when user B invites A to join a group.
5. membership_request_accepted - Created by BP for user A when A requests membership in a group, and the group's admin approves the request
6. membership_request_rejected - Created by BP for user A when A requests membership in a group, and the group's admin rejects the request
7. member_promoted_to_admin - Created by BP for user A when A is promoted in a group from 'member' to 'admin'
8. member_promoted_to_mod - Created by BP for user A when A is promoted in a group from 'member' to 'mod'
10. new_membership_request - Created by BP for user A when A is the admin of a private group, and user B requests membership in that group

Not sure:
12. pending_booking - Created by the events-manager plugin for user A when user A has created an event with booking, and user B books for that event. events-manager is not a plugin that we run on the main site, so this must be something that happens on secondary sites

And could we also just have an All tab where you see everything?


Files

Screenshot 2023-09-20 at 9.41.10 PM.png (629 KB) Screenshot 2023-09-20 at 9.41.10 PM.png Sara Cannon, 2023-09-20 10:46 PM
same-notify-numbers.png (166 KB) same-notify-numbers.png Colin McDonald, 2023-09-21 05:07 PM
different-notify-numbers.png (222 KB) different-notify-numbers.png Colin McDonald, 2023-09-21 05:07 PM
Screenshot 2023-10-10 at 9.06.11 AM.png (45.7 KB) Screenshot 2023-10-10 at 9.06.11 AM.png Sara Cannon, 2023-10-10 10:10 AM

Subtasks 1 (0 open1 closed)

Feature #18637: Invites do not create a BP notificationResolvedRaymond Hoh2023-08-21

Actions
Actions #1

Updated by Boone Gorges 11 months ago

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.

Actions #2

Updated by Raymond Hoh 11 months ago

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.

Actions #3

Updated by Raymond Hoh 6 months ago

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 .

The new "Action Center" page only shows notifications by the following types:
  • 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.

Some implementation notes:
  • 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).
Actions #4

Updated by Boone Gorges 6 months ago

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?

Actions #5

Updated by Sara Cannon 6 months ago

When you receive a private message, your top bar gets a 2-count notification. One under Notifications and one under Messages. Would it make sense to simplify it so that messages are excluded from the notification section so that when you receive a message, you see the notification count only under messages and not notifications?

Actions #6

Updated by Raymond Hoh 6 months ago

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?

Actions #7

Updated by Boone Gorges 6 months ago

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

Actions #8

Updated by Colin McDonald 6 months ago

I'm not too sure what's happening here, 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). See attached. Then when I accepted a membership request, both went down to 2 count. Also attached.

Actions #9

Updated by Raymond Hoh 6 months ago

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 .

Actions #10

Updated by Sara Cannon 5 months ago

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

Actions #11

Updated by Raymond Hoh 5 months ago

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.

Actions #12

Updated by Boone Gorges 2 months ago

  • Target version set to 2.3.0
Actions #13

Updated by Boone Gorges 2 months ago

  • Status changed from New to Resolved
Actions

Also available in: Atom PDF