Project

General

Profile

Actions

Feature #19278

closed

"Account Settings > Edit Profile" screen and "Commons Profile" header

Added by Raymond Hoh 4 months ago. Updated about 1 month ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
Account settings
Target version:
Start date:
2023-11-15
Due date:
% Done:

0%

Estimated time:
Deployment actions:

- On "Users > Profile Fields" network admin dashboard page, change the 'Website' and 'Blog' profile field types from 'Text Box' to 'URL'.
- git submodule update wp-content/plugins/cac-advanced-profiles


Description

I decided to create a new ticket from #17769.

Here are Sara's mockups for the "Account Settings > Edit Profile" screen:


There was a bit of talk in the dev chat about keeping the CV data and the Commons Profile header data separate. I'm wondering whether we can just use the CV's data as the main source of data. By that I mean, if a user has filled in their CV's name, pronouns, one-line bio, social links, etc, we will display that same data in the Commons Profile header and we will not show the "Account Settings > Edit Profile" screen at all. I've already got some code for this ready to go. The code uses the parse_blocks() function and thanks to the placeholders in those blocks, it is possible to extract data for specific blocks from the CV.

If a user has not filled in their CV, for the header, we will fall back to the data that the user inputted previously during account signup or for their Public Portfolio. For these users, the "Account Settings > Edit Profile" screen will be available so that data can be edited.

I think this would limit the confusion of having two separate pieces of profile data. On the contrary, would users be surprised to see some of their CV data in their Commons Profile header? What does everyone think?


Files

edit-profile-errors.gif (229 KB) edit-profile-errors.gif Raymond Hoh, 2023-11-27 07:33 PM
Screenshot 2023-11-28 at 5.34.51 PM.png (500 KB) Screenshot 2023-11-28 at 5.34.51 PM.png Sara Cannon, 2023-11-28 06:35 PM
no-cv-saving-profile.mov (3.97 MB) no-cv-saving-profile.mov Colin McDonald, 2024-01-07 11:32 PM
Actions #1

Updated by Boone Gorges 4 months ago

There was a bit of talk in the dev chat about keeping the CV data and the Commons Profile header data separate. I'm wondering whether we can just use the CV's data as the main source of data. By that I mean, if a user has filled in their CV's name, pronouns, one-line bio, social links, etc, we will display that same data in the Commons Profile header and we will not show the "Account Settings > Edit Profile" screen at all. I've already got some code for this ready to go. The code uses the parse_blocks() function and thanks to the placeholders in those blocks, it is possible to extract data for specific blocks from the CV.

This is an interesting idea. But I think it ultimately limits what users can do with their CVs. You might imagine, for example, someone with a professional and a personal Twitter account; they might want one listed on the CV and another listed on the Commons Profile. Even Name - I can imagine someone who uses a different version of their name on a CV.

Keeping the CV and Profile fields separate might cause some confusion, but it allows for full flexibility. Syncing the two, on the other hand, eliminates some possible confusion at the cost of eliminating certain ways of filling in data. On balance, in this case, I think it's better to address the potential confusion with documentation. Happy to defer to what Sara and others think, though.

Actions #2

Updated by Colin McDonald 4 months ago

I also see both the benefits and drawbacks of this. I wonder if another argument against syncing is the item-by-item control over visibility that one has for the profile fields, whereas the CV fields are all totally public by design/default.

