[UXD Spike] Confirmation dialogs for competency criteria edits and deletes

This is a design spike. The deliverable is design artifacts and documented decisions, not working code.

User Story

As a course author or platform administrator, I want to be warned before I change or remove competency configuration, in order to understand what my change will and will not do to learners who have already been evaluated.

Delivery checklist

Design the confirmation dialog shown on every edit of a CompetencyCriteria or CompetencyCriteriaGroup. Starting text to refine: "Change this rule? Changing this will only affect future evaluations of this competency. Learners who have already been evaluated against the current rule will keep their existing status." Buttons: Cancel / Save Changes.
Design the confirmation dialog shown on every delete of a CompetencyCriteria or CompetencyCriteriaGroup. Starting text to refine: "Delete this [criterion/group]? This action cannot be undone from this screen. Existing learner mastery statuses will not be affected." Buttons: Cancel / Delete.
Design the confirmation dialog shown when deleting an ObjectTag association from the Competency Management page. Starting text to refine: "Delete this tag association? This action cannot be undone from this screen. Existing learner mastery statuses will not be affected." Buttons: Cancel / Delete.
Confirm all three read correctly for an author who does not know, and is not meant to know, whether the record will be archived or hard-deleted underneath.
Specify responsive and small-screen behavior for each dialog.
Specify accessible behavior for each: focus on open and on close, what a screen reader announces, keyboard dismissal, and which button takes initial focus.
Update the Competency Criteria Figma file with all three dialogs and link it here.
Document each resolved open question below as a decision with its rationale, in a form the implementation tickets can quote.

Description

Deleting or editing competency configuration on the Competency Management page happens immediately today, with no confirmation step at all. Underneath, a delete will soon either remove the record or archive it, depending on whether any learner has already been evaluated against it, and the author is deliberately not told which. One wording therefore has to be true in both cases.

#785 implements the edit dialog. The delete dialog for CompetencyCriteria/CompetencyCriteriaGroup is implemented by #709 and #710, which need updating to add it. #786 implements the ObjectTag association-delete dialog.

Context for the Designer

How the two outcomes differ underneath, and why the dialog cannot say which applies. When no learner has been evaluated against a record, deleting it removes it outright. Once any learner has a mastery status against it, deleting it hides it instead and keeps the row so learner statuses stay traceable. The author cannot tell which case they are in, and product decided they should not need to. So the wording can promise that existing learner statuses are unaffected, and that the action cannot be undone from this screen, without claiming the record is destroyed.

Edits behave differently from deletes. An edit never removes anything and never changes a learner's already-recorded status. Changes apply only to evaluations that happen afterwards. That is why the edit wording talks about future evaluations rather than about data loss.

The edit warning is unconditional, appearing on every criteria and group edit rather than only when learner statuses already exist. Product chose this so behavior is consistent rather than a dialog that appears unpredictably.

The edit dialog has no "do not show this again" option. Letting an author silence it after one click would recreate the same unpredictability product chose the unconditional warning to avoid. If this needs revisiting, it is a scope change for product to approve, not something the designer decides here.

Tag and Taxonomy edits get no warning at all. Renaming a tag or editing taxonomy metadata does not change how mastery is computed, so those flows are out of this spike.

Related tickets. #785 implements the edit dialog. The delete dialog for CompetencyCriteria/CompetencyCriteriaGroup is implemented by existing tickets #709 (group delete) and #710 (criterion delete), which currently delete with no confirmation step and need updating to match this spike. #786 implements the ObjectTag association-delete dialog.

Open Questions

Should the delete wording differ between a CompetencyCriteria and a CompetencyCriteriaGroup? Deleting a group also removes every association inside it, which is materially more destructive, and the current single wording does not say so. Owner: designer, with the BA.
Is one shared dialog component right for all three, or should edit and delete look visibly different so an author does not confuse them? Owner: designer.
Does the association-delete dialog need to name which competency and which content object the association joins, so an author deleting one of several can tell them apart? Owner: designer.

@jmakowski1123

@jmakowski1123 @thelmick-unicon: for this ticket I'm aligning the delete flow in Figma with #709/#710/#786 and the backend (#674/#675). Two things:

