2022-03-09 Meeting notes

15 min

File uploader

@Jon F

• Presenting a concept for drag & drop file upload screen with container for customizable fields, text, or CTA.

Notes:

• Use case: redesign of video block

  • user selects a video to add to a course, select existing video, or upload a new video

  • file uploader UI where content is customizable

• Upload is current proposed name

• Shouldn’t need to be full screen all the time, to make it usable for other use cases

• Error state with alert (e.g., issue uploading the file).

• Probably something we can reuse in other places

• Looking for feedback on:

  • Missing anything?

  • Things that we should change?

  • Do we want this?

• BenW: dropzone probably makes sense (Adam +1)

• Loading state?

  • Momentary spinner instead of a full progress bar

  • Right when you add that it changes to a different page to edit while video is still processing

  • Currently only really solving for this one case

• (BenW) custom elements:

  • error text

  • hint text

  • active content

  • Header

  • confirm text

  • on success action

• Jeff on a11y:

  • “Browse files” same functionality a drag and drop should suffice

  • May need to clarity on outline requirements around dropzones

    • Noticeability for low vision users

    • Touch tablets and need to know what’s touchable

    • “Is the entire dropzone surface area known in advance?”

  • Is there an affirmative action?

• (Adam) How could this look like in other use cases, like inside of a modal, etc.?

  • (Ben) Could be complex and different to reason about as a result.

• (Jeff) Same file upload for mobile (small viewports) vs. desktop?

  • Perhaps “browse files” only on mobile, not drag and drop?

• (Adam) Have we referred to any examples of drop zones from other design systems?

  • https://www.carbondesignsystem.com/components/file-uploader/

  • https://polaris.shopify.com/components/actions/drop-zone

15 min

Text Editor

@Connor Haugh

• Proposing the unification of our existing text editing capacity using a paragon component.

• adr here: https://github.com/openedx/paragon/pull/1131

• Notes

  • review ADR linked above

  • proposed component name: RichTextEditor

  • Wrapper around TinyMCE to allow a certain amount of customization for consumers

  • Can bake in our own standards / a11y needs

  • (Ben) would this replace all uses of TinyMCE in existing places?

    • Worried that it could be tricky to have TinyMCE installed via both Paragon & the application itself.

    • Custom plugins don’t require a specific version of TinyMCE

    • No need for this as a peer dependency. Should have minimal risk of application-installed TinyMCE and Paragon-installed TinyCME.

  • (Jeff) Help with discoverability with keyboard shortcuts to avoid users going to Help Center

  • Perhaps we standardize a TinyMCE config (openedx/tinymce-editor) so that non-React UIs can use standard config from Paragon component as well.

  • Not a ton of a design ask here, but should designers take a look at TinyMCE?

    • Jon is interested!

15 min

Design Handoff process

@Ben Warzeski (Deactivated)

Working on issues with communication of designs to engineering, around design system components and responsive behavior.

Notes

• How do we communicate designs in Figma that are based on Paragon that devs can actually replicate the designers?

• Increased clarity on Figma “inspect”

  • Takes a lot of digging to see how to map things with the specs

• Everything we build is responsive

  • More rules around responsive behavior

• 2 top of mind things

  • Content bodies (e.g. modals) that are responsive, keep figuring out from scratch how these things interact

  • Could we create a base set of variants that define/describe most of the responsive scenarios we use?

• Designers are given designs in lo-fi, but causes devs a lot of back-and-forth to align lo-fi to Paragon components.

• How do we handle responsive columns, etc.? Need more guidelines or just a few predefined presets.

• Looking for a more formalized responsive content rules.

• Controlled vs. non-controlled for responsive behavior

  • Non-controlled might make more sense.

  • “The less the dev has to tell the code how to be responsive, the better we are”

  • How do we take arbitrary Figma widths and make it into an actual responsive app?

•