Design/UX #17385
closedProfile CV & Account Settings
Added by Sara Cannon almost 2 years ago. Updated 10 months ago.
100%
Description
The current profile pages are outdated and need a refresh to reflect the latest design of the Commons. Rather than having a tab interface, we are going to separate out a "Public CV" that users can customize and their "Commons Activity & Settings". I've attached some initial screens for reference.
Logged Out- Public CV
- Public CV with Header
- Public CV (Minimal)
- Account - Commons Activity
- Public CV
- Public CV with Header
- Public Cv (Minimal)
- Account - Commons Activity
- Public CV with Header (My Profile)
- Account - Commons Activity (My Profile)
- Account Settings - Export Data
Files
Related issues
Updated by scott voth almost 2 years ago
I wonder if we are treating undergrads as second tier members with the CV page. Does anyone like the idea of allowing them (or any other member) to have a "personal page" on the Commons rather than a CV? So a new member could opt to create a CV or a "personal page" (and be able to switch the type back and forth). And I guess a personal page could be either public or private.
Updated by Matt Gold almost 2 years ago
Hi Scott -- that is an interesting question. Would it feel more open to undergraduates, do you think, if we called it a Resume/CV page?
As a matter of principle, I think it would be okay to have element of the site that would cater to faculty/grad students/staff since it is an opt-in element rather than an automatically created part of the site for users. I am interested in thinking about ways we can make the naming of it more approachable for all audiences, though.
Updated by Colin McDonald almost 2 years ago
Maybe a question for more academic types here, but doesn't a CV apply to undergrads too? If the idea of one is to write out your experience, academic and otherwise, don't you list degrees etc that are in progress as well as completed?
A CV for an undergrad would be shorter, but the same would be true for a resume or anything else. I like the academic slant of the CV labeling, as we discussed in prior meetings the Commons leaning into its academic side.
Going with "CV/Resume" is more clean in a way, but I think most people know what a CV is, and we could always use documentation for those who don't. I like keeping it simple if possible -- same for whether we'd offer a different kind of non-CV page that was opt-in and customizable. Everyone would still have the standard, autopopulated profile page with their feeds to start.
Updated by Colin McDonald almost 2 years ago
Adding a few watchers to this ticket and following up on a data question from last week - we'd like to know how many users have filled out the below elements in their profile, so we can better determine which ones to keep and how to handle them in the design. Boone, let me know if anything unclear as you look into this.
PROFILE FIELDS/CHECKBOXES
Twitter
IM
LinkedIn
Flickr
YouTube
Github
Vimeo
ORCID ID
Google Scholar
One-Line Bio
About You
Phone
Website
Blog
Facebook Profile Link
Delicious ID
academia.edu Profile URL
BOTTOM FREEFORM SECTIONS
Free Entry (anyone more than one?)
Academic Interests
Education
Publications
RSS Feed
Twitter
Positions (how many only one vs multiple?)
---Each is college/department/title, for reference
Updated by Boone Gorges almost 2 years ago
I've written a tool that gets counts. Here are results:
Array ( [total] => 41367 [Twitter] => 1601 [LinkedIn] => 1474 [Flickr] => 227 [YouTube] => 367 [Github] => 461 [Vimeo] => 79 [ORCID ID] => 160 [Google Scholar] => 174 [One-Line Bio] => 20572 [About You] => 3899 [Phone] => 4396 [Website] => 2394 [Blog] => 810 [Facebook Profile Link] => 687 [Skype ID] => 278 [Delicious ID] => 194 [academia.edu Proflie URL] => 434 [Academic Interests] => 2444 [Education] => 804 [Publications] => 426 [Positions - Number of users] => 1812 [Users with 1 positions] => 1476 [Users with 2 positions] => 166 [Users with 3 positions] => 59 [Users with 4 positions] => 25 [Users with 8 positions] => 3 [Users with 5 positions] => 15 [Users with 7 positions] => 3 [Users with 10 positions] => 1 [Users with 6 positions] => 8 [Users with 9 positions] => 1 [Users with 12 positions] => 1 [Twitter Feed Widget] => 33 [RSS Feed] => 18 [Users with 9 free entry fields] => 1 [Users with 4 free entry fields] => 3 [Users with 1 free entry fields] => 13 [Users with 2 free entry fields] => 3 )
Let me know if anything here needs clarification or refinement.
Updated by Jeremy Felt almost 2 years ago
Progress on the front-end editor... front. :)
Here's a short video walking through some thoughts: https://www.loom.com/share/f9bead9bfdc94eee82e5fdde95916a8e
I've extended Automattic's Blocks Everywhere plugin, which uses Automattic's Isolated Block Editor package. At the moment, the best experience is with the latest version of Gutenberg activated, though I don't think it would take much to rework Blocks Everywhere so that it isn't required.
Quite a bit of the editor UI is intentionally hidden. It seems like it would be nice if we're able to implement patterns/blocks in a way where no class names need to be applied.
Right now I have every field editable, but we can lock specific blocks or enforce a pattern that always retains things like profile image and the various navigation buttons.
I'll work on actually saving the content next.
Sara - I think we can be pretty flexible with the layout here. Action buttons could go in content or outside of the frame. Let me know if you have any questions.
Boone / Ray - I'm guessing this approach can be packaged in a new plugin—CAC CV Editor or something—that is activated on the main site. The front-end editing code could be extracted if it is ever needed for something else. I'll start poking at an actual branch next week, but please let me know if you have any thoughts or if we need a ticket specifically for that integration.
Updated by Boone Gorges almost 2 years ago
Awesome, Jeremy! Hopefully this will spark Sara's imagination.
It seems like it would be nice if we're able to implement patterns/blocks in a way where no class names need to be applied.
I always say this when I start building block-based projects, and I never succeed :) But it gets a bit easier with every version of the Block Editor.
Boone / Ray - I'm guessing this approach can be packaged in a new plugin—CAC CV Editor or something—that is activated on the main site. The front-end editing code could be extracted if it is ever needed for something else. I'll start poking at an actual branch next week, but please let me know if you have any thoughts or if we need a ticket specifically for that integration.
A standalone plugin makes sense to me. It's likely that we'll need some additional infrastructure around it - editing permissions, integration into menus, any CV-specific custom blocks we build in the future. A plugin would be a natural home for these things. It would be nice if we could build in such a way that we're somewhat theme-independent, though this is just a nice-to-have.
Updated by Colin McDonald almost 2 years ago
- Related to Design/UX #17018: Analytics for Profile Fields & Features added
Updated by Jeremy Felt over 1 year ago
- File Screenshot 2023-02-21 at 09-32-29 https __plugins.test.png Screenshot 2023-02-21 at 09-32-29 https __plugins.test.png added
A screenshot for Sara of the basic layout for the front-end editor. We can modify this quite a bit, so let me know if you'd like to see any elements added.
Updated by Colin McDonald over 1 year ago
Hello all, as per the dev call on Tuesday, I've set up #17768 (CV Editing and Publishing) and #17769 (Account Settings Tab) to break off the tasks we feel ready to start developing while Sara is away given the design work she's completed on them already. We'll combine this development work with that of the other items in this overall ticket once she's back and we can flesh out the other elements.
I know we've used this ticket so far as a bit of a catchall for everything rolled up into it, but let's try to use the subtickets (I'll create more as needed) for more targeted updates, especially since Jeremy has taken the lead already on the CV Editing and the Account Settings I believe will fall to Boone and Ray.
Updated by Sara Cannon over 1 year ago
Hello! Here is the latest (unfinished) Figma for the Inbox (messages + notifications) so everyone can see it. I don't know how to create a subtask to put it in - so I thought I'd throw it here so that people can have eyeballs on it while I'm out. https://www.figma.com/proto/0Ke5bCwheE5SXXkT6wDd2l/CUNY-Design---Spring-2023?page-id=2900%3A84364&node-id=2900%3A87036&viewport=4098%2C6553%2C0.13&scaling=min-zoom
cheers!
Updated by Raymond Hoh about 1 year ago
In this week's dev call, we talked about keeping the user's Public Portfolio page while rolling out the new Commons Profile and Account Settings design changes in case the CV Editor is not ready for the next release.
I've added a commit that ensures this is possible - https://github.com/cuny-academic-commons/cac/commit/17993ab5124c0cf00fe5f770baa650dec4e61bdb . For this to work, deactivate the CAC CV Editor plugin and then check a user's profile and you should see the user's Public Portfolio page again. I need to make a few more changes like changing the "View / Edit Public CV" button so it says "View Public Portfolio" when on a Commons Profile page. Do we also need to adjust the "Account" breadcrumb located at the top?
We also talked about perhaps adding some basic styling to the Public Portfolio page so it matches parts of the new design. This probably means changing the background color, fonts, padding, so nothing too drastic here.
Updated by Colin McDonald about 1 year ago
Many thanks for this, Ray. So does it seem then that we would be able to move ahead then with releasing Settings on its own before CV, without creating a lot of temporary/transient work for ourselves or confusion for our users?
Updated by Raymond Hoh about 1 year ago
Yes, we should be able to move forward with just releasing the Commons Profile and Account Settings changes before the CV Editor is deployed in a later release if we choose to do that.
Updated by Raymond Hoh about 1 year ago
On cdev, I've deactivated the CV Editor plugin so the Commons Profile and Account Settings pages can be tested alongside the existing Public Portfolio page.
Before testing, make sure to clear your browser's cache or do a hard refresh in your browser. You can do so with the following keyboard shortcuts:
- Chrome, Firefox, or Edge for Windows: Press Ctrl+F5 (If that doesn't work, try Shift+F5 or Ctrl+Shift+R).
- Chrome or Firefox for Mac: Press Shift+Command+R.
- Safari for Mac: Press Command+Option+E to empty the cache, then hold down Shift and click Reload in the toolbar.
Updated by Raymond Hoh about 1 year ago
I've added a first pass at refreshing the Public Portfolio page with the new redesign. This is available for testing on cdev. For those unable to access cdev, I've attached a screenshot of Matt's Public Portfolio from cdev.
Sara, let me know if anything needs tweaking.
Updated by Colin McDonald about 1 year ago
Thanks Ray, I've taken a quick pass through and this is looking promising to me. Once Sara's signed off, I'll add it to our list for testing for the intermediate release.
One small thing I noticed is that the Edit button on your "public portfolio" page says Edit Public Profile when it should probably say Edit Public Portfolio, keeping the terminology consistent for now until we do away with the "portfolio" aspect in the CV release.
Updated by Sara Cannon about 1 year ago
This looks great! I just saw one bug with a long "About You" where the button does not wrap below the text (see screenshot)
Updated by Boone Gorges about 1 year ago
Sara has posted icons at https://redmine.gc.cuny.edu/issues/18194#note-9
Updated by Raymond Hoh about 1 year ago
On cdev, new icons are up for the "Follow Me Online" block. I've also fixed the sticky header bug that Colin reported in the dev chat, as well as the overflow bug Sara mentioned above.
Updated by Boone Gorges about 1 year ago
- Target version changed from 2.2.0 to 2.3.0
Updated by Colin McDonald about 1 year ago
- Related to Design/UX #19070: Handling notifications backlog added