translations UI design revisions

[gumaerc]

What are the relevant tickets?

Closes https://github.com/mitodl/hq/issues/11196

Description (What does it do?)

This PR implements some style changes to both mobile and desktop on the B2B contract page, focusing mostly on the header and the new translation language selection dropdown.

Screenshots (if appropriate):

How can this be tested?

• Follow the instructions in dashboard translations UI #3269 to get set up with test data sufficient to test a B2B program in the dashboard
• Compare the design on both desktop and mobile to the Figma designs linked in the above issue and make sure that it looks correct

[github-actions]

OpenAPI Changes

No changes detected

View full changelog

Unexpected changes? Ensure your branch is up-to-date with main (consider rebasing).

[Copilot]

Pull request overview

This PR updates the B2B contract dashboard header styling (desktop + mobile) and revises the visual design of the “Learning Language” dropdown to match updated translation UI designs.

Changes:

• Added responsive styling to the contract header layout, logo container, and header/subheader typography.
• Adjusted program header mobile styling (padding/background/border) and updated the language select field layout/styling.
• Updated the language select’s renderValue to render the selected language label with subtitle typography.

[gumaerc]

@mbilalmughal I saw your suggestion to use a modal to select dropdown elements on mobile instead of the usual dropdown:

My question is that this looks like a one-off wireframe and not an actual finalized component. Do we want to do this for dropdowns across the site? Should we make it an official part of our implementation of SimpleSelectField in smoot-design? It would be hacky to implement it only in this one place. We should implement it at the component level IMO.

[daniellefrappier18]

@gumaerc @mbilalmughal Here is my two cents since Carey suggested I weigh in.

On mobile, a modal is almost always better than a dropdown for language selection. Dropdowns get cramped fast, and language lists are usually long. One thing I would like to call out on the current mockup is could we sort the list alphabetically by how each language spells its own name, not by the English version. Right now it goes English, Spanish, French… but a Spanish speaker is scanning for "Español," not "Spanish." I know it offers both currently, so if you disagree I'm not married to this suggestion. Also if over time we end up having more than 12 languages (this may already be the case) I think adding a search box at the top would be a valuable UX add.

[mbilalmughal]

@mbilalmughal I saw your suggestion to use a modal to select dropdown elements on mobile instead of the usual dropdown:

My question is that this looks like a one-off wireframe and not an actual finalized component. Do we want to do this for dropdowns across the site? Should we make it an official part of our implementation of `SimpleSelectField` in `smoot-design`? It would be hacky to implement it only in this one place. We should implement it at the component level IMO.

---

On principle, I generally agree that UX should be applied globally. As you can see in the end of user story, I initially proposed a larger dropdown menu for easier selection, but later the UX team decided it would be better to use a modal, as there is a chance users might accidentally click the cards behind it.
Note: But don’t take the user story as a reference, as it was only based on the team’s understanding of what needed to be done. The handoff document is more suitable here.

That being said, I’m not in favor of making that change right now. I would like to review all scenarios where the dropdown is used (e.g., search pages, sorting dropdowns, etc.). After that, I’ll be in a better position to suggest whether this change can be applied globally and whether it would improve the mobile UX with confidence. cc: @steven-hatch

For now, the modal should only be applied to language selection. That would be a better and safer approach.

Also, I noticed a couple of small UI spacing issues that I would like you to take a look at.

[gumaerc]

@mbilalmughal re: the grey background on the "Learning Language" section and the mobile program section headers: you used colors that are not in the theme. The Learning Language section background is defined as "Light Gray 0" in Figma, which is not part of Smoot Design yet. I could add that, but ideally that work has been done before an issue like this is passed on for implementation. The program header is a separate issue, as the background color is defined as rgba(243, 244, 248, 0.60);, a color that is not even tied to a variable in Figma.

[mbilalmughal]

@gumaerc Yes, I agree this is a new color. We introduced it while creating the Podcast and Video Collection page, and I thought it could be reused here. The reason was that the lightest grey color is already used in the background above, and it feels like it’s blending in rather than giving a distinct separation.

