Open boonebgorges opened 9 years ago
r-a-y
commented
9 years ago I've been thinking about making this more general and having a Follow Activity module in BP Follow.
This would only work if activity comment syncing is enabled, which ties in with the work imath has been doing in BP Core. We would get email notifications for free this way as well.
boonebgorges
commented
9 years ago Oh, that is a pretty good idea. We'll still want to have separate directories for followed papers vs followed sites vs followed whatevers, though - the fact that they all run through the Activity component will be largely invisible to the user.
boonebgorges
commented
8 years ago See #18. I'm going to start working on access control, which I think is pretty much independent of the Follow feature, though I think the two will interact in some ways.
r-a-y
commented
8 years ago First pass of follow functionality is up on cdev.
Just going to run down the main elements.
Navigation:
Papers I Follow tab on the Papers directory, which displays all followed papers.Papers > Followed Papers page on a user's profileActivity > Papers page on a user's profileMy Papers filter on My Commons (CAC-only)Auto-follow:
Settings > Notifications page.What isn't done:
follow_paper_{PAPER_ID}.boonebgorges
commented
8 years ago This is pretty cool, @r-a-y ! Thanks for pushing it along.
I saw some comments in the code about a notifications directory.
If we're thinking about the same comments, they were a @todo about where screen notifications like "There are three new comments on papers you follow" should go - since presumably they'd be different papers. Maybe to My Papers? I dunno. Or maybe we can split up the joined notifications so that they're grouped only per-paper. Not sure if BP will even allow us to do that. But yeah, if you can filter the notifications with a URL query arg, so that you only see the relevant ones, I guess that's a good solution too.
Follow button on the paper page. I think there should be a follow button on the paper page. Just need to think of a good spot to put it.
This seems critical to me. I was thinking something prominent, like a big star (yellow when following, white when not) right next to the paper title. @samradd do you have thoughts about this?
Show followers of a paper on the paper page? in the paper directory loop?
I think it'd be OK to leave this off. The only person it should really matter to is the paper author, and even to them, do we really need this? In any case, I'd say it can be deprioritized for v1.
Small note - I see how you're handling the non-sending of duplicate notifications, using did_action(). This is clever, but obviously quite awful :) You and I should put our heads together - not now, but at some point - about how to solve this kind of problem, maybe at the BP level with a centralized API for registering outgoing email notifications.
r-a-y
commented
8 years ago If we're thinking about the same comments, they were a @todo about where screen notifications like "There are three new comments on papers you follow" should go
Or maybe we can split up the joined notifications so that they're grouped only per-paper.
@boonebgorges - For screen notifications when a user follows a paper, this is what I've done in commit 90b65f2.
When recording a follow paper notification, I use a dynamic component action - follow_paper_{$paper_id} so the user will see separate notifications for each paper.
When there is more than one follower for a paper, the notification will show X members started following your paper "foo". This links to the user's unread notifications with a query argument - ?spfilter (see commit adcb15f) - that filters the unread notification loop to show all followers for all of the logged-in user's papers.
When there is only one follower for the paper, the notification link goes directly to the followed user's proflle with a query argument - ?spf_read - that I use to mark the notification as read.
Let me know what you think.
boonebgorges
commented
8 years ago Cool, this is very clever! Thanks, @r-a-y .
The spfilter trick probably is worth looking into for BP. I can see use cases where you might want to filter notifications based on a query param, even if this isn't something we support with any UI at the moment.
I'm trying to think if there are any potential problems with dynamic notification types. If this were the activity component, there may be issues: you'd need some middleware to allow things like dropdown filters on the activity directory and the Activity Dashboard panel. But we don't really do anything like that for notifications.
samradd
commented
8 years ago A user can also manually follow a paper on the Paper Directory page by clicking on the "Follow" button. If someone manually follows a paper, the paper author will receive an email notification. This email notification can be disabled from a user's Settings > Notifications page.
Will all of these emails be controlable via Settings > Notifications or will users be able to opt out of receiving notifications for specific papers within the notification emails? I'm worried that users may not clearly associate 'follow' with 'receive email' and I want to make sure they have a way of getting people into their 'followed' tab without also receiving emails, if they'd like.
Follow button on the paper page. I think there should be a follow button on the paper page. Just need to think of a good spot to put it.
For CAC: wouldn't it make the most sense to borrow the same convention we use for sites and put it on the bottom right of the page?
In general: Now that we have more information at the top of the page with the author/published/private/public info at the top, let's include it there. I want to separate what's a button/controllable by the user and what's metadata provided by the system, so I think something like this would work best:
We could include a star on the button if you'd like, but we at least need to include text with the icon, no matter what. Starts mean a lot of things across a lot of different popular interfaces right now (favorite, like, follow) so we need to be clear. I borrowed the button styling from the Post Comment button at the bottom of the papers page.
Following vs Reading I've thought about this for a while, and I think we need to either 1) remove the option of 'Reader' or 2) maintain a clear delineation between Readers and Followers throughout the interface. More detail:
r-a-y
commented
8 years ago Will all of these emails be controlable via Settings > Notifications or will users be able to opt out of receiving notifications for specific papers within the notification emails?
Good question. I did this to notify a paper author of a follower originally, but IMO yes, we should give users the option to disable email notifications of all sorts. I'll wait for others to chime in.
For CAC: wouldn't it make the most sense to borrow the same convention we use for sites and put it on the bottom right of the page?
I'm not sure that would be the best thing here. Following a site is different than following a paper, so we shouldn't mix these two types of following together. We would also want the follow paper button to be prominent (as detailed in your screenshot). The follow site button is a little passive, which was the intention.
I think we shouldn't even be showing the followed sites footer block on the main CAC site as there isn't anything to follow on the main site; no blog posts are ever published there.
I would say that your screenshot describing the general use-case should be implemented on CAC as well.
boonebgorges
commented
8 years ago IMO yes, we should give users the option to disable email notifications of all sorts
It would be great for users to have fine-grained control over emails that they receive. But where do these controls live? What does the UI look like, and where in the larger interface do we put it?
Remove the option of 'Reader'
Currently, authors can toggle users in and out of the Readers section. Switching this so that it's an "invitation" rather than a setting will mean that authors cannot revoke access.
Maintain a clear delineation between Readers and Followers throughout the interface: Keep the two uses separate and allow a follow-opt-in for readers. So, when a reader is added the paper is just added to their shared papers tab and they receive an email that it has been shared with them. They are not automatically following a paper and therefore they are not automatically receiving other emails about it. They then have the option to follow the paper to receive notifications -- this would mean that papers may be duplicated in user's 'shared' and 'followed' tabs.
It seems to me that, 95% of the time, people added to a paper will want to follow it. Forcing another step seems like an unnecessary hurdle.
Here's another thought: The only person who ever sees the word "Reader" (we can pick a better word if you want) is the paper author. There would be no such thing as a "Shared with me" or "Papers I am a reader of" tab on the directory, there would be no "x readers" counts anywhere in the interface, and there would be no email that says "You are now a reader on paper x". When an author adds a user as a reader, the user autofollows the paper, and receives an email to that effect (perhaps with the language "You are now following paper X, by an invitation from Sam"). Users may then unfollow as they wish.
I'd like us to try for the minimal interface and minimal amount of settings here. Let's not create additional tabs and additional toggles just for the sake of logical completeness.
mkgold
commented
8 years ago Here's another thought: The only person who ever sees the word "Reader" (we can pick a better word if you want) is the paper author. There would be no such thing as a "Shared with me" or "Papers I am a reader of" tab on the directory, there would be no "x readers" counts anywhere in the interface, and there would be no email that says "You are now a reader on paper x". When an author adds a user as a reader, the user autofollows the paper, and receives an email to that effect (perhaps with the language "You are now following paper X, by an invitation from Sam"). Users may then unfollow as they wish.
I think this makes sense. And I would suggest doing away with the "Reader" terminology entirely. Why can't we just use Followers?
boonebgorges
commented
8 years ago And I would suggest doing away with the "Reader" terminology entirely. Why can't we just use Followers?
"Reader" is a way of giving someone permission to read your paper. If reader==follower, then if a user decides to unfollow a private paper, they'll no longer have access to it. This, in turn, will likely mean that we need a workflow for unfollowing private papers that's different from following public papers, since it's irreversible. It also means that, if/when we start exposing "Follower" data to paper authors, it will mean something different in the case of private and public papers; for private papers, it's a list of people you've permissioned to read, while for public, it's a measure of popularity.
If a hard link between paper permissions and paper notifications is what people want, then I can start working it.
mkgold
commented
8 years ago Why not make the invitation terminology something like "Share this paper with . . . . " and then call the people it's shared with Followers?
This, in turn, will likely mean that we need a workflow for unfollowing private papers that's different from following public papers, since it's irreversible.
I'm not sure I agree with that. If they consciously unfollow, then they are giving up access. What I think is needed is a way of muting notifications even for papers you follow, so that you don't receive email updates.
boonebgorges
commented
8 years ago I'm not sure I agree with that. If they consciously unfollow, then they are giving up access.
OK
What I think is needed is a way of muting notifications even for papers you follow, so that you don't receive email updates.
Getting notifications of paper activity is, as far as I understand it, the very center of what it means to "follow" a paper. If we need per-paper toggles for this stuff, we'll need a pretty extensive settings UI.
mkgold
commented
8 years ago Getting notifications of paper activity is, as far as I understand it, the very center of what it means to "follow" a paper. If we need per-paper toggles for this stuff, we'll need a pretty extensive settings UI.
I hear you on that, though there are other benefits to following a paper (ie, it shows up in your list of followed papers).
Let's think through the simplest possible way to mute/unmute email notifications -- even just as a thought experiment. I think it could possibly be done without extensive UI changes or settings.
r-a-y
commented
8 years ago Simplest way is to add paper-related options on the "Settings > Notifications" page for all the other email types:
Users can then toggle these options off if they do not want emails for certain paper actions.
mkgold
commented
8 years ago Thank you, Ray. Isn't the simplest possible way to have a mute/unmute button on the paper itself? I realize that it would add another button to the interface, but why would anything else be needed?
mkgold
commented
8 years ago (and I think it could be a simple icon -- not even a button)
r-a-y
commented
8 years ago Isn't the simplest possible way to have a mute/unmute button on the paper itself?
For consistency's sake, I would say we should keep email-related options on the "Settings > Notifications" page. Every other email option we have in BuddyPress is located there (with exception to groups). This is also more granular than a mute button (could be seen as a pro or con).
Muting papers is another feature, which wasn't brought up until just now and introduces another UI element. This also has consequences when we decide to introduce a general "mute" option into the activity stream / My Commons.
mkgold
commented
8 years ago For consistency's sake, I would say we should keep email-related options on the "Settings > Notifications" page.
I am not sure I agree with this, as we've already said that settings page is overwhelming . . . .and I think that Papers are discrete enough from the rest of the Commons that it makes most sense for people to be able to toggle notifications on or off from the papers themselves.
Muting papers is another feature, which wasn't brought up until just now and introduces another UI element. This also has consequences when we decide to introduce a general "mute" option into the activity stream / My Commons.
I did mention this earlier but I fully admit that it wasn't on our MVP. And I am fine if we decide to boot it from the MVP. But I do think that implementing a simple on/off toggle here, through a small visual icon, could help solve some of the thornier terminology issues we are facing above.
r-a-y
commented
8 years ago I am not sure I agree with this, as we've already said that settings page is overwhelming
I've already added one option to the "Settings > Notifications" page to toggle if post authors should be notified of new followers... should I remove this option so we can discuss muting individual papers in a later milestone?
mkgold
commented
8 years ago Let's figure out out whether we will include the mute option and then go from there.
boonebgorges
commented
8 years ago @samradd Can you please chime in on this? Matt wants a "Mute" button, but I don't know how to put this in the interface in such a way that it's relationship with "Follow" is fairly clear. (One can only mute/unmute a paper if one follows the paper.)
profstein
commented
8 years ago Hi all, I'd like to chime in on this too. Overall I think this might be easier if we work with Erin to get a couple of specific users and use cases for the MVP. That could help focus decisions on what to do and not do.
For the current discussion I am in favor of keeping it very simple in the following ways:
My suggestions are based some assumptions: if a Paper is private (invite only) then there will be a relatively small group of people involved who will know each other and there is no need to distinguish between reading and following; if a Paper is public then the author is open to comments from everyone and expects that so again there is not much benefit in segmenting out a group of readers separate from followers; it is easier for users to understand one Read/Follow option than two. My assumptions for not having a mute button are: unfollowing is equivalent to the mute button and probably the best choice for public papers; for private papers there is most likely a relationship and other factors that will mean followers want/need to know what's going on and as deadlines pass activity will naturally fade on its own; for those who don't want email notifications the Settings allows them to mute them all.
We may want to have separate discussions on ways to surface the Settings and maybe ways to allow people to sort how they see papers in the Followed Papers tab of My Papers.
samradd
commented
8 years ago (From Chris) There is no Mute button. In the Settings under Notifications there are two areas: My Papers heading with a No/Yes option under that for "A member follows a paper that you authored" (remove the word "manually" from the current text under the Follow heading). Papers I Follow (or Papers I'm Reading) heading with the No email ... All Email options we have for groups. There would be one setting for all papers none for individual papers.
I agree that adding a "mute" button into the mix with 'Follow' is going to compound the problem, not solve it -- at least in the CAC world. The settings area is a mess, yes, and we should address that someday! But if we're able to include settings we at least have a place to point users if they would like to turn off these types of notifications.
(from Chris) There is not two options (Reader/Following), just one. We may want to use Reading as the singular option if we think it should be differentiated from following sites. Sharing is fine as a verb to indicate that you are inviting someone to read/follow a paper (and as the only way someone can read/follow a private paper).
I also agree that maintaining both the 'reader' and 'follower' language is confusing and we need to narrow it down. I don't think this solves our issue of differentiating when people are able to view a private paper and when they want to receive email notifications about it.
(from Boone) Here's another thought: The only person who ever sees the word "Reader" (we can pick a better word if you want) is the paper author. There would be no such thing as a "Shared with me" or "Papers I am a reader of" tab on the directory, there would be no "x readers" counts anywhere in the interface, and there would be no email that says "You are now a reader on paper x". When an author adds a user as a reader, the user autofollows the paper, and receives an email to that effect (perhaps with the language "You are now following paper X, by an invitation from Sam"). Users may then unfollow as they wish.
I think this might be the closest solution we have for our beta release. Using the language 'following' in the email notification to the recipient user at least signals to them that they can 'unfollow' the paper to get out of the emails.
If someone Unfollows a private paper, it would then be taken out of their 'Papers I follow tab' and then only appear in their 'All Papers' list, so they still can access it.
As far as the author-settings language, how about we remove the word 'Readers' entirely and do something more along the lines of 'Allow these users/groups to see this paper:'?
boonebgorges
commented
8 years ago I think this might be the closest solution we have for our beta release. Using the language 'following' in the email notification to the recipient user at least signals to them that they can 'unfollow' the paper to get out of the emails. ... As far as the author-settings language, how about we remove the word 'Readers' entirely and do something more along the lines of 'Allow these users/groups to see this paper:'?
The thing about "Allow these users/groups to see this paper" is that group-linking actually does more than Readers: it whitelists the group members and it adds paper activity to the group activity stream. (Kinda like Follow for groups.)
I am fine with not using the Readers language, but the discussion on this ticket shows how hard it is to come up with an alternative! How about if we axe the Readers heading, and then when you select Private, the user selector shows up in a way that makes it clearer that it's related to Private, with language like "The following users have access to the paper"?
Either way, it'd be great to get some sign-off on this ASAP - I need some time to implement so that we can hand off the UI to the team for documentation.
samradd
commented
8 years ago How about if we axe the Readers heading, and then when you select Private, the user selector shows up in a way that makes it clearer that it's related to Private, with language like "The following users have access to the paper"?
This sounds like a good solution to me, at least until we can get user feedback to see if we've made it clear enough!
mkgold
commented
8 years ago How about if we axe the Readers heading, and then when you select Private, the user selector shows up in a way that makes it clearer that it's related to Private, with language like "The following users have access to the paper"?
This sounds like a good solution to me, at least until we can get user feedback to see if we've made it clear enough!
I can agree to this.
I am unclear whether, in saying no to a mute button, we would be taking up this suggestion from Chris:
There is no Mute button. In the Settings under Notifications there are two areas: [etc]
Let's imagine that Social Paper is a huge success, and that a user -- Erin -- has created 15 papers and is a reader on 40 papers. If we go with the solutions offered by Ray and Chris, which involves adding controls for email notification controls for each of those papers to the existing BuddyPress notification settings (again, a page we've said is already overwhelming), then we are talking about adding 55 new rows/settings to that page. And how will the papers be differentiated? By Title? What if the titles are unclear?
Wouldn't it be so much simpler to have a simple yes/no (mute/unmute) control on the paper itself?
That way, you get an email notification and you realize that you no longer want to hear about that paper. Rather than clicking a link and going to a control panel that looks like something out of an airplane cockpit, you go to the paper itself and click a button to stop notifications. To my mind, this would be a much better user experience than going to a crazy busy notifications page that covers everything from group notifications to paper notifications.
I am willing to back down on this, especially for the MVP, but I have yet to be convinced that from a usability standpoint, users will prefer to visit a huge, complicated notification settings page rather than the paper itself.
boonebgorges
commented
8 years ago Wouldn't it be so much simpler to have a simple yes/no (mute/unmute) control on the paper itself?
There already is: it's called Follow/Unfollow.
Mute/Unmute alongside Follow/Unfollow, whether on the paper or on a unified notifications page, is unwieldy both from a UI and from a data schema point of view. If we decide that we need mute in addition to follow in the future, we can always add it. If we add it now and people don't like it, it'll be hard to take away.
FWIW, I agree with Matt that the Notifications panel is not a good (primary) place to handle paper following settings. I think it's fine as an optional, secondary interface.
We are bouncing around a lot of ideas, but we actually have to build something. So, in the absence of someone else making the call, let's do this:
@r-a-y I may not have time to work on this tonight, but I will try to do it tomorrow. If I start working on it, I'll drop a note in the Gitter room so that we don't overlap. Please do the same if you get to it first :-D
mkgold
commented
8 years ago Wouldn't it be so much simpler to have a simple yes/no (mute/unmute) control on the paper itself? There already is: it's called Follow/Unfollow.
True, but for private papers, that also completely removes read access.
boonebgorges
commented
8 years ago True, but for private papers, that also completely removes read access.
No, it doesn't. "Readers" are those with read access, as determined by the paper author. "Followers" are people who receive notifications about the paper. When a user becomes a Reader, she is automatically added as a Follower. She then has the option to unfollow, at which point she will no longer receive notifications. But she'll still have access to the paper, so long as she's listed by the author as a Reader, either by accessing the URL directly or clicking on the paper from one of the various directories.
chris0stein
commented
8 years ago Matt, thanks for that concern. I share it too and in fact I wasn't thinking of adding a setting for each paper but having a broad global setting that would apply to all papers you follow or have authored. Here is an example:
@boonebgorges you added your comments in as I was writing so I hope my comments apply to you as well.
It's easier to think of Following and Reading/Viewing. Viewing relates to your ability to to see and comment on a paper. Following relates to whether you receive notifications on a paper. My other suggestion is that the only way someone can Follow a paper is by clicking a Follow button. When an author shares a paper with a person or group they are simply giving the Viewing status on the paper. For public papers this would be redundant but allowed as it could serve to allow someone to notify someone about a paper. For private papers the sharing would allow the person or group to see the paper in the list of papers and to add comments to the paper. They would not automatically follow the paper or get notifications. The person would also see a follow button for the paper. Clicking that would start notifications. Unfollowing the paper would not someone's ability to view a paper as they are separate functions.
If someone shared a paper with an individual we could add the button to follow it in the share message. If the person doesn't follow the paper they could do it later by finding the paper in the global directory or the author's list of papers.
If the author revokes the sharing then Following would also be removed if the person had followed the paper.
To address Boone's bullets:
The Readers header on the settings panel will be removed, and the language changed so that it's clear that the user-selection interface is closely tied to the Private status
My suggestion is to keep the reader section for private papers. This is a list of people who can view and comment on the paper. The only way someone can get on the list is if the author invites them.
When a user is added as a [Reader/Permissioned Person/Whatever Term People Aren't Confused By], they will be autofollowed, and get an email that says as much.
I would change this so that adding as a reader just changes the view/comment permission. The user would still have to click a Follow button to follow. If they don't click to follow they will still be able to see the paper
From this point, the user has the option to unfollow, just as if they'd followed the paper organically. If the user unfollows a private paper, they'll still have the ability to refollow, as long as they're still whitelisted (by the author) for the paper. They'll also see the paper in directories.
This would be unnecessary. Following is a separate action and the user can follow/unfollow at will.
We should double-check that users following a private paper are auto-unfollowed when their Reader status is revoked.
Yes, I agree this would still apply.
chris0stein
commented
8 years ago @boonebgorges You added your response again as I was typing, you're too fast for me. I think we are basically on the same page except that I'm suggesting we don't auto follow anything and allow people to decide whether or not they will follow a paper (authors will decide whether or not someone or some group can read a paper).
chris0stein
commented
8 years ago Another correction re this point
From this point, the user has the option to unfollow, just as if they'd followed the paper organically. If the user unfollows a private paper, they'll still have the ability to refollow, as long as they're still whitelisted (by the author) for the paper. They'll also see the paper in directories.
My answer should have been yes, that's what I'm suggesting as well.
boonebgorges
commented
8 years ago @chris0stein Yeah, it sounds like you and I are pretty much on the same page. I am fine with dropping auto-follow if it makes everything simpler to understand. If someone gets an email saying they were invited/added to a paper, it's likely they'll click through and follow themselves.
The one bit that seems weird to me is showing the Reader/Viewing stuff on public papers. As you note, it's redundant. I guess it could act like an "invitation" mechanism?
mkgold
commented
8 years ago True, but for private papers, that also completely removes read access. No, it doesn't. "Readers" are those with read access, as determined by the paper author. "Followers" are people who receive notifications about the paper. When a user becomes a Reader, she is automatically added as a Follower. She then has the option to unfollow, at which point she will no longer receive notifications. But she'll still have access to the paper, so long as she's listed by the author as a Reader, either by accessing the URL directly or clicking on the paper from one of the various directories.
Okay -- that removes a major worry of mine.
mkgold
commented
8 years ago I wasn't thinking of adding a setting for each paper but having a broad global setting that would apply to all papers you follow or have authored.
Thanks, Chris. That would definitely solve the issue I raised before, but at a significant cost -- I think that people should ultimately be able to control notifications for individual papers. But that definitely does not need to be part of the MVP and we can do some user testing to see how people react/are using SP as we move forward to determine the best course of action.
boonebgorges
commented
8 years ago I did some work on this tonight, and I think it's pretty close. On Chris's suggestions, I did not change the appearance of the Readers section in the settings sidebar. But I did remove auto-following when a user is added to the Readers list. I also added a Follow/Unfollow button to individual papers, to make possible the workflow of being added to as a reader to a private paper -> getting an email notifying you of the fact -> clicking through to the paper -> following the paper.
In addition, I set up notifications for Follow, so that users following a paper should get email notifications whenever the paper gets a comment or an edit (unless they themselves are the people who made the comment/edit). As in the case of activity, "edit" notifications are throttled to one per six-hour period.
I think this'll work pretty much like the Blog follow plugin works, thus the assignment to @r-a-y :)