Project

General

Profile

Feature #120

Consider Adding Privacy Options Plugin for Profiles

Added by Matt Gold almost 12 years ago. Updated about 6 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
BuddyPress (misc)
Target version:
Start date:
2009-12-05
Due date:
% Done:

0%

Estimated time:

Description

Very much excited to see this: http://jeffsayre.com/2009/12/05/buddypress-privacy-component-released/

It's in beta, so we may want to wait on it, but this is something that users have asked for.


Related issues

Blocked by CUNY Academic Commons - Bug #1959: Upgrade to BP 1.6Resolved2012-06-21

History

#1 Updated by Boone Gorges almost 12 years ago

I will install it in a test environment and play with it, but I want to wait until it's been used by the community for a while before considering it on this site. It has the potential to permeate and thus screw up nearly every part of the site.

#2 Updated by Boone Gorges over 11 years ago

Would prefer to wait until after we upgrade to latest BP, as the Privacy plugin is not supported on legacy versions.

#3 Updated by Boone Gorges over 11 years ago

Still waiting on Jeff. Moving this to Features rather than Bugs

#4 Updated by Boone Gorges over 11 years ago

  • Tracker changed from Bug to Feature

#5 Updated by Boone Gorges over 11 years ago

I talked to Jeff yesterday, and it sounds like he's shooting for a release within a week or so of the BP 1.2.6 release. Once it's out, I can start looking at it on some local installations. In any case, we'll have to upgrade to BP 1.2.6 first (it's not out yet)

#6 Updated by Boone Gorges over 11 years ago

  • Target version set to Future release

#7 Updated by Boone Gorges over 10 years ago

  • Target version changed from Future release to 1.3

I don't think that we will be using Jeff's plugin, but we'll be doing something for the 1.3 release.

#8 Updated by Matt Gold over 10 years ago

Cool -- this will be big. At some point, we should talk about what kinds of privacy to enable.

#9 Updated by Boone Gorges about 10 years ago

Can we have a discussion about how this should work? There are a couple areas where I have questions.

- Levels of privacy. For a community like the Commons, I think that having two options makes sense: public, and visible only to logged-in members. This also has the advantage of being pretty easy to implement. Doing it on a "friends" basis is more complicated, and, I think, not in keeping with the goals of the Commons.

- Breadth of settings. Do we give a public/private setting for the profile as an entire unit? Or, on the other end of the spectrum, do we allow each profile field to be marked public vs private? The former is easier to implement. If we go with the latter, we should be careful not to overwhelm people with a sea of options. We could provide sensible defaults for each field (presumably phone and email would be private by default, college affiliation public), which might at least ease the tendency to have the privacy settings be overcomplex.

#10 Updated by Matt Gold about 10 years ago

Happy to have this discussion here and also at our meeting on Friday.

-- Levels of privacy -- I very much like your ideas here. Yes -- public/visible only to community (ie., logged in users)

-- Breadth -- I'd love to see users have fine-grained control over the privacy of every item in their profiles, but I agree that we want to beware of an overwhelming panoply of options. Having sensible defaults is a great idea. We can also have a global checkbox that sets most items (excluding whichever ones we think that are mandatory public items -- name, college) to one privacy level or the other to allow for an easy, one-click switch.

#11 Updated by Boone Gorges about 10 years ago

  • Target version changed from 1.3 to 1.4

See also http://buddypress.trac.wordpress.org/ticket/3695

I'm suggesting for BP something pretty close to what we want for the Commons, with the idea that we will be able to build it as a plugin for our community and then submit it as a patch for BP itself. As I spell it out in the ticket, I think it's too complex for this dev cycle, so I'm punting it.

#12 Updated by Boone Gorges almost 10 years ago

I've got a first draft of this functionality written as a BuddyPress patch. There is a possibility that it will go into the next BP release. More soon.

#13 Updated by Matt Gold almost 10 years ago

Wow -- awesome.

#14 Updated by Chris Stein almost 10 years ago

Yes great. So this will be the central way to address the privacy concerns users have addressed.

Do we still want to change the language on the registration page to reflect the current privacy settings or do we just want to wait until this is in place and make the change once?

#15 Updated by Boone Gorges almost 10 years ago

This has been added to BuddyPress and should be in the 1.6 release. http://buddypress.trac.wordpress.org/ticket/3695#comment:10

#16 Updated by Matt Gold almost 10 years ago

Excellent. Thanks, Boone!

#17 Updated by Boone Gorges over 9 years ago

  • Status changed from Assigned to Hold

#18 Updated by Boone Gorges over 9 years ago

Depends on #1959

#19 Updated by Boone Gorges over 9 years ago

  • Status changed from Hold to Reporter Feedback

This is in the master branch and available for examination on cdev for testing. Here's a rundown of the functionality:

