User - View canonical registry

[jamlung-ri]

Similar to what was outlined in this comment: https://github.com/OpenConceptLab/ocl_issues/issues/1799#issuecomment-2228400934

A new CTA needs to be added to the user profile design for "View Canonical Registry" for that user, if it exists (many users will not have one, so we need to provide an indicator if they do). See below for a picture of the current canonical URL registry tool, filtered to view jamlung's list.

Example registry view that is currently filtered to CIEL:

[paulsonder]

Hey @jamlung-ri

I've been thinking through Registries in context of a User or an Organization... the UX of taking a User into their Settings with a filtered view of the Registry tool doesn't feel so efficient... I thought we might consider showing the details in a modal so the User can remain in context?

Does the User need to be able to take any actions on the information?

[jamlung-ri]

Hey @paulsonder, good questions. Jon and I just spent most of the Dev call talking about this.

A combination of both the indicator and the modal preview window should be good. One main note: A user mainly just needs some registry info if registries have been configured. That part should be made obvious to the user, and if there are no entries, there’s no need to show this indicator.

Let me put some user stories below:

• User story: As a consumer, I want to see an indicator that this organization or user has defined entries in its canonical URL registry so that I can be aware that the way that Canonical URLs are resolved in the namespace has been configured by this org’s/user’s admins.
• User story: As a consumer, I want to see a light view/summary of their canonical URL registry so that I understand what they have configured for canonical URL resolution.
  • Note: Users will only need to define registry entries if they are changing how OCL resolves these canonical URLs, so the most common user will not have a namespace registry configured. Meaning, these users would not show an indicator about having a canonical registry.

This light view might look something like this, where it is simply a filter and a table of each entry’s values for the following attributes: Canonical URL, Target Namespace (i.e. the target registry being queried), and the actual Repository to which it resolves. Then perhaps there can be a button to take you to the Canonical URL Registry area in Settings?

Does this make sense? This canonical registry stuff can be hard to talk about so no worries if more info or better descriptions are needed.

[paulsonder]

Hello @jamlung-ri

I created a simple prototype, check out the video here.

The Canonical Registry is displayed in the overview panel. That should help users to discover that functionality, as well as providing a snap shot of how many Canonicals an Owner has in their registry. Once clicked, the detail opens in a modal window, so the User does not need to navigate away from the page.

CC @paynejd

[paulsonder]

@jamlung-ri The example I worked on was for Orgs rather than Users, but the same principal will apply. Let me know what you think of the approach.

[jamlung-ri]

Awesome! It feels really good, and it seems both non-intrusive and clear.

Do you think the "Learn more" button will take the user to the Settings version of this, which also includes the educational content? Or do you think those two things should be separate? I do think that having a pointer to your Settings page to test canonical URLs is going to be needed somewhere or another, whether it's in the model window or elsewhere.

[paynejd]

All this looks great! Only comment is that "Learn more about Canonical URLs" doesn't seem like the right language -- the "4 entries" could be clickable itself to see the canonical URL entries. These entries are owned by the Org/User, so those are personal. "Learn more..." makes it seem like global or help content.

On Tue, Jul 16, 2024 at 10:36 AM Joseph Amlung @.***> wrote:

Awesome! It feels really good, and it seems both non-intrusive and clear.

Do you think the "Learn more" button will take the user to the Settings version of this, which also includes the educational content? Or do you think those two things should be separate? I do think that having a pointer to your Settings page to test canonical URLs is going to be needed somewhere or another, whether it's in the model window or elsewhere.

— Reply to this email directly, view it on GitHub https://github.com/OpenConceptLab/ocl_issues/issues/1888#issuecomment-2231084315, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJCOON2X2N3HAF3IS2AQY3ZMUVV7AVCNFSM6AAAAABK5EQXMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRGA4DIMZRGU . You are receiving this because you were mentioned.Message ID: @.***>

[paulsonder]

All this looks great! Only comment is that "Learn more about Canonical URLs" doesn't seem like the right language -- the "4 entries" could be clickable itself to see the canonical URL entries. These entries are owned by the Org/User, so those are personal. "Learn more..." makes it seem like global or help content. … On Tue, Jul 16, 2024 at 10:36 AM Joseph Amlung @.> wrote: Awesome! It feels really good, and it seems both non-intrusive and clear. Do you think the "Learn more" button will take the user to the Settings version of this, which also includes the educational content? Or do you think those two things should be separate? I do think that having a pointer to your Settings page to test canonical URLs is going to be needed somewhere or another, whether it's in the model window or elsewhere. — Reply to this email directly, view it on GitHub <#1888 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJCOON2X2N3HAF3IS2AQY3ZMUVV7AVCNFSM6AAAAABK5EQXMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRGA4DIMZRGU . You are receiving this because you were mentioned.Message ID: @.>

Actually it is the '4 entries' that I clicked to open it. The 'Learn more' link would either be to a help doc or as @jamlung-ri mentioned to the Canonical URL tool itself, where we could also include some educational content - I do love that idea.

[paulsonder]

@jamlung-ri @paynejd What would you think about including it here? This would be clickable, to expose the modal.

[jamlung-ri]

Hmm interesting. I do like how cleanly it fits into the screen. There's one bit of context that I talk through in this Loom video that might play a role in this: https://www.loom.com/share/4be2ade301e84c908dcb38019edee9f5?sid=7cc0592f-1c35-4594-be3f-a4abfab1a3c9

Basically, orgs/users would probably be okay to have this more subtle indicator, but repositories might need something with a little more pop to tell the user that the content in this repo might resolve differently than what a user is commonly used to.

@paulsonder Does this context change how you're thinking about this?

[paulsonder]

Thanks Joe, super useful feedback.

1. It seems we need to be very clear when a Canonical(s) is affecting a particular Repository
2. I think we should probably try to be consistent with how indicate to Users that Canonicals have been added to a Registry and are affecting content.

Let me take this away and come back to you today.

[paynejd]

Quick changes for the Org header -- this is based on what Sunny has implemented, not on Paul's designs:

• Org header must include the org ID (this is in the design) and "Created" date without going to additional attributes
• Additional attributes implies that you would not show the attributes from the header again, but we are showing everything twice -- can we remove the redundancy?
• Add "X" button to the top-right as an additional way to close the Additional attributes window?
• The additional attributes window should have a title that isn't the name of the org -- why not just "Organization Attributes"?