Project

General

Profile

Actions

Feature #18192

open

CV "top" section

Added by Boone Gorges 5 months ago. Updated 20 days ago.

Status:
New
Priority name:
Normal
Assignee:
Category name:
CV
Target version:
Start date:
2023-08-11
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)
Deployment actions:

Description

Breaking out from #17768, the general CV ticket.

Let's do some thinking about how best to build the "top" section of the new CV, by which I mean everything that appears above the dashed line (above 'Education'): https://www.figma.com/proto/0Ke5bCwheE5SXXkT6wDd2l/CUNY-Design---Spring-2023?page-id=2888%3A56943&node-id=2889-67871&viewport=3501%2C4218%2C0.13&scaling=min-zoom

While we'll be using the block editor to edit this section, its structure will be fairly static. WordPress allows locking at the level of the post-type template as well as the level of the block. The post-type template is too broad, so we'll need to build some sort of wrapper block with a 'lock' property. See https://developer.wordpress.org/block-editor/reference-guides/block-api/block-templates/#individual-block-locking

Most of the components of the top section should be definable as single blocks, while several will potentially need a more complex implementation. Here's an initial rundown:

1. The top-level block might be a Columns block, to enable the left-hand avatar photo. The Columns block will allow us to inherit some responsiveness. On the other hand, we don't really want users to be able to edit the column dimensions, so we might think about using custom styling for this side-by-side appearance instead.
2. The avatar upload can probably use the Featured Image block. We might build something into the CV provisioning process so that the default Featured Image is copied from the user's CAC avatar.
3. The cuny.is link is generated automatically, and every user has one. But it is currently editable by the user, so we'll probably need to build a custom block in order to enable editing.
4. The 'Active...' section will be a "dynamic" (ie PHP-generated) block.
5. The user's name ("Matthew K. Gold") can likely be a heading block. As in 2, we can probably pre-fill it with the Commons display name.
6. The Pronouns section can probably be an editable field (maybe a plain Input?) that can be pre-populated from the user's Commons settings, but like everything else, I think it should be separately editable (or deletable) for the purposes of the CV.
7. The user title ("Associate Professor...") can likely be a heading block. But I'm not sure whether we're maintaining this separately as a non-CV field as well, for use in directories. If so, we can pre-fill with that value.
8. The user description ("My research & teaching interests...") could be multiple paragraphs, so I think it will probably need to be a custom block that has a limited allowedBlocks.
9. 'View Commons Activity' link/button can be static HTML
10. For 'Find me Online', do we want to leverage WP's Social Links block? One consequence would be that the data would be stored in post_content rather than as separate usermeta, making it harder to use elsewhere on the Commons. I don't think we currently do use it elsewhere, though.
11. 'Contact' in the mockup has two different fields, for phone number and for email. We could do something like this, or simply make it a text field that people can add whatever they want to (along with some helper text). Here too we will have to decide whether the information should be pre-filled from CAC account information - my thought is that it probably should not be in the case of contact info.
12. Website and Blog can be single blocks

Hopefully this will be a good starting place for discussion about how this section of the CV will work.


Subtasks 1 (1 open0 closed)

Feature #18585: CV shortlink / cuny.is blockTesting RequiredBoone Gorges2023-08-11

Actions

Related issues

Related to CUNY Academic Commons - Feature #17768: CV Editing and PublishingNewJeremy Felt2023-03-04

Actions
Actions #1

Updated by Boone Gorges 5 months ago

Actions #2

Updated by Boone Gorges 5 months ago

  • Description updated (diff)
Actions #3

Updated by Jeremy Felt 4 months ago

This is a great start, thanks Boone!

1. The top-level block might be a Columns block, to enable the left-hand avatar photo. The Columns block will allow us to inherit some responsiveness. On the other hand, we don't really want users to be able to edit the column dimensions, so we might think about using custom styling for this side-by-side appearance instead.

I'm wondering if the entire top section can be a custom block, with columns and their dimensions already set. It can then have inner blocks with placeholder (or migrated) content for the other items. This should support a generally consistent look across CVs.

2. The avatar upload can probably use the Featured Image block. We might build something into the CV provisioning process so that the default Featured Image is copied from the user's CAC avatar.