I guess this would be avoided somewhat by not showing the Edit Profile screen if the CV exists, but something doesn't feel quite right to me about showing this screen to some and not others, without a better way of making it clear why that's happening. In the documentation (which I agree we'll need a good amount of here), it's easier to instruct everyone if we know they're seeing the same things.

As I was writing my latest update to #17768 just now, it also struck me that it might be nice to clarify/separate the CV and the profile as much as possible. Right now one of our editing links is for CV/Profile and we use that language sometimes, but I think there's some benefit to helping people see them as separate in both functionality and overall purpose.

Actions #3

Updated by Raymond Hoh 3 months ago

A first pass of the "Account Settings > Edit Profile" screen and revamped "Commons Profile" header is available for testing on cdev.

For the "Account Settings > Edit Profile" page, we will re-use the existing BuddyPress "Profile > Edit" page and hide the existing "Account Settings > Profile Visibility" page.

For the "Commons Profile" header, we will display the reconfigured profile fields and will use microformats markup as well for better parsing by apps and search engines utilizing microformats. See https://microformats.io/ for more info.

One issue I encountered when entering invalid info for the "Email Address", "Website" and "Blog" fields is we do not do any validation checking whatsoever when submitting the form. For the moment, I am doing some rudimentary checking to see if these fields have valid email and URL values respectively before displaying that info in the header, but we should add some error messages if a user attempts to add invalid data during submission.


I wonder if another argument against syncing is the item-by-item control over visibility that one has for the profile fields, whereas the CV fields are all totally public by design/default.

Yeah, having control over the profile field visibility is the main reason to keep the existing set up. However, entering that same core info (name, pronouns, one-line bio) on the CV again nullifies this advantage.

Actions #4

Updated by Raymond Hoh 3 months ago

I've added HTML5 browser validation for the 'Email Address', 'Website' and 'Blog' profile fields. The 'Email Address' field uses the built-in, browser email validation routine for the <input type="email"> field and the 'Website' and 'Blog' fields uses a basic 'https:// or 'http://' prefix check.

If you pass browser validation, but still have errors, I've also added server-side validation so we can display an error message. See attached GIF:

We can also add better browser validation if we wanted to strengthen the email address and URL matching as well.

This is available for testing on cdev. Let me know if you would like me to change the error message copy displayed in the red box. Boone, the 'Website' and 'Blog' fields will require changing the profile field type from 'Text Box' to 'URL'. I've added a deployment action for this.

Actions #5

Updated by Raymond Hoh 3 months ago

  • Deployment actions updated (diff)
Actions #6

Updated by Raymond Hoh 3 months ago

  • Deployment actions updated (diff)
Actions #7

Updated by Raymond Hoh 3 months ago

  • Deployment actions updated (diff)
Actions #8

Updated by Sara Cannon 3 months ago

In my profile, I have all the icons such as delicious and flickr. When I go to this screen, I just see Twitter, Linkedin, and Facebook. I get that maybe we want to sunset some of these socials for users, but if you already have them - they should be editable.

Actions #9

Updated by Raymond Hoh 3 months ago

Hi Sara,

Good catch about all the social icons still being displayed in the header.

To follow-up on that, based on the first mockup displayed at the top of this ticket, was the intention to limit the social fields to just Facebook, Twitter and LinkedIn? If so, I can fix up the header so it only displays those three sites.

Regarding:

I get that maybe we want to sunset some of these socials for users, but if you already have them - they should be editable.

I think we shouldn't have some existing users being able to edit more social media sites than those users that will not have access to those sites. I think we should make a list of the social media sites we will want to display and retire ones like Delicious that we know are outdated. Would welcome others thoughts on this as well.

Actions #10

Updated by Colin McDonald 3 months ago

I think it's right that we should retire most of the social media sites, especially for the Commons Profile header. People can always add more to their CV if they'd like. In #17018 are the pulled numbers showing that most of these fields are rarely used, and likely not very recently at that.

Actions #11

Updated by Colin McDonald 3 months ago

Quick followup, I'd be in favor of just having Twitter, Linkedin and Facebook as the default fields.

Actions #12

Updated by Matt Gold 3 months ago

Colin McDonald wrote in #note-11:

Quick followup, I'd be in favor of just having Twitter, Linkedin and Facebook as the default fields.

that sounds fine to me, as well

Actions #13

Updated by Raymond Hoh 3 months ago

Quick followup, I'd be in favor of just having Twitter, Linkedin and Facebook as the default fields.

This is done and available for testing on cdev.

Actions #14

Updated by Sara Cannon 3 months ago

Here are links to the icons that we can use for Google Scholar and OrchidID. They have SVG downloads but let me know if you need me to format it a certain way and I can

Google Scholar Icon: https://fontawesome.com/icons/google-scholar?f=brands&s=solid
OrchidID Icon: https://fontawesome.com/icons/orcid?f=brands&s=solid

Actions #15

Updated by Colin McDonald about 2 months ago

I think I found an issue when saving changes to the profile header fields for a user who doesn't have a CV yet. See attached screen recording. When I update a field then click Save Changes, it redirects to the modal / edit CV page, rather than just refreshing and bouncing back to the top of the Edit Profile page (this is what it does for my CDEV accounts that do have an active CV).

Actions #16

Updated by Raymond Hoh about 2 months ago

Thanks for finding this bug and for the recording, Colin.

The redirect issue is due to plugin conflicts with the CAC Advanced Profiles plugin and the CAC YOURLS shortlink plugin. Both plugins short-circuit the profile update routine by redirecting back to the main user's root profile, which would be the CV page if a user has a CV published.

I've added fixes for the two plugins below:

Colin, the fixes are deployed on cdev. Feel free to test again to see if the redirect issue is still occurring.

Actions #17

Updated by Raymond Hoh about 2 months ago

  • Deployment actions updated (diff)
Actions #18

Updated by Boone Gorges about 2 months ago

Thanks, Ray! These fixes seem fine to me.

Actions #19

Updated by Colin McDonald about 2 months ago

Looks good on CDEV to me too, thanks Ray!

Actions #20

Updated by Boone Gorges about 1 month ago

  • Status changed from New to Resolved
Actions

Also available in: Atom PDF