Page MenuHomePhabricator

Provide designers with a method to test Codex components in a 14px font size context
Open, Needs TriagePublic

Description

Problem

On-wiki, the Vector skin uses a 14px base font size, while MinervaNeue uses 16px. These do not necessarily correspond to desktop and mobile, respectively, because you can use either skin on any viewport size.

Because of this difference in base font size, in Figma, Codex components are documented at both font sizes:

image.png (1×2 px, 181 KB)

However, this distinction is MediaWiki-specific. Following our guiding principle to support the wider Wikimedia ecosystem by maintaining platform-agnosticism, in the code implementation of Codex components, a base font size of 16px is used. On the Codex docs site, components are only shown in a 16px context. We have a custom build process to produce multiple CSS files, ones that work in a 16px context and ones that work in a 14px context. These CSS files are then made available in MediaWiki and used by the skins.

Because the docs site, which contains demos of components meant to demonstrate all of their variants, does not show components at 14px, designers often cannot see a working example of a component as it will appear in Vector. This leads to confusion, especially since the components at 14px are not directly scaled from 16px in an intuitive way.

Potential solutions

Show components in a 14px context on the Codex docs site

This solution would involve adding a way for users to view the component demos on the Codex docs site in a 14px context. This might be accomplished via a theme or font size switcher.

Pros:

  • All of the carefully curated component demos on the docs site would be available at 14px
  • All implementation documentation lives in one place
  • The text size of components Demos and the components Guidelines match

Cons:

  • Design and implementation of this feature would be complex and time-consuming
  • We'd be introducing something MediaWiki-specific into the docs site and codebase

Considerations:

  • If we provide a switcher, we should carefully consider how to present it. We should remain as MediaWiki-agnostic as possible (not showing "Vector" or "MinervaNeue"), avoid correlating 14px with desktop and 16px with mobile, and make the options clearly understandable by our users
  • Would just the component demos be shown at the chosen font size, or the whole site?

Build a demo page on-wiki

For this solution, we would replicate the component demos on the docs site on-wiki, so they could be viewed in any skin.

Pros:

  • This keeps the MediaWiki-specific stuff in MediaWiki, and is true to the actual difference here (it's really about skin vs. skin, not font size vs. font size or desktop vs. mobile)
  • We've already built a version of this in VueTest

Cons:

  • The way VueTest was updated was very non-ideal, to the point that we recently decided to kill it. We would need to figure out a more sustainable way to keep VueTest in sync with Codex
  • This would be a separate location from the docs site, distributing our documentation more

Considerations:

  • We'd need to install VueTest on some test or beta wiki to make it available to the design team

Here's a screenshot from the page generated by VueTest, showing a variety of Lookup demos:

image.png (1×1 px, 213 KB)


Acceptance criteria

  • Discuss the options asynchronously
  • Propose a solution to the design team and get feedback
  • Open tasks to implement that solution

Event Timeline

Feedback that would be helpful:

  • What do you think of the proposed solutions?
  • Are there other potential solutions?
  • Does anything need to change on the Figma end, in addition to any changes we might make on the implementation end?

My personal preference is for option 1. I think we could avoid the Vector/Minerva and desktop/mobile names by using the term "legacy mode". This is a concept that is already being proposed in this change, and it would go along with dark mode. We could have a control for each demo that let you choose the mode (legacy or dark, or maybe even dark+legacy?) along with the direction. This way it also wouldn't really be MW-specific, or at least wouldn't introduce any new MW-specific things: we'd be exposing the same modes that already exist in the tokens package. We would need to make some other technical changes (mainly using CSS variables for the affected tokens), but for the most part we're already planning to make those changes (or at least similar ones) for other reasons.

I don't like option 2 as much, because it would be harder to keep the demos in sync. The best way I can think of would be for Codex to build either the sandbox or a combination of all the demos (gathered in an automated way so that we can't forget to manually update something) as a JS file rather than an HTML file, make that part of the Codex release tarball that is published to NPM, and have VueTest just wrap that in a simple special page (or maybe even put a Special:CodexTest page in MW core?). That way things would be updated automatically, you'd always see the demos that correspond to the release of Codex that is being used in MW, and if you needed to see the demos for a more recent unreleased version you would use T314507 (or its current workaround). The downside in my mind would be that this file would be part of the release that is published to NPM, even though it's really only intended for testing purposes, but I acknowledge that's more of a "philosophically not ideal" thing than an actual practical problem.

I think option 2 is the "correct" way to do this. The 14px context is specific to Vector, so I think the demos of our components in a 14px context should just be displayed in Vector itself. I think this is important for 3 reasons:

  1. Philosophical reason: it keeps Codex, including the docs site, skin-agnostic. Having a font-size switcher on the docs site seems cluttered and confusing to me.
  2. Technical reason: we are currently discussing making major changes to the way we support using Codex in a 14px context, including shipping a single font-size mode and enabling users to override font-size tokens in their projects (e.g. in Vector). I don't think we should build a font-size switching system on the docs site that might be subject to change, or might not exactly replicate what happens in Vector, which could increase the risk of regressions or unexpected results onwiki.

Keeping the demos in sync is a real challenge, and it didn't work well with VueTest. That said, I think our time would be better-spent creating a system for keeping at least a set of demos in sync and displaying them on some test wiki, rather than making what I would consider hacky changes to our docs site.

  1. Technical reason: we are currently discussing making major changes to the way we support using Codex in a 14px context, including shipping a single font-size mode and enabling users to override font-size tokens in their projects (e.g. in Vector). I don't think we should build a font-size switching system on the docs site that might be subject to change, or might not exactly replicate what happens in Vector, which could increase the risk of regressions or unexpected results onwiki.

I think this depends on which technical approach we end up going with: if we build support for a 14px context into Codex as a legacy mode (similar to how dark mode would work), then I think it makes sense to have a way to exercise that built-in support in Codex itself. But if we keep it out of Codex and it lives entirely in Vector, then I agree that it doesn't make sense to have demo tools in Codex for something that doesn't live in Codex.

Keeping the demos in sync is a real challenge, and it didn't work well with VueTest. That said, I think our time would be better-spent creating a system for keeping at least a set of demos in sync and displaying them on some test wiki, rather than making what I would consider hacky changes to our docs site.

I think this also depends on the technical approach for supporting 14px: if it is a mode just like dark mode, then exposing it on our docs site wouldn't be hacky if we exposed it in the same way as dark mode, and we'd have to build a light/dark switch anyway. But if it's a Vector-specific thing, then it would make more sense to demonstrate it in MediaWiki.