Also noting the header/cover image in https://www.figma.com/file/0Ke5bCwheE5SXXkT6wDd2l/CUNY-Design---Spring-2023?type=design&node-id=2889-67603&t=nxd6WCGIOuEFFouv-0, which could be a cover block.

6. The Pronouns section can probably be an editable field (maybe a plain Input?) that can be pre-populated from the user's Commons settings, but like everything else, I think it should be separately editable (or deletable) for the purposes of the CV.

I think this makes sense. Would some kind of one-time notice at the top of the editor make sense that helps to set expectations? A better version of: "Your CV has been prepopulated with existing CAC data. Any future changes in your CAC profile or this CV will not be copied."?

9. 'View Commons Activity' link/button can be static HTML

This area is static, but should be generated dynamically in PHP based on the logged in/logged out view.

10. For 'Find me Online', do we want to leverage WP's Social Links block? One consequence would be that the data would be stored in post_content rather than as separate usermeta, making it harder to use elsewhere on the Commons. I don't think we currently do use it elsewhere, though.

The interface in the Social Links block is pretty nice. It wouldn't be tough to capture that block's values on CV save and sync with usermeta (or to prepopulate then with existing usermeta).

11. 'Contact' in the mockup has two different fields, for phone number and for email. We could do something like this, or simply make it a text field that people can add whatever they want to (along with some helper text). Here too we will have to decide whether the information should be pre-filled from CAC account information - my thought is that it probably should not be in the case of contact info.

+1 for a simple field (maybe even paragraph) with helper text. It could be something to revisit down the road and see how people are using it.

Actions #4

Updated by Boone Gorges 4 months ago

I'm wondering if the entire top section can be a custom block, with columns and their dimensions already set. It can then have inner blocks with placeholder (or migrated) content for the other items. This should support a generally consistent look across CVs.

Yes, this sounds right. The "columns" block idea was just spitballing, but I think it's probably better to have a unified block with all the interior layout hardcoded.

Also noting the header/cover image in https://www.figma.com/file/0Ke5bCwheE5SXXkT6wDd2l/CUNY-Design---Spring-2023?type=design&node-id=2889-67603&t=nxd6WCGIOuEFFouv-0, which could be a cover block.

I forgot to include this in my list, so yes. I'm not sure how this works structurally - the Cover block might have to be a wrapper for everything else?

Actions #5

Updated by Jeremy Felt 3 months ago

