Update social network connection options during group creation
the list of networks we offer seems a bit outdated. please see the attached screenshot
#2 Updated by Boone Gorges about 1 year ago
- Assignee changed from Boone Gorges to Paige Dupont
- Target version set to Future release
I'm probably not the best person to decide what the au courant social networks are.
Paige, could you chime in with your suggestions? Better to pare it down to a few essential ones, rather than pad it out with those that are never used.
Another possibility: have a single field with a dropdown to select from a list, with a plus-sign to dynamically add more rows.
Dan, adding you as a watcher, as you built this feature initially.
#3 Updated by Paige Dupont about 1 year ago
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:Personal:
- 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?
#4 Updated by Boone Gorges about 1 year ago
- Assignee changed from Paige Dupont to Daniel Jones
- Target version changed from Future release to 1.11
Thanks, Paige. This list seems good to me, though I'm unsure that for our purposes we need a personal/professional distinction in the UI.
Free entry fields are tough because we provide custom icons for each network, which we can only do for a predetermined list of networks. If there are other networks that are super important to a group admin, the links can be added to the group description.
Dan, can you work on this for 1.11?
#7 Updated by Daniel Jones about 1 year ago
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.
#8 Updated by Boone Gorges about 1 year ago
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.
#9 Updated by Daniel Jones about 1 year ago
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?
#11 Updated by Daniel Jones about 1 year ago
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.
#12 Updated by Boone Gorges about 1 year ago
Thanks, Dan! General approach looks good to me. With some styling cleanup, I think this'll be a big improvement to what we already have, and might be a good model for rethinking our user social media fields, especially during registration.
I've attached a gif showing the interface, for the benefit of Paige and others.
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?
#14 Updated by Paige Dupont about 1 year ago
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!
#15 Updated by Daniel Jones 12 months ago
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!
#16 Updated by Daniel Jones 12 months ago
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.
#19 Updated by Boone Gorges 12 months ago
Thank you, Dan! This is a significant improvement. (gif attached for others' convenience)
I'd suggest the following changes - subject to approval from others:
1. When a group has no existing fields, show a blank one when first visiting Social Media Accounts tab. Having to click the button makes it too hard to find.
2. Lose the Submit button as well as the [label linebreak input] field format. There's no real benefit to switching from [dropdown input] to [label input] on hitting "submit" - in fact, the [dropdown input] format takes up just a single line, which reads better to me.
3. This means that the Remove button should appear in the [dropdown input] format
Does this make sense? Does it seem right to others?
#20 Updated by Daniel Jones 9 months ago
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:
#23 Updated by Daniel Jones 8 months ago
Sorry about that - this commit should fix it: https://github.com/cuny-academic-commons/cac/commit/fbadf89b94b195b57a5d7b9d1d063a724c170bbc
#24 Updated by Boone Gorges 8 months ago
- Status changed from Assigned to Resolved
- Target version changed from 1.12 to 1.11.2
It looks like this feature got shipped in 1.11 - I forgot to remove it from the branch, though the ticket hadn't been closed. My fault. Let's call this finished for 1.11.2.