Drop the trash icon on rule boxes ("With a score of…"). They aren't saved records ([FE] Confirm every deletion of a tag association from the Competency Management page #786), and authors clear them chip by chip.
Keep delete on both course-level and bottom-tier groups. It's small: [BE] Build endpoint for removing a Competency Criteria Group #675 already supports course-level deletes, and it reuses [FE] Delete Competency Course & Rule Groups #709's dialog and endpoint, so it's one more trash button. @thelmick-unicon, could [FE] Delete Competency Course & Rule Groups #709 say it covers both levels? @jmakowski1123, OK to have course-level delete in scope? If not, authors can still delete bottom-tier groups one at a time, and the course block disappears when its last group goes.

I'm also dropping the "can't delete the only rule/group" blocks in favor of #709/#710's behavior (the parent is removed too, with a placeholder fallback). The dialog will say when that's about to happen.

cc @AShatsila: please hold off on the rule-box trash and any disabled "can't delete" states in #709/#710 until this settles.

@jmakowski1123

@jmakowski1123 @thelmick-unicon: this follows up my comment above with the designs for this spike, plus a correction.

Figma (CBE Stories): Delete flow · Edit flow

Needs a decision

@thelmick-unicon: keep or close [FE] Delete a Competency Rule Box #833 (delete a rule box)? If it stays, should it make one [BE] Delete Competency Criterion #674 call per criterion, or use a bulk endpoint? Details under "Ticket updates" below.
@thelmick-unicon: suggested edits for [FE] Confirm every deletion of a tag association from the Competency Management page #786, [FE] Confirm every edit to a competency criterion or criteria group #785, [FE] Delete Competency Course & Rule Groups #709 and [FE] Manage & Apply Competencies: delete a Competency Criteria Association #710 are also under "Ticket updates".
@jmakowski1123: is course-level delete in scope (from my comment above)? And are you OK with Remove for unlinking content or a course, and Delete for a group the author built?

Open questions from this spike, answered

Different wording for a criterion and a group? Yes. The group dialog says what else it removes, with a count. When the group is the course's only one, it also says the course will stop counting toward the competency. Every delete dialog ends with the same line, which is true whether the record is archived or hard-deleted: "This can't be undone from this screen. Learners keep any mastery status they already have."
One shared dialog, or visibly different edit and delete dialogs? One shared dialog: Studio's existing DeleteModal, which is Paragon's AlertModal. Deletes get the red danger button, and edits get the blue primary "Save changes". Every title is a question that names what's changing.
Should the association dialog name both sides? Yes: "Remove 5 Whys + Fishbone Deep Dive from Inference?" The names go in the title because Paragon's dialog announces only its title to screen readers.

Delete: where it starts

Content keeps its chip ✕, in both places [FE] Confirm every deletion of a tag association from the Competency Management page #786 names: a rule box, and the Browse Courses (Courses & Content) panel. Both open the same dialog.
Groups and courses get a ⋮ menu instead of a trash icon, with one item that names its scope: "Delete group" on a group, "Remove from Inference" on a course.

Why a ⋮ menu:

It's already how Studio does this. Course outline cards and taxonomy tag list rows both put Delete in a ⋮ menu that opens a confirmation.
The menu item says what gets deleted. The earlier design had identical trash icons about 40px apart that deleted different amounts.
It's harder to hit by accident, and it leaves room for more group actions later without a redesign.
Size: it's Paragon's IconButton at Inline size (24px), to keep the nested rows light. Studio uses sm (36px) in the tag list and the default (44px) in the course outline, if we'd rather match one of those.
Deleting the last item is allowed, as in [FE] Delete Competency Course & Rule Groups #709 and [FE] Manage & Apply Competencies: delete a Competency Criteria Association #710. The parent is removed too, and the dialog says so. There are no disabled "can't delete" states.

Delete: the dialogs

Plain Cancel / Delete (or Remove), matching DeleteModal. There's no type-to-confirm. Studio reserves that for deleting a whole taxonomy, whereas here learner statuses survive, and removing content is a routine correction ([FE] Manage & Apply Competencies: delete a Competency Criteria Association #710).
Shown on every delete, for the same reason the edit warning always shows. The one exception is an unsaved placeholder box, which [FE] Delete Competency Course & Rule Groups #709 removes without contacting the server.
Counts and the competency name are bold, so what's affected stands out.

