CUNY Academic Commons

Hey Boone,

I like the idea of just cleaning is up rather than allowing for a dropdown menu with infinite options. After doing a little bit of reasearch and reading this great article: http://www.pewinternet.org/2016/11/11/social-media-update-2016/ my recommendation for updated social medias are split by professional and personal:

• Facebook
• Twitter
• Instagram
• Pinterest
• Tumbler

• Linkedin
• Google+
• Blog
• Website
• Academia.edu Profile URL

Additionally, if we are really concerned with making someone feel like we're not allowing them to showcase who they are with the options we come up with could we possibly add a "free entry" or "other" field?

Thanks!

Oh, I didn't mean we had to add distinctions for Commons users between professional vs. personal entries, I just made those lists as I was researching because I like organized lists. Sorry about the confusion!

I figured that was the case :)

I've implemented a version of these updates here: https://github.com/cuny-academic-commons/cac/commit/110e6f0d2341ae7fe4a1813093f620e7d40e31e2

I also made some other changes to the code to DRY it out and make it easier to add and remove options in the future, plus a couple minor accessibility things.

For now I've left off the "blog" and "website" entries, because I'm not sure what icons to use. Right now we're just piggy-backing off of the icons available in the bp-social-media-profiles plugin, and I don't see a good choice there for a general "blog" or "website" icon.

Thanks, Dan. The DRY changes look great. I left a couple small comments on GitHub, which I see you've already addressed :)

It seems fine to me to leave "blog" and "website" off the list for now. Many groups with blogs host them on the Commons, so that they're linked to from the navigation already. Paige, let us know if you feel strongly otherwise.

A thought: We're removing a couple items from the list. It could be that there are existing groups using them. Could we keep these old networks on the list, showing them on the Manage tab only if they're non-empty? They'd be marked "deprecated" in your available-network list, or something like that.

Good thinking, Boone! I've added that support here: https://github.com/cuny-academic-commons/cac/commit/0c1b2d557a731f4e39239ed9c2e6efb49e1c2be1

Also - should I work on the UI mentioned at the top of the ticket, where users can add (and I'd guess delete, too) accounts themselves, instead of always seeing all of the options?

Also - should I work on the UI mentioned at the top of the ticket, where users can add (and I'd guess delete, too) accounts themselves, instead of always seeing all of the options?

Yeah - IMO this would be much more elegant. Thanks!!

I've implemented the new UI here: https://github.com/cuny-academic-commons/cac/commit/37d84d94737b2d5175e8385f5b82ddc415b294d5

I still need to add some styling to help everything be a little more clear, and also add internationalization to the strings I use for the buttons in PHP and JS, but I wanted to get this out now for you to review and see if it looks like I started down the right track.

Boone Gorges wrote:

Having to click "Add Account" after filling in a field doesn't seem quite right to me. The "Add" button feels like it ought to add empty fields, which I must then fill in. What do others think?

Agreed. Nice work, all!

I have a question based on the gif. Are the social media accounts auto populated? Based on the gif, facebook is the first and only thing users are allowed to fill in initially. But what if they don't have a facebook account and want to add, let's say, instagram instead? Do you have to click "Add Account" until the option pops up in the predetermined social media hierarchy? If this is true, and a user hits "Add Account" three times to get to an instagram entry field, would doing this cause an error message should the user not choose to fill out the first two fields?

I agree with Boone that the "Add Account" is unclear as a submit function since it already works as a new field function for the social media choices. I think that two different functions should live on their own as either separate buttons or (submit better idea here). Perhaps a 'submit' button could live where the 'remove' button lives (i.e. remove replaces submit).

Also how do users edit after submission? The remove button is clear but editing (I'm assuming) is done by clicking the already submitted name?

I think changes needed are all fairly small and I really like the cleanness of the idea!

Thanks for the feedback everyone! I've made some changes here: https://github.com/cuny-academic-commons/cac/commit/3d5719b4bd06ee1e35dd3f42ad0d665e6f975149

I've separated out buttons for adding a new account field and for the submitting the new account info. In an attempt to keep things simple, I've disabled and hidden the button for adding a new account field when there's already one displayed. I also added some styling to fix some of spacing issues that could cause confusion. Let me know what you think!

Oh and to answer your question, Paige: The the accounts aren't auto-populated. The user selects the account name from a drop down and then enters the name and submits it. And yes, the way to edit them once they've been submitted it so edit them directly in the text input that they're displayed in.

and when you add a new one it automatically pre-populates the new text field with the username entered for the old one?

Right! Sorry about that - that was an oversight in the first version. My most recent set of changes fixes it.

This ended up being more or less a total rebuild of the front-end, because of how I had coded the JS before to take advantage of the design only allowing one new account input at a time.

Here's the commits - something weird happened with git for me so I ended up pushing the CSS/JS and the PHP in two separate commits:
https://github.com/cuny-academic-commons/cac/commit/d35ddfef0c8f499732d324bdbc4e2527b50dd76c
https://github.com/cuny-academic-commons/cac/commit/860a5733a763bc168f4d83449365254bace25386

Thanks, Dan!

Could you please test your latest changes against a group that doesn't yet have any social media accounts attached? It looks like, in this case, JS variables aren't being initialized properly, which causes various sorts of errors.

Sorry about that - this commit should fix it: https://github.com/cuny-academic-commons/cac/commit/fbadf89b94b195b57a5d7b9d1d063a724c170bbc