Explore: Delete and remove

[oliviaflory]

We need to have a better understanding of the current Delete and remove pattern in order to determine if it is a component, pattern or guidance based on the new definitions.

Definitions

Component

An asset that has been designed and coded

• Export is a component because there is a coded modal provided specifically to export

Pattern

Something that can be accomplished in multiple ways utilizing a combination of component(s) with additional design considerations (a recipe of components)

• Patterns may provide coded examples, but will not be required to provide code or support every possible instance of a pattern
• Dashboards are patterns because you can build a dashboard in many different ways
  • Various sized tiles
  • Various components, actions, information within those tiles

Guidance

Overarching direction or instruction that can be applied across an entity

• As you move further away from the “core” of the spoke, we may see more detailed guidance and opinion on guidance at the “spoke” levels
• Content is guidance because we apply the same principles across all IBM experiences and services
  • Capitalization rules
  • How to display dates

---

Tasks

• Read the current (Delete and) remove documentation
• Review the current Delete and remove code
• Answer: Do delete and remove have coded assets? (This might make it a component)
• Answer: Are there multiple ways to utilize delete and remove? (This might make it a pattern)
• Answer: Could delete and remove be categorized into "common actions" or 'CRUD' (create, read, update, delete)
• Deliverable: Form an opinion on what category Delete and remove slot into and the future of the asset. Share with Product PAL team

[oliviaflory]

Review of "Remove" and "Delete" assets

Questions to be answered

• Answer: Do delete and remove have coded assets? (This might make it a component)?
  • Yes, we are currently maintaining three examples of a modal for Remove (2) and Delete (1)
  • Unclear if there is any difference between the standard and remove examples
  • Benefits to the user:
    • The words "Remove" and "Delete" are in the primary buttons
    • The primary buttons are swapped for danger buttons
    • The delete modal has the text input in place already and when the correct string is typed in the button changes from disabled to enabled.
    • The storybook is only called "Remove"
• Answer: Are there multiple ways to utilize delete and remove? (This might make it a pattern)
  • Yes,
    • There are 2 levels of "Remove": Medium impact, Low impact
    • There are 3 levels of "Delete": High impact, Medium impact, Low impact
• Answer: Could delete and remove be categorized into "common actions" or 'CRUD' (create, read, update, delete)
  • It seems like yes, though we would likely have very long pages if we were to do that
    • If we had the treeview nav that would allow the actions to be nested under "CRUD" and then have individual pages

Recommendations

• I would have pushed to place these in components because they are coded assest
• However, there are so many different considerations that I think they fit into Patterns
  • "multiple ways of accomplishing something with additional design considerations"
  • We CAN maintain example code for patterns
• I would love to gather Telemetry data on whether the Remove and Delete modals are being used across our Software portfolio to understand if these components are being used / helping our Software devs
  • If they have low usage I wonder if we could consider eliminating the code in the future?

Telemetry updates

very few people if any are probably using that deletion feature.

• Based on the data above, we could potentially consider deprecating the code we provide for this asset and directing teams to the Carbon modal.
• Or we could consolidate the 3 variants of delete/remove because they are all the same (add delete prop to default)
• One additional consideration: import and upload have a larger usage. Do we treat all these patterns/components the same?
  • Delete and remove
  • Import and upload
  • Edit and update

Path 1

• Leave the assets as "patterns" in storybook
• Don't add enhancements to the modals / limit code

Path 2

• Re-classify as:
• Delete and remove pattern
  • Components that support the pattern:
  • Delete modal
  • Remove modal
• Note: Diana T suggested this path for the Export assets as well
• Note: this path may make the IA challenging:
  • Do we surface Delete modal in the components list?
  • Dow we show the Delete modal only in the context of the pattern page and link out to storybook like the Onboarding flows?

Path 3 ??

• We are anticipating incorporating the Sustainability Confirmation dialogues patterns into C4IP
• Combine all Dialogues under Patterns
  • Need tree in left nav
  • Still need to consider if we keep the custom modals as a pattern or component

[oliviaflory]

Review Jul 3

• Deprecate the remove & delete coded "pattern"
• Keep Delete and remove within Patterns and keep the documentation on the website

[elycheea]

Adding another note so @matthewgallo @davidmenendez and I can possibly propose some deprecation strategies for the code as a followup task in a future sprint.