Edit: adding the Save step that #785 needs to intercept

#785 points out that there's no save step to intercept, because both edit controls apply as soon as they change. The designs add one:

Score: the popover gets Cancel and Save buttons, following Studio's inline edit in the taxonomy tag list. Save opens the dialog. Cancel in the dialog returns to the popover with the new value still entered.

any/all: choosing a new value opens the dialog immediately. Cancel switches back to the old value, because a dropdown has no unsaved edit to keep on screen.

When a delete or save fails

The dialog stays open with a danger Alert at the top, and the button can be pressed again to retry.

This keeps the author's change, which [FE] Confirm every edit to a competency criterion or criteria group #785 requires.
It follows Studio's SaveErrorAlert in the taxonomy table.
The Alert stays until the author acts on it. A toast disappears after a few seconds.

Ticket updates this needs

#833, and a correction to my comment above. I said no ticket covers deleting a rule box, but #833 does. A rule box isn't a record of its own: its score is stored on each criterion, and #672 draws one box for the criteria in a group that share a score. So deleting a box means deleting each criterion in it. There are two ways to do that:

One [BE] Delete Competency Criterion #674 call per criterion. This needs no new backend work, but it can partly fail. Each call commits on its own, so if the second of three calls fails (a network drop, a server error, or a permission change partway through), the first criterion is already gone and the frontend can't undo it. The author is left with a half-emptied rule box.
A bulk endpoint that removes all of the box's criteria or none of them. This is cleaner, but it's new backend work.

If #833 stays, the design adds a third ⋮ on the rule box with "Delete rule", and a dialog that gives the count.

#786's scope paragraph needs updating if #833 stays. Suggested replacement:

Four ways to delete an association on this page are in scope: the "X" on a chip in the Browse Courses (Courses & Content) panel, the "X" on a chip in a rule box's Selected Content list, the control to delete a whole rule box (#833), and the control to delete a whole criteria group (#709). A rule box isn't a saved record of its own. It's the criteria in a group that share one score, so deleting one removes each criterion in it, and it shows the same confirmation.

#786 would also need a matching acceptance criterion: "Deleting a whole rule box shows the confirmation too."

#786's Figma link points at the sidebar frame ("2 Competencies applied to…"), but no ticket builds the sidebar. Could it point at the chip-removal dialog instead?

#785: the acceptance criterion that the author's unsaved edits are still on screen after Cancel holds for the score popover. It doesn't hold for the any/all dropdown, where Cancel restores the old value.

#709 and #710 error handling: both say to follow #672's error pattern, which is a toast. For failures inside a confirmation dialog, they should use the in-dialog Alert described above instead.

#709 and #710 Figma links: no change needed. The frames they link to now show the revised designs: #709 (group menu), #710 (chip ✕ entry points).

CC: @mgwozdz-unicon

@jmakowski1123