In the feature/17769-commons-profile branch, we now have...

  • CV Top is a block that applies the pattern at the top of the CV through a template of inner blocks. Quite a few of those (for the moment at least) are paragraphs or headings.
  • CV Shortlink is a block that currently acts as a paragraph, but will be refined to handle the shortlink data.
  • CV Last Active is a block that displays the BuddyPress last active date. (This doesn't render properly yet in the editor, but seems to on a front-end view)
  • CV Profile Navigation is a block that will display the buttons/links used to navigate between the CV and other profile sections.
  • CV Bio is a block solely used to create some boundaries around the short bio section of one or more paragraphs.

These blocks are all added with their placeholders when a profile is created. This is not a final version, but moves the posts quite a bit. I'll be working through these to keep refining. I have not done any work on visual refinement.

Actions #6

Updated by Boone Gorges 3 months ago

Awesome! This is looking very cool.

I know you haven't done any visual refinement, but we'll probably need to do some thinking about the Avatar section, to ensure that uploaded items are cropped to the proper dimensions.

Speaking of images, have you thought at all about the "cover image" type of functionality shown at https://www.figma.com/proto/0Ke5bCwheE5SXXkT6wDd2l/CUNY-Design---Spring-2023?page-id=2888%3A56943&node-id=2889-67603&viewport=3501%2C4218%2C0.13&scaling=min-zoom?

CV Last Active is a block that displays the BuddyPress last active date. (This doesn't render properly yet in the editor, but seems to on a front-end view)

I'm not sure why bp_displayed_user_id() isn't returning the proper value in this context - must have something to do with the sandboxing done by the front-end editing? Passing get_current_user_id() to bp_last_activity() is probably a fine workaround, since in 99% of cases users will only be able to edit their own CVs.

Actions #7

Updated by Jeremy Felt 2 months ago

CV Top is shaping up pretty well. There are some annoyances (as with any block editor work) in matching the non-editor view with the editor view. I'm getting close to having the styles dialed in and I don't think we're too far off on the blocks.

Up next, beyond continued style adjustments:
  • Account for a cover image in the template
  • Improve avatar/profile image handling * Set the correct ratio for any uploaded images * Fallback to the default avatar if no image is available
  • CV Shortlink (Spin this off as another ticket/feature)
  • Pass correct user ID to CV Last Active block in editor
  • Make CV Profile Navigation buttons context-aware

A question: I first added "Contact" as a paragraph block, but I'm wondering if this makes sense as a preformatted block instead? I'm trying to imagine how varied this content will be. Some people may just want one phone or email. I assume others may want to add an office location or multiple points of contact. How much should we account for here?

Related: We could treat the "Contact", "Website", and "Blog" a bit more general and—similar to the CV Rows area—have a sort of free form key-value area.

I'll chat about this on the call today.

Actions #8

Updated by Jeremy Felt about 2 months ago

CV Shortlink
Pass correct user ID to CV Last Active block in editor

Boone - I've just pushed a change that registers `userId` as an attribute for the cv-shortlink and cv-last-active blocks. Each attempts to autofill this from a global object when first loaded, if an ID is not already assigned.

I was hoping to use block context, but it turns out this isn't yet supported for server-side rendered blocks.

Note: we'll need to account for this attribute on each block during migration.

Actions #9

Updated by Jeremy Felt about 2 months ago

I'm close on an approach for profile and cover images, but may have started to overthink it. Let's see...

The profile image block should be a custom block that renders either a user-provided image or a mystery avatar. This block provides an interface for uploading or removing an image and provides the default avatar if one is not entered.

We likely don't want to rely on the WordPress media library for all of this. Users won't need access to a "library" of their uploaded images and sorting out permissions may be a bear. We can instead direct the uploads elsewhere and skip offering a list of previous uploads.

So a couple questions:

  • Does that sound right?
  • Should we continue to use the same directory for storage? (files/avatars/) Or maybe files/cv/avatars and files/cv/covers/

Aside: we could always create a filename structure that does allow for browsing previous uploads, but that's probably overkill. :)

I have more thoughts on the cover image that I'll share on the call and note here afterward.

Actions #10

Updated by Boone Gorges about 1 month ago

I've opened #18585 to track the cv-shortlink block.

Does that sound right?
Should we continue to use the same directory for storage? (files/avatars/) Or maybe files/cv/avatars and files/cv/covers/

Yes, let's not use the Library. /files/cv/avatars and /files/cv/covers seems right to me. BP will continue to use its native /files/avatar, and we should probably leave that directory alone. And there's a chance we might want to leverage BP's cover system for Commons Profile in the future. So let's have our own CV directories. Definitely skip the ability to roll back and/or view old uploads for now.

Actions #11

Updated by Jeremy Felt 20 days ago

I've dialed in quite a bit of the profile and cover image handling in the feature/17769-commons-profile branch.

Profile/avatar image

The WordPress core image block is so tied to the media library that I decided to make a custom CV Profile Image block to handle avatars. When a file is upload through here it is stored in files/cv/avatars and prefixed with a unique ID to avoid collision with filenames. The final URL is stored as the imageURL attribute on the block. I went with this rather than post meta only because it seemed more straight forward. If we'd like to use this data elsewhere it may make sense to save as post meta instead/as well.

<!-- wp:cac/cv-profile-image {"imageURL":"https://commons.test/files/profiles/6ec2e0c4-3de9-4c06-bf0a-d04c2f7dc0bd-d1759b1c669981b7c52ec9a97d19e6bd.jpeg"} /-->

The block supports adding/removing the image. I've started to think through a "replace" workflow, but it may be fine to just require remove/add again.

My next step here is to fine tune the sizing and figure out what our options are for communicating the size of image and/or maybe helping the user crop and resize. The downside of not using the media library is having to work through this (or not!).

Cover image

I've added another button/link to the top bar of the editor to "Add cover image". This image is stored as post meta because I'm not treating it as part of block content. Right now it only appears in the editor view as a background image on the editor itself. I've just got this working so I'm working through the sizing/display still.

Once a cover image is added, the button becomes "Remove cover image" and... removes it. This works, but does not yet reflect in the editor. I'll have that shortly! :)

Any existing cover images will need to be migrated to the cac_cv_cover_image_url meta key.

Actions

Also available in: Atom PDF