I’m fine either way, if we can’t add this for now, that’s totally fine. The color you used works well for now. I think your color with the correct shadow will work just as well, so please ignore that change.Thanks.

[gumaerc]

@mbilalmughal Also, in regards to the font sizes, I am specifying the font sizes specified in Figma for mobile here:

const HeaderText = styled(Typography)(({ theme }) => ({
  ...theme.typography.h3,
  color: theme.custom.colors.darkGray2,
  [theme.breakpoints.down("sm")]: {
    ...theme.typography.h5,
  },
})) as typeof Typography

const SubHeaderText = styled(Typography)(({ theme }) => ({
  ...theme.typography.subtitle1,
  color: theme.custom.colors.silverGrayDark,
  [theme.breakpoints.down("sm")]: {
    ...theme.typography.subtitle2,
  },
})) as typeof Typography

In the design, we have heading 5 for the title and subtitle 2 for the subtitle. I'll do some further verification to make absolutely certain the styles are applying correctly, but I think they are so we might want to check if we have made some design changes in Figma that have not been applied to theme.

[gumaerc]

@gumaerc Yes, I agree this is a new color. We introduced it while creating the Podcast and Video Collection page, and I thought it could be reused here. The reason was that the lightest grey color is already used in the background above, and it feels like it’s blending in rather than giving a distinct separation.

I’m fine either way, if we can’t add this for now, that’s totally fine. The color you used works well for now. I think your color with the correct shadow will work just as well, so please ignore that change.Thanks.

There are places throughout Learn where we see stuff like backgroundColor: "rgba(243, 244, 248, 0.60);", // TODO: use theme color. We need to do a better job of actually implementing things like this in there theme and using them, rather than just continually saying we'll do it later and subsequently never doing that.

[mbilalmughal]

@mbilalmughal Also, in regards to the font sizes, I am specifying the font sizes specified in Figma for mobile here:

const HeaderText = styled(Typography)(({ theme }) => ({
  ...theme.typography.h3,
  color: theme.custom.colors.darkGray2,
  [theme.breakpoints.down("sm")]: {
    ...theme.typography.h5,
  },
})) as typeof Typography

const SubHeaderText = styled(Typography)(({ theme }) => ({
  ...theme.typography.subtitle1,
  color: theme.custom.colors.silverGrayDark,
  [theme.breakpoints.down("sm")]: {
    ...theme.typography.subtitle2,
  },
})) as typeof Typography

In the design, we have heading 5 for the title and subtitle 2 for the subtitle. I'll do some further verification to make absolutely certain the styles are applying correctly, but I think they are so we might want to check if we have made some design changes in Figma that have not been applied to theme.

---

The font feels too big and out of proportion in that card header. I don’t think it will look good even if it follows the rule.
It might work generally for an open container item, but for cards or any element with limited space, it’s better to adjust the font size to match the overall proportions and ensure better balance.

I’m not against the rule, but sometimes certain font sizes work better on desktop, while on mobile smaller font sizes can also work well.

[mbilalmughal]

@gumaerc Yes, I agree this is a new color. We introduced it while creating the Podcast and Video Collection page, and I thought it could be reused here. The reason was that the lightest grey color is already used in the background above, and it feels like it’s blending in rather than giving a distinct separation.
I’m fine either way, if we can’t add this for now, that’s totally fine. The color you used works well for now. I think your color with the correct shadow will work just as well, so please ignore that change.Thanks.

There are places throughout Learn where we see stuff like backgroundColor: "rgba(243, 244, 248, 0.60);", // TODO: use theme color. We need to do a better job of actually implementing things like this in there theme and using them, rather than just continually saying we'll do it later and subsequently never doing that.

---

I’m really sorry to see that. I’m totally against using fixed color values instead of color variables.
I did discuss this with Chris, and this usually happens when we need a lighter variation of a color. In those cases, we tend to use a base variable color and apply opacity. While this still references the variable in Figma, in Dev Mode it shows an RGBA value instead, which isn’t ideal for development.
Chris advised against this approach, and I agreed. We decided that going forward, we will not use opacity for colors. That’s likely why you’re seeing RGBA values.

