Review and consolidate components

[bradenmacdonald]

This repo has three sets of reusable "generic" components:

• src/generic
• src/editors/sharedComponents
• src/files-and-videos/generic

These components have a bunch of issues:

1. Redundancy with each other. Some examples are listed here but there are more. These should either be consolidated or one of them renamed to clarify the difference.

   • AlertError and ErrorAlert seem very similar.
   • PromptIfDirty and usePromptIfDirty are identical except one is a hook. We don't need both, or the component could be simplified to wrap the hook.
   • CodeEditor and CodeEditor
   • FileInput and FileInput
   • more; this isn't a complete list

2. Some things are "temporary" workarounds for Paragon bugs that should no longer be needed

   • SelectableBox should be replaced with the upstream Paragon version. (see old explanation why this happened)
   • src/generic/NewsstandIcon.tsx

3. It's unclear why some of them exist or how they should be used, like this repo's own version of Button. A style guide page or storybook type resource should explain all the reusable studio widgets, and the code should have JSDoc comments with a clear justification for each one.

4. Each part of this MFE - course outline, unit page, advanced settings, pages & resources, libraries, taxonomy editor, editor modals - has a totally different look and feel. We should use a library of standard Studio UX patterns & components for a more consistent look & feel.

   • Here's how a unit looks on the course outline:
     
   • Here's how the same unit looks in the search modal:
     
   • Here's how a unit looks in the library:
     

5. Some things, if they're that useful, should perhaps be moved to upstream Paragon or an Open edX component library ??

---

This is a large umbrella, so create sub-issues as needed.

[bradenmacdonald]

@sdaitzman @edschema @marcotuts I know you have a ton on your plate these days, but could I get at least some high level thoughts from you on points 3-5 (moving toward consistent, reusable, well-documented components and UX patterns in Studio) whenever you have some time, please ?

[edschema]

Hi @bradenmacdonald, this is very related to conversations we've been having on our team. It's definitely a cross functional issue, so I'm grateful that you've brought this up. I'll add some notes on how we have been thinking about related issues from a design/product lens, and I'm sure @marcotuts and @sdaitzman will have additional thoughts to add.

We've been working on two different Figma files that should help with 3 and 4 above. I know Figma files won't solve everything, but I think these changes reflect a meaningful shift towards Atomic Design that, if effective, should help directly clarify usage patterns of Paragon components as well as communicating larger template/ page level patterns that will help with UX/UI consistency across the Studio tools.

@sdaitzman has written this proposal that I think clearly documents some of the issues and steps forward https://openedx.atlassian.net/wiki/x/AgCyKwE.

Maintained Open edX Paragon Figma File
We've not had an Open edX Paragon Figma file that has been properly maintained, and it's caused some issues. The current Paragon Figma file still has 0 border radius for buttons and different color mappings (ex: primary-500 in Paragon is #0A3055, but on the Figma file is #00262B).

We've started an Open edX Paragon Figma file to align what currently exists in Paragon with the Figma components. There are issues still with ownership/ licensing, etc. But we're at least starting to do some of the work.

Standardized UX patterns for Improved Consistency
We've been making improvements to the Library and Course Authoring Figma file. The goals are to 1. improve consistency across the platform and 2. make design quicker/leaner. We think this will come through better components and documentation of template/page level patterns. Examples of benefits here include consistent sidebar patterns (headers, tab format, etc), consistent page level IA/ layouts (ie: header, page level actions area, metadata or tab structure). This work should help with the general fit/feel and consistency. We'll hopefully be ready to share more of the groundwork here in the coming weeks.

Beyond Figma files, there are a couple other ways I can think of to incrementally address design-caused maintenance issues:

• Refresh the current Paragon Contribution Process documentation. Right now the contribution process relies on that same out-of-date Figma Paragon file
• Continue to push the Paragon WG into a more hybrid front-end and design focused meeting

I'll keep thinking on this and whether there are other actionable steps we can take from the design/ product side..!

[bradenmacdonald]

@edschema Thanks! [How] do you see these Figma files interacting with / coexisting with / staying in sync with an interactive component viewer like Storybook or https://paragon-openedx.netlify.app ? Or not?