Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

\uD83D\uDDD3 Date

\uD83D\uDC65 Participants

\uD83E\uDD45 Goals

\uD83D\uDDE3 Discussion topics

Time

Item

Presenter

Notes

5 minutes

Ensure branches are up to date before merge?

Brian Smith

  • Merging this led to failing tests that would have been caught if the branch had been rebased first

Notes:

  • Decision: we will keep this disabled to keep velocity up (doesn’t require PR authors to rebase on every commit to master).

  • We will continue to monitor if we need to adjust. But, it seems we’ve only had an issue with this 1-2 times int he last ~year.


5 mins

Frontend-app-learner-dashboard Banner component


Mena Hassan Cindy Nguyen

In frontend-app-learner-dashboard it looks like Alert is being used to do what is essentially the function of Card status. See the ‘Grade required to pass the course: 60%’ banner under Demonstration Course here:

  • Is there something about this usage of Alert that is being used because Card status isn’t satisfying another need here?

    • If so, how can we/how should we expand the functionality of Card status to cover use cases like this


Notes:

  • Using Alert has a11y concern since it includes aria-live="assertive". Only the last message is read aloud (e.g., dashboard page renders multiple Card with Card.Status.

  • There may be other paradigms to mitigate concerns around having screen reader messaging, e.g. rendering Alert at the top of the page that describes any important card-related status messages.

  • We will not modify Card.Status to account for the Alert use case.

  • There may be a use case for duplicate Card.Status. May be

5 min

Frontend-app-learner-dashboard EmailLink component

Cindy Nguyen Mena Hassan

Currently, EmailLink is covering for the case of if there isn’t an email address provided. Should we make MailtoLink in Paragon already handle this use case?

This is how it’s being used within the MFE. Is this a pattern that’s ok? If so, how can we better support that pattern directly within Paragon? If not, what should we do instead?

  • Certificatebanner.jsx line 29:

    const emailLink = address => address && <MailtoLink to={address}>{address}</MailtoLink>;

    Notes:

  • If you’re using MailtoLink, we expect that an email address will exist to send.

  • Possibly make at least ONE of the to, cc, and bcc props to be required. Conditional prop types; may need to define a custom prop type to be able to support.

10 mins

Demonstrate and get accessibility feedback on Marketplace

Kaleb Davenport

The navigation can be found at https://www.edx.org/?mega=true , and we would love to get any and all feedback about how we can make the interaction patterns more comfortable and easy to browse using accessibility tools.

Feedback requested:

  • a11y

  • Components that should be using Paragon but not

  • Questions/feedback about the UX

Notes:

10-20 minutes

Design tokens: what’s left

Adam Stankiewicz

https://openedx.atlassian.net/wiki/spaces/BPL/pages/3898572801/Design+tokens+What+s+left

✅ Action items

  •  

⤴ Decisions

  • No labels