Paper "follow" feature #7
Comments
|
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. |
|
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. |
|
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. |
Requires BP Follow v1.3-bleeding. See #7.
|
First pass of follow functionality is up on cdev. Just going to run down the main elements. Navigation:
Auto-follow:
What isn't done:
|
|
This is pretty cool, @r-a-y ! Thanks for pushing it along.
If we're thinking about the same comments, they were a
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?
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 |
The follow papers module relies on this. See #7.
@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 - When there is more than one follower for a paper, the notification will show When there is only one follower for the paper, the notification link goes directly to the followed user's proflle with a query argument - Let me know what you think. |
|
Cool, this is very clever! Thanks, @r-a-y . The 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. |
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.
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
|
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.
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. |
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?
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.
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. |
I think this makes sense. 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. |
|
Why not make the invitation terminology something like "Share this paper with . . . . " and then call the people it's shared with Followers?
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. |
OK
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. |
|
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. |
|
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? |
|
(and I think it could be a simple icon -- not even a button) |
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. |
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.
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. |
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? |
|
Let's figure out out whether we will include the mute option and then go from there. |
|
@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.) |
|
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. |
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.
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.
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:'? |
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. |
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:
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. |
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 |
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. |
|
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:
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.
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
This would be unnecessary. Following is a separate action and the user can follow/unfollow at will.
Yes, I agree this would still apply. |
|
@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). |
|
Another correction re this point
My answer should have been yes, that's what I'm suggesting as well. |
|
@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? |
Okay -- that removes a major worry of mine. |
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. |
This replaces mythread_comment, because users are auto-followed to a paper when they comment on it. See #7.
|
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 :)
The text was updated successfully, but these errors were encountered: