Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Time

Item

Presenter

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?

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?

✅ Action items

  •  

⤴ Decisions

...