CUNY Academic Commons

@matt thanks. i totally agree. i will be very interested in the discussion re: UI issues. :-)

forgot to mention that since i am not an academic there might be OpenAccess publishing platforms, etc. cf. Academia.edu that i'm unaware of that might be more desirable options than the purely social network-based options listed above.

I'm OK with pushing this. It would be nice to have more options but I don't think it should hold up the new profiles. Matt's point about possible UI issues with many options is well taken and may be more easily addressed once the new profiles are in place.

Boone, Chris,

I've worked on profile links in #2248 and am currently adding fields in #2800.

Would you like me to take this ticket over and keep incorporating new profile fields (and removing old ones)?

Here's my suggestion

New inclusions:
- Tumblr (content publishing)
- Instagram (image publishing)
- Pinterest (bulletin board publishing)
- google + (social network)
- Picasa (image publishing)
- YouTube (video content)
- Vimeo (video content)
- github (programming / code publishing)
- last.fm (social network based on scrobbling aka tracking music you listen to on iTunes, Spotify, etc.)

Delete from current list of options:
- IM*
- FriendFeed*

Chris, please let me know whether you have thoughts/suggestions

Matt, that sounds fine. I agree with the fact that IM and FriendFeed don't seem to be so useful.
my only question there is do we know how many people are using the IM field? If there is a significant amount we might want to offer them something.

• github
• prezi

• edutopia
• edmodo
• classroom20.com

Ideally we will also create another ticket at some point to work on a system of adding these that doesn't require showing all of the fields at once. When we're ready I can work on some mockups.

This is just a quick update for anyone monitoring this issue.

The current bp-social-media-profiles plugin (the plugin responsible for providing these features) already has support for these social profiles:

• YouTube
• Vimeo
• Github

So I'll be focusing on the remaining new requests:

1. Instagram
2. Tumblr
3. Vine
4. Pinterest
5. Google+
6. Picasa
7. last.fm

I'm going to work on new additions first so we can all swing back around to discuss removals once we've investigated the popularity of those profiles.

Great! Thank you, Dom

I've created pull requests for the following new profiles:

1. Instagram
2. Tumblr
3. Vine
4. Pinterest
5. G+
6. last.fm

In previous comments I listed profiles that already existed in the plugin. The only major profile listed above that has not been included is Picasa. Sharing of that info has been integrated into G+ so there is no need to add a profile field for it.

Thanks, Dom. I'll review the pull requests and get them merged in for 1.7.

My instinct is to make it an ajaxy section that opens-out upon click, but let's wait just a few days until Samantha is on board to comment on UX issues..

OK. I was thinking something similarly slidey or whatever, but I want to note that building this will be a non-trivial amount of work. So if we're going to go with the complex version for 1.7, we should decide pretty soon; and if not, we should decide whether we're going to hold off on adding the new fields until we do get the more complex UI changes made.

I've taken my first pass at the changes to the interface here: https://github.com/cuny-academic-commons/cac/commit/16733daf04fbed42b2929c7d0f76bf6dbe076720

Let me know if anything isn't clear: I tried to emulate the MeetUp approach that Sam described, by just having the name of the network and a checkbox, and then when the user clicks the checkbox the field appears.

I'd be interested especially on input on how I'm handling when people check/uncheck the field: right now I save the value loaded from the DB on page-load in a data attribute for the checkbox, which I use to restore the value in the text input for the field whenever it gets displayed after being hidden. So if you have a GitHub username input but you uncheck the Github checkbox, the value gets set to "", but if you re-check, the value goes back to what it was from the database. This means that if you edit the value in the textbox, then uncheck the field, then recheck it, those changes will be lost. Same if you check a previously empty field, fill something in, then uncheck and recheck it: it'll be blank.

If this is looking good, I can move on to updating the options and also adding the hints for what users should input that Sam suggested (like @-symols and http:'s).

Oh okay understood - I'd defer to you and the others. I guess the trade-off is taking up room on the page vs. rules of thumb on how many options you can have in a dropdown before it gets unwieldy.

I could see about reducing some of the margins to help make things a little more compact, too.

Hey again - managed to loop back around and finish off another set of changes to this. I've incorporated the 'hints' that help clarify what we're asking users for in each case. Let me know if this looks okay! https://github.com/cuny-academic-commons/cac/commit/d7e614280ddaa85787716eabef56cc78ce30a884