[gumaerc]

@mbilalmughal Also, in regards to the font sizes, I am specifying the font sizes specified in Figma for mobile here:

const HeaderText = styled(Typography)(({ theme }) => ({
  ...theme.typography.h3,
  color: theme.custom.colors.darkGray2,
  [theme.breakpoints.down("sm")]: {
    ...theme.typography.h5,
  },
})) as typeof Typography

const SubHeaderText = styled(Typography)(({ theme }) => ({
  ...theme.typography.subtitle1,
  color: theme.custom.colors.silverGrayDark,
  [theme.breakpoints.down("sm")]: {
    ...theme.typography.subtitle2,
  },
})) as typeof Typography

In the design, we have heading 5 for the title and subtitle 2 for the subtitle. I'll do some further verification to make absolutely certain the styles are applying correctly, but I think they are so we might want to check if we have made some design changes in Figma that have not been applied to theme.

The font feels too big and out of proportion in that card header. I don’t think it will look good even if it follows the rule. It might work generally for an open container item, but for cards or any element with limited space, it’s better to adjust the font size to match the overall proportions and ensure better balance.

I’m not against the rule, but sometimes certain font sizes work better on desktop, while on mobile smaller font sizes can also work well.

@mbilalmughal I'm not arguing that the font size looks more correct as implemented. What I'm saying is that I have set the font size to what is specified in Figma, so if it looks incorrect then likely the theme is incorrect.

[mbilalmughal]

@gumaerc Am saying in my attach image above that

• The company name should be H5.
• The subtext should be 14px bold, which is part of our subtitle typography.
• The card header text should be 16px, using the subtitle typography.
  • The text below should be 14px, from the body text typography category.

[gumaerc]

@gumaerc Am saying in my attach image above that

• The company name should be H5.

• The subtext should be 14px bold, which is part of our subtitle typography.

• The card header text should be 16px, using the subtitle typography.

  • The text below should be 14px, from the body text typography category.

Yep, and what I'm saying is that on mobile, the header is set to h5 from our theme, and the subtitle is set to subtitle is set to subtitle2 from our theme. So, if you are seeing any discrepancy here it is not because I didn't set the right font on the element, it's because the font is wrong in the theme.

[gumaerc]

@mbilalmughal Also be advised that the color values I'm seeing (and have seen thus far) for box shadows has been using these argb values with transparency such as rgba(120, 147, 172, 0.40) in the case of the new contract header shadow.

[mbilalmughal]

@gumaerc Am saying in my attach image above that

• The company name should be H5.

• The subtext should be 14px bold, which is part of our subtitle typography.

• The card header text should be 16px, using the subtitle typography.

  • The text below should be 14px, from the body text typography category.

Yep, and what I'm saying is that on mobile, the header is set to h5 from our theme, and the subtitle is set to subtitle is set to subtitle2 from our theme. So, if you are seeing any discrepancy here it is not because I didn't set the right font on the element, it's because the font is wrong in the theme.

So, you are saying the H5 on the theme is not 18px Bold?

[gumaerc]

@gumaerc Am saying in my attach image above that

• The company name should be H5.

• The subtext should be 14px bold, which is part of our subtitle typography.

• The card header text should be 16px, using the subtitle typography.

  • The text below should be 14px, from the body text typography category.

Yep, and what I'm saying is that on mobile, the header is set to h5 from our theme, and the subtitle is set to subtitle is set to subtitle2 from our theme. So, if you are seeing any discrepancy here it is not because I didn't set the right font on the element, it's because the font is wrong in the theme.

So, you are saying the H5 on the theme is not 18px Bold?

It is, and that is what you're seeing in the screenshot, so maybe it's a visual misinterpretation? It's 1.125rem, which at a 16px base font would translate to 18px.

[mbilalmughal]

@mbilalmughal Also be advised that the color values I'm seeing (and have seen thus far) for box shadows has been using these argb values with transparency such as rgba(120, 147, 172, 0.40) in the case of the new contract header shadow.

