CUNY Academic Commons

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.

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

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

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)

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

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.

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.

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.

Wow -- awesome.

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?

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

Excellent. Thanks, Boone!

Depends on #1959

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.

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.

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.

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

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.

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

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.

Great ideas and good point about unsaved changes, Chris

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.

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.

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.

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.

Congrats, Boone -- this is pretty huge.

Yes great!

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

That's great!