Page MenuHomePhabricator

[SPIKE] Plan project(s) for DST intern
Closed, ResolvedPublic1 Estimated Story Points


As a Design Systems team engineering intern, I want to have a sense of ownership in a completed piece of work during my time with the team, so that I can grow my skills and experience during my time with WMF.


  • Lauralyn is joining the Design Systems team from Feb 28 - June 30 🎉
  • Goal of internship program: provide valuable experience and connections to people getting started in the tech industry
    • Focus on learning


  • Start by pairing on a small change to go through the process/workflow and codebase, then start work on a new component as the main project
    • Combination of navigating existing code and starting a new component
    • Just the process of submitting a patch is hard

Potential new components:

  • Textarea T284272
    • Fairly straightforward but could be interesting if we incorporate features like clearable, character counter, and icons
    • Many use cases
  • NumberInput
    • Straightforward, already have it in OOUI, won’t be much discussion during design
    • We use a hacked-together one on the demo site, so we could use it immediately
    • Growth team uses one they built internally (copied from TextInput)
    • A composition of components (input + two buttons) which is interesting/relevant experience
    • Unclear how many other use cases we'd have for this component
  • FloatingButton T278134
    • Needed by Growth team, potentially for their intern's project
    • Could be a good experience to collaborate with a team that needs the component, but also adds some pressure

Potential existing component work:

  • Add readonly state to TextInput component T309903 (great first task to pair on)
  • Allow all necessary input types in the TextInput component T295165 (simple component change, requires a change to a TypeScript type as well)
  • Add determinate variant to ProgressBar T309234 (already designed, good intro to Vue component configuration)
  • Elevated Card style T310631 (nice, simple, useful config + style update, but blocked by lack of a specific box-shadow token)

Ruled out:

  • ProgressIndicator (bouncing dots and/or spinner) T266028 (Mostly just copied CSS, maybe not interesting enough)
  • Image (Likely quite complex; requires lots of background knowledge of the library)
  • Dialog: header and footer T324708 (Dialog is an extremely complex component)
  • Skeleton T311874
    • Mostly CSS-only, would require some brainstorming in terms of how best to implement. Not much Vue/JS work to do though.
    • Already designed, just need to update some small things. Need to decide whether we add token or not.
  • Toast notification T303612
    • Maybe more interesting than NumberInput, but could be tricky to implement and would require some MediaWiki-specific thinking
    • Would require more design work and decisions than the others

Decisions/Next steps:

  • 2023-01-25: Discussed at engineering/design sync; @AnneT will think about Toast and connect with @bmartinezcalvo to decide on components.

Event Timeline

Restricted Application triaged this task as High priority. · View Herald TranscriptJan 27 2023, 10:15 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
ldelench_wmf set the point value for this task to 1.Jan 27 2023, 10:15 PM
AnneT updated the task description. (Show Details)

@bmartinezcalvo I've thought more about potential work for Lauralyn and was hoping to get some feedback from you! Here are my thoughts and questions:

  • Textarea: have you thought about what features we might offer for this component? For example, the Vuetify Textarea component is clearable, has an optional character counter, and allows start and end icons. If we want to support features like this, I actually think this would be a very interesting component to work on, and might be my top choice.
  • ToastNotification: I've thought a lot about this one and think that it is probably not the best option. It would take the most design work and decisions out of all the options, and from a component standpoint it would be both tricky to work on and not as good of a learning experience IMO.
  • Skeleton: Similarly, I have ruled out Skeleton. It will take a lot of brainstorming on the implementation end to figure out how to implement this one in a way that makes sense from a developer experience point of view, and it wouldn't provide much experience working with Vue or JavaScript.

Let me know what you think about Textarea; that will help us make the final decision. Really, it would be awesome if we could get design specs ready for Textarea, NumberInput, and FloatingButton—do you think that would be possible in the time we have? I totally understand if it's not, and if that's the case, we will just have to pick one or two :)

@AnneT both TextArea and NumberInput were already defined and implemented in OOUI which means that we would save time in the brainstorming and definition steps. We could start from these components by migrating what we have in OOUI and making some small visual/implementation changes (as we do with the rest of our Codex MVP components). Once these 2 components are defined we could start with the FloatingButton.

So we could start from the following tasks (cc: @ldelench_wmf):

  1. Textarea T284272 //(this could be the Epic and then we can file the MVP task)
  2. NumberInput (we need to file the Epic and MVP task)
  3. FloattingButton /(we need to file the Epic and MVP task and I need more context and real use cases for this)//

Closing since we've decided to start with Textarea, then maybe consider NumberInput or FloatingButton if there's time left