[UXD] Build the UI for Competency Criteria Associations

[thelmick-unicon]

[UXD] Manage & Apply Competencies: design review and sign-off

Task #648 — the parent of the Manage & Apply Competencies work. This is a design review and sign-off ticket: the finished designs already exist, and this ticket is the vehicle to present them for team review and record agreement. The deliverable is reviewed, signed-off design artifacts, not code.

Children (implementation): #671 (create / remove Competency Criteria Groups), #672 (select / deselect gradeable-subsection associations). Foundation: #670 (the page, its competency tree, and the course-search / browse panel). Repo (eventual build): frontend-app-authoring.

Use Case

As a course author who will use the Manage & Apply Competencies page to build competency criteria, I want the finished designs for the whole page reviewed and signed off by the team, so that the shipped authoring experience matches validated intent and #670/#671/#672 don't build against designs that get re-litigated mid-implementation.

Description

Finished UX designs exist for the entire Manage & Apply Competencies page: the page shell and two-panel layout, the competency tree, Competency Criteria Groups (create, nest, remove), and gradeable-subsection associations (select, deselect, already-associated, and blocked/rejected states). No code exists for this page: #670, #671, and #672 are all unbuilt.

Figma link to existing designs: https://www.figma.com/design/VhAdaucNQS49x0Afp9xPZw/Competency-Application?node-id=3-45424&t=zImspZK8unjhmx3e-4

Delivery Checklist

The deliverable is a reviewed and signed-off set of design artifacts, not code. There is no Gherkin and no QA path; acceptance is this checklist completed and sign-off recorded.

• Finished designs for the full Manage & Apply Competencies page linked on this ticket.
• Page shell / two-panel layout reviewed.
• Competency tree and its selection behavior reviewed.
• Competency Criteria Group screens reviewed: create, nest (up to 3 levels), remove, and the AND/OR ("within all" / "within any") control.
• Gradeable-subsection association screens reviewed: select, deselect, already-associated indication, and the blocked/rejected state (dominance validation).
• Any requested changes or re-litigated decisions documented on this ticket, with rationale.
• Final sign-off recorded, confirming the designs are ready for [FE] Build the competency-selection tree, Course Search, and gradeable-subsection browse UI for Competency Criteria Associations #670/[Placeholder for FE] Build the create / remove Competency Criteria Group interactions #671/[Placeholder for FE] Build the select / deselect gradeable-subsection association interactions #672 to build against.
• Sign-off and any resulting design updates communicated to [FE] Build the competency-selection tree, Course Search, and gradeable-subsection browse UI for Competency Criteria Associations #670, [Placeholder for FE] Build the create / remove Competency Criteria Group interactions #671, and [Placeholder for FE] Build the select / deselect gradeable-subsection association interactions #672.

[jmakowski1123]

I know this ticket is not groomed yet, but flagging early that this will spark conversation around implementation details. Namely, should this whole page be a brand new MFE? If so, what are the implications of that? cc @arbrandes @illiphilli

[bradenmacdonald]

@thelmick-unicon Thanks for the ping to review these. I am not planning to review the UX designs in detail, so I'll leave that to other people.

However, this looks like a large and complex UI, and if it will be implemented in the Authoring MFE, I'd definitely like to discuss the technical implementation plan in significant detail once the UX design is finalized.

@jmakowski1123

Namely, should this whole page be a brand new MFE? If so, what are the implications of that?

I would lean toward building it as a new MFE, using frontend-base. That will let the team that's building it move a lot faster, and I believe frontend-base is designed to make it easier to incorporate smaller, special-purpose MFEs like this.

If we were to implement it in the existing Authoring MFE, as I mentioned, I'd want to take a very specific approach to how we built it, factoring out common patterns in the existing codebase and doing a better job of reusing components and patterns across the whole codebase. That said: I do have a high-level concern, which is that overall "look & feel" doesn't match any other parts of Studio (the Authoring MFE) too closely. I don't generally prefer one thing or the other, but we already have a problem with UX consistency and I'd like to make it better, not worse, with any new work. Even if this is a new MFE, if it's accessed from Studio, it may be a bit jarring if the UX language is suddenly fairly different.

BTW, what's the status of the Studio UX pattern guide / Figma template that Schema was working on? CC @edschema

• One the course outline and the library page, the main atomic cards are white but here ("Analysis", "Evaluation", etc.) they are grey. i.e. in courses, the tree is White-Grey-White but here it's Grey-White-Grey.
  
• I don't think we've used the light blue / light purple / light pink color scheme seen on the right hand side.
• The overall two-column layout is reminiscent of the sidebar pattern we've adopted for courses and libraries, but I see there is also an actual sidebar in some cases, and this one is modal, overlapping the content, whereas the course and library sidebars are not modal and do not overlap the content.
  
• Courses, Taxonomies, and Libraries all use the "three dots" vertical ellipsis to reveal an action menu, but I don't see that here.
  
• The search/filter bar looks great but doesn't match our existing patterns.