- On Profile > Edit, you'll see under each field "This field can be seen by: x" where 'x' is either "Anyone", "Logged In Users", or "My Friends"
- On this screen, you can change these settings. Make sure to click Save Changes to save the changes to visibility.
- Admins are able to set a default visibility level for a given field. Note that, by itself, this default only applies to new members (existing members are assumed, for reasons of backward compatibility, to have chosen "Anyone").
- Admins are able to enforce the default for all users, under "Per-Member Visibility". When set to "enforce the default...", user options for this field will be overridden with the default selected above. This does apply to existing members.

#20 Updated by Matt Gold over 9 years ago

This is pretty epic, Boone -- congrats and thanks for getting this done.

A few small things:

1. The left side of the drop-down radio buttons is cut off on my screen (OS X, Chrome). Screenshot attached.

2. "Logged In" should have a hyphen -- ie., "Logged-In Users"

3. Should we have a "Visible to: No One" setting? My guess is that you didn't include that because people should leave the field blank if they don't want anything to show up, but having blank fields set to any one of three existing options may be confusing to users -- a blank field with "this field can be seen by: anyone" implies that the blank field will show up on the profile. Here are a few options for resolving this:

a) add a fourth option: "No One."
b) have the privacy setting text show up only when a field is filled in (ie., we would see anything related to privacy if the field is blank)
c) have the privacy setting on blank fields be visible but default to something that clearly implies that it won't show up on the profile (maybe "no one")