Yes, Its the chatbubble shadow variation

For the shadow, can we make an exception? Shadows usually use extremely low color values that aren’t used anywhere else. For example, shadows typically require a slight grey or other subtle color variation. It would be difficult to add all those color values just for shadows, and I think it might be overkill.

However, I’m open to whatever you suggest. In that case, we may need to add a few very light colors so we can properly update the shadows.

[gumaerc]

@mbilalmughal I pushed some commits and updated the style as best I could given your feedback and the current limitations surrounding what is actually implemented in the theme:

• There were issues with the spacing in general that I corrected based on what you noted.
• The contract header mobile fonts are verified set to h5 for the title and subtitle2 for the subtitle.
• Since the last time we worked on this, there have been changes to the mobile design for program headers that were never implemented. I had the font size wrong within these headers and it has been updated to use subtitle1 and body2 for the program description.
• Light gray background colors were left as a combination of lightGray1 / lightGray2 as those are what's available in the theme
• Box shadows throughout the site still use manual argb values copied and pasted from Figma. Based on what you mentioned above, we should find a better way to link argb values from Figma into actual variables that are defined as argb values within the theme

[mbilalmughal]

@gumaerc Update looks amazing now, Thanks ALOT ❤️

And I won’t promise for next week, but within a couple of weeks I will address all the concerns you mentioned and fix the design system inconsistencies for sure. I will ask our product team to give me some time to resolve these issues properly.

And if some new elements are introduced, which I’m sure there will be, since our Podcast and Video Playlist pages are slightly different from what we currently have, what I will do is create a change set document. I will also introduce a practice of creating a handoff document every time a new task goes into development, not for small changes, of course.

Thanks again, Carey, much appreciated.

[gumaerc]

NOTE: As discussed outside of Github, this PR will not introduce any kind of modal / dialog or native select functionality for the language selection. It would be hacky to do so only for the language picker and we need to have a larger discussion outside the context of this PR about potentially using NativeSelect only on mobile for our select based controls.

[gumaerc]

@mbilalmughal That sounds good. I will start with putting up a PR in smoot-design to add the lightGray0 color. If you could come up with a list of everywhere where that's supposed to be used, after that is merged I could do a follow-up PR to implement it wherever it's supposed to be.

[mbilalmughal]

@mbilalmughal That sounds good. I will start with putting up a PR in smoot-design to add the lightGray0 color. If you could come up with a list of everywhere where that's supposed to be used, after that is merged I could do a follow-up PR to implement it wherever it's supposed to be.

That would be great. For now, I’m only using that color here. Previously, it was introduced in the podcast and video playlist UI, so I don’t think it will affect MIT Learn as such.

[gumaerc]

@mbilalmughal That sounds good. I will start with putting up a PR in smoot-design to add the lightGray0 color. If you could come up with a list of everywhere where that's supposed to be used, after that is merged I could do a follow-up PR to implement it wherever it's supposed to be.

That would be great. For now, I’m only using that color here. Previously, it was introduced in the podcast and video playlist UI, so I don’t think it will affect MIT Learn as such.

@mbilalmughal For what it's worth, I searched the entire repo for #F7F7F7 (the --Light-Gray-0 color from Figma) and came up with no results. I checked out the Podcast page and it's just using lightGray1 and lightGray2. I imagine other developers are possibly not making as much noise about missing colors like this and are just using whatever's available.

[mbilalmughal]

@gumaerc Yes, good catch. When I started building the new podcast page, I introduced this in a couple of places, but those pages were never approved or moved to development. Although, I think it’s a good gray shade for lighter background use. The one we currently have, which is the lightest gray shade, is kind of dark and doesn’t actually give a true gray feel; rather, it has some blue in it. That’s when I thought I should add a color that can also work well with all the gray shades we already have in the system. F7F7F7 was working well on white, as well as above our lightest gray shade. I would recommend adding that gray shade. As I said, I will work on all the change sets we’ve made, and then we can discuss which changes we should push to the smoot design 👍