@jmakowski1123 @thelmick-unicon: a friction idea for the edit confirmation (#785). Most rule setup happens before a course starts, when no learner can have been evaluated, so the "only affects future evaluations" warning is noise there. Open edX knows each course run's start date (#669 already filters on it). Could we skip the edit confirmation for courses that haven't started, and show it once they have? We'd label each course block with its start date ("Starts Jan 6" / "Started Aug 15"), so authors can see why one course asks and another doesn't. Delete confirmations would stay on every delete. Caveat: beta testers and staff test submissions can create learner data before the start date.

@thelmick-unicon

fyi - The intention for #833 is for it to call #674's endpoint for each criterion in the group. If we wanted to remove some scope, we could delete this ticket, though it is part of the current sprint.

@thelmick-unicon and @illiphilli fyi - #775 is intended to only impact tickets in Epic 10 (#723 ). I'm not sure if all of the tickets Phil listed that "need updating" are in Epic 10 or if some of them are in Epic 5, but the intention is to leave Epic 5 alone and add these dialogs as part of Epic 10.

@jmakowski1123 @thelmick-unicon: a friction idea for the edit confirmation (#785). Most rule setup happens before a course starts, when no learner can have been evaluated, so the "only affects future evaluations" warning is noise there. Open edX knows each course run's start date (#669 already filters on it). Could we skip the edit confirmation for courses that haven't started, and show it once they have? We'd label each course block with its start date ("Starts Jan 6" / "Started Aug 15"), so authors can see why one course asks and another doesn't. Delete confirmations would stay on every delete. Caveat: beta testers and staff test submissions can create learner data before the start date.

@illiphilli I think it would be scope creep to only show the edit confirmation for courses that have already started.

@mgwozdz-unicon

@mgwozdz-unicon thanks, that clears things up. Here's the updated plan with your points and last week's sync folded in.

Start-date gating: dropped. The edit confirmation shows on every edit, as #785 says now.

Ticket updates are limited to Epic 10 (#723). In my 9/30 list, #709, #710 and #833 are in Epic 5 (#721), so I'm withdrawing those suggestions. Only #785 and #786 are left:

[FE] Confirm every deletion of a tag association from the Competency Management page #786's scope paragraph: already covers all four ways to delete, [FE] Delete a Competency Rule Box #833 included. Thanks, @thelmick-unicon. No change needed.
[FE] Confirm every deletion of a tag association from the Competency Management page #786's Figma link still points at the sidebar frame, which no ticket builds. It should point at the chip-removal dialog instead.
[FE] Confirm every deletion of a tag association from the Competency Management page #786 error handling: when a delete fails, the dialog should stay open with a danger Alert, not close and show a toast. This is the in-dialog failure state in the delete flow. [FE] Confirm every edit to a competency criterion or criteria group #785 already keeps the author's edits on screen when a save fails, which matches.

#833: one #674 call per criterion. Understood. #833 already says what to do if that partly fails: tell the author some of the box's content couldn't be removed, and show exactly what's stored. So the design needs no other change. Per the 10/7 sync, I'm adding a ⋮ menu to the rule box with a remove option, plus its dialog with the criteria count. I'll link it from #833 when it's done.

One question: at the 10/7 sync we agreed to swap the trash icons for ⋮ menus, but those trash icons come from Epic 5 tickets (#709, #833). Should those two tickets switch to ⋮ now? Or should Epic 5 ship the trash icons and #786 swap them for menus when it adds the dialogs? The first means less rework, but it changes Epic 5. Your call.

Wording: the sync settled on "Remove" across the interface, so I'm changing the "Delete group" and "Delete rule" labels and dialog buttons in Figma to "Remove". @jmakowski1123, this also answers my 9/30 Remove vs Delete question, and #709 already covers course-level groups, so I don't need anything else from you here.

@illiphilli

@illiphilli Let's ship Epic 5 with the three dots because I think that will be a small change and easy switch. Could you please help get the screenshots updated in the impacted tickets?

@mgwozdz-unicon

@mgwozdz-unicon done. The ⋮ is now part of the components in Figma, so every frame shows it at all three levels: course, group and rule box. Here's what changes in each Epic 5 ticket:

#709 (remove course and rule groups)

Screenshot: replace with the attached one. The menu item now reads "Remove group". The Figma link is unchanged.
Text (@thelmick-unicon): "trash can icon" becomes "the ⋮ menu's Remove group item" on a Rule Group, or Remove from [competency] on a Course Group. That's in the description and in the ACs. The rule that hides it on courses I can't edit now applies to the ⋮ button itself.

#833 (remove a rule box)

Screenshots: replace with the attached menu and dialog.
Add Figma links: ⋮ menu · dialog. The dialog is [FE] Confirm every deletion of a tag association from the Competency Management page #786's to build. It's here so the whole flow is in one place.
Text: "trash can icon" / "trash control" becomes "the ⋮ menu's Remove rule item".

#710 (remove a criteria association)

Chips keep their ✕, so the flow itself doesn't change. Both screenshots still show trash icons on the groups and rule boxes, though, so I've attached replacements. The Figma link is unchanged.

#670 (course search/view)

Its screenshot also shows the old trash icons. The replacement is the frame it already links to.

Wording: every label and button now says "Remove", per the 10/7 sync.

Accessible names for the ⋮ button: "More actions for this group", "More actions for this rule", and "More actions for [course name]".

Navigation Menu

Repository navigation

[UXD Spike] Confirmation dialogs for competency criteria edits and deletes #775

User Story

Delivery checklist

Description

Context for the Designer