My preference would be to do a) and c) -- add "No One" to all optional fields (I don't think it should be there for required fields), then make the privacy setting be visible but set to "No One" on blank fields.

At any rate, this is huge work -- thanks so much for it, Boone -- it's real coup for the Commons and a good thing for BuddyPress.

#21 Updated by Boone Gorges over 9 years ago

1. The left side of the drop-down radio buttons is cut off on my screen (OS X, Chrome). Screenshot attached.

Can't reproduce. Is this still the case? Some of the styling of these buttons has changed since the first rev.

2. "Logged In" should have a hyphen -- ie., "Logged-In Users"

Changed in https://github.com/castiron/cac/commit/b81f9b8121d0a3b964af5a9578f8aea26af12bf7

3. Should we have a "Visible to: No One" setting?

No. You're correct that it's not included because blank fields don't show up to anyone. Realistically, it seems highly unlikely that anyone would actually be confused by this. At worst, they might say "How could this be shown to Anyone if it's blank", save their profile, and then see that, indeed, nothing shows up. I'm very wary of overengineering a solution to a problem that probably won't exist.

A javascript solution along the lines of your (b) is not the worst idea, but the funky nature of the profile edit screen is going to make it a pretty fair amount of work. I propose that we push it to a future release.

#22 Updated by Matt Gold over 9 years ago

Can't reproduce. Is this still the case? Some of the styling of these buttons has changed since the first rev.

Yes, still experiencing it -- though, oddly, it seems to be happening on some fields but not others. Please see attached screenshot. Mac OS X, Chrome

A javascript solution along the lines of your (b) is not the worst idea, but the funky nature of the profile edit screen is going to make it a pretty fair amount of work. I propose that we push it to a future release.

Okay. I still think that people might be confused by this, but I hear you not on overengineering problems prospectively, so I'm fine with pushing this to a future release. Will create a ticket.

#23 Updated by Boone Gorges over 9 years ago

I'll have to wait until next week when I have access to a Mac to deal with the radio button thing, though it's beyond trivial, so I'm not going to lose sleep about it :-D

I still think that people might be confused by this

I think you're overthinking it. I'd be surprised if we heard from a single person about it.

#24 Updated by Matt Gold over 9 years ago

I think you're overthinking it. I'd be surprised if we heard from a single person about it.

I'm not saying you're not right, but I do want to point out that it's rare that we hear about UI issues, even if they're crucial -- many times, people just turn off/turn away.

And that reminds me that this is really a UI issue, so I'm adding Chris to the ticket as a watcher, which I should have done earlier -- apologies, Chris.

#25 Updated by Matt Gold over 9 years ago

Oops -- added Chris as a watcher after my last comment. Chris, please read through the ticket and let us know what you think. Thanks. here's the new ticket: http://redmine.gc.cuny.edu/issues/2013

#26 Updated by Boone Gorges over 9 years ago

many times, people just turn off/turn away.

Agreed. As a rule, it's a good thing to evaluate and reevaluate these sorts of things.

This specific case seems, to me, pretty clearly not worth reengineering. If the group disagrees with me, then I can alter it however you want.

#27 Updated by Matt Gold over 9 years ago

Chris, any thoughts? Boone, feel free to mark this as resolved if we don't hear from Chris today.

#28 Updated by Chris Stein over 9 years ago

Sorry, still trying to get through a bunch of stuff. I think this is very cool. Matt, I don't share your concern about the empty fields. Yes, there is potential for confusion but I think it's small. The option to have the privacy setting show up only when the field has something in it is a good way to address the issue.

Something I'd like to see addressed before that is changing the text when the 'close' button is clicked. For example if you're field is set to anyone, "This field can be seen by: Anyone" and you click 'Change' and change it to "Logged-in Users" in the radio button and then click 'Close' it will still show the same text. After you click on 'Submit' it does of course change to "This field can be seen by: Logged-In Users."

I know that would require some work. I don't think it has to submit to the DB when the 'close' is clicked just change the text on the page. If you all agree I can make a separate ticket as I don't think that needs to hold this up.

While, I'm on that train of thought... what do you both think about notifying the user if they make some changes and then try to leave the page (for example: http://stackoverflow.com/questions/8259090/how-to-detect-unsaved-data-in-form-when-user-leaves-the-page). It would say something like "You have made changes to your profile that haven't been saved. Would you like to leave the page and loose the changes?" This would be another ticket and shouldn't hold this one up.

#29 Updated by Matt Gold over 9 years ago

Great ideas and good point about unsaved changes, Chris

#30 Updated by Boone Gorges over 9 years ago

I don't think it has to submit to the DB when the 'close' is clicked just change the text on the page

Right. This is just the problem. The changes aren't reflected in the database until after you hit Save. So changing the text actually seems like it will cause data loss, since people may not bother to change anything. I agree that this part of the UI is confusing, but simply changing the text on close doesn't seem like it's much better than it currently is - both are confusing in their own way.

The quickest "fix" I can think of is this: a JS listener that detects when someone changes the visibility of one of their fields, and then fades in a messages that says "This change will be reflected when you hit Save Changes". That's fairly quick to do.

Warning before leaving the page is a good idea; I'm not sure if it would be in place of the suggestion I just made, or in addition to it.

Anyway, let's just decide what should be done, so that someone can do it. I don't want this issue to hold up the works.

#31 Updated by Matt Gold over 9 years ago

I'd vote for just the leaving-the-page warning but happy to be outvoted.

Boone, out of curiosity, how difficult (or inefficient/resource-intensive) is it to actually have the change write to the database on selection of the option? I notice that on PCs, changes are often not registered until one clicks a save button, while on Macs, changes there is no save button --- changes are made immediately upon selection of the option. Of course, we're talking about two very different things here -- an OS installed on a computer vs. web software communicating with a database on a server, but again, I'm just curious.

#32 Updated by Chris Stein over 9 years ago

Good Points all around. Here"s my suggestion on next steps.

Step 1
Implement it "as is". The changes we're suggesting aren't critical for 1.4.

Step 2
Change acknowledgement: something to let the user know they have changed an option. Boone's "fix" above with the fade out message is one option, the other option is to change the text that shows the privacy status when they click 'close.'

Save protection: Warn the user if they try to leave the page without saving changes.

I'd like to see both the change acknowledgement implemented together as they address different issues (letting the user know they have successfully made a change, and not letting the, accidentally lose the changes they've made.

Step 2 alternative: save each change as it's made.
This would use Ajax to submit each change automatically as it was made. Matt, youre right that this is the style that apple has gone to in osx. It solves the problem of having the combined solution proposed above. I don't think it would be too taxing on the DB. You would still need a submit button in case user doesnt have JS. I think you would still want some kind of change acknowledgement to let people know the change was made. this option could be more elegant but I'm guessing it will require more work.

One reason I'm willing to wait until after 1.4 for step 2 is that I think once we decide on a direction we should start to do similarly consistent things on other forms like email options.

#33 Updated by Boone Gorges over 9 years ago

Boone, out of curiosity, how difficult (or inefficient/resource-intensive) is it to actually have the change write to the database on selection of the option?

The basic setup is moderately time-consuming. I think it's a bad idea, though, for a couple reasons. (1) We don't do this anywhere else in the interface. (2) I'd have to come up with an elaborate workaround for users registering for the first time, since their data isn't stored in the database before they have registered. (3) Other data on that very page - the profile field data itself - would still only be stored when the form is submitted, a discrepancy that may cause confusion for users.

I'm going to see how much time I've got in the upcoming week to implement the warn-before-leaving thing, but as Chris suggests, I'll push it to the next release if I run out of time.

#34 Updated by Boone Gorges over 9 years ago

  • Status changed from Reporter Feedback to Resolved

I tried a couple proofs-of-concept of the leave-the-page-warning thing, but I didn't feel comfortable with any. I've opened a separate ticket for it, targeted for the 1.5 release: #2028

Marking this ticket resolved. Hooray!

#35 Updated by Matt Gold over 9 years ago

Congrats, Boone -- this is pretty huge.

#36 Updated by Chris Stein over 9 years ago

Yes great!

#37 Updated by Boone Gorges about 6 years ago

When I made our Contributions page http://dev.commons.gc.cuny.edu/free-software-contributions/, I'd forgotten that the xprofile field visibility feature in BuddyPress came from this Commons ticket. IMO this is one of the most influential things we've built for BuddyPress. I've updated the page accordingly :-D

#38 Updated by Matt Gold about 6 years ago

That's great!

Also available in: Atom PDF