| AnneT | |
| Nov 5 2021, 5:13 PM |
| F35105839: Captura de pantalla 2022-05-06 a las 10.55.01.png | |
| May 6 2022, 8:56 AM |
| F35072300: Captura de pantalla 2022-04-28 a las 18.54.03.png | |
| Apr 28 2022, 6:21 PM |
| F35072226: Captura de pantalla 2022-04-28 a las 18.51.17.png | |
| Apr 28 2022, 4:51 PM |
The version of the ProgressBar in WVUI has only the indeterminate state: as a first step for this component, let's recreate the WVUI version in Codex.
Figma component spec sheet here.
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| design/codex | main | +4 -9 | ProgressBar: Set height on root element | |
| design/codex | main | +120 -1 | ProgressBar: add progress bar component with indeterminate state |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T295174 [EPIC] Add ProgressBar component to Codex | |||
| Open | None | T295177 Add ProgressBar component with only the indeterminate state |
Change 780638 had a related patch set uploaded (by DannyS712; author: DannyS712):
[design/codex@main] ProgressBar: add progress bar component with indeterminate state
Since this is as good a place as any, @ldelench_wmf why were the column from the Codex workboard all hidden, and everything moved into "Open Tasks"? This makes it a lot harder to figure out what is going on and the current state of each ticket
Change 780638 merged by jenkins-bot:
[design/codex@main] ProgressBar: add progress bar component with indeterminate state
Hi @DannyS712, thanks for your question (and all of your contributions to Codex!) and apologies for any confusion this caused.
We found it was inefficient & confusing for Design Systems to track task statuses on multiple boards, so all our active work is now tracked in one place: Design-Systems-Sprint. We have been pulling your assigned tasks for Code Review & Design Review into that board as we go.
Let me know if there's a need we're not meeting with this current approach & I'll add it as a topic for our retrospective.
I understand it might not be the best to track status on multiple boards, but then the single board used should have been the Codex board - this is used by more than just the design systems team. DST may know the current status on its board, but everyone else doesn't, unless they know to go there and check, plus volunteers like myself are probably not as comfortable updating the status on a WMF team board. In short, for anyone looking at just codex, there is no longer any way to tell the status other than if there is a Patch-For-Review tag on the task.
@DannyS712 thanks for your feedback from a volunteer's perspective. Our goal is to provide an intake and tracking process that is maintainable for the team and also intuitive for all contributors to participate in. When we revisited this, we knew that the Codex board was super out of date, which was an indicator to us that maintaining statuses in multiple locations is not maintainable manually. I'll revisit this topic in the team; there are a few paths forward. Ideally I'd like to have a column of "Open" issues that are free for volunteers to grab, and track status within our sprints if feasible. We're actively iterating on this, so thanks for your patience. We welcome any and all volunteer contributions but are not actively seeking more until we sort all of this out, for the reasons you've stated, and also to focus on completing our prototype iterations. I've created a task T306857: Workflow for volunteer/cross-team contributions to track progress on improving this workflow. Thank you!
Makes sense, though it hasn't (to me at least) been a big deal elsewhere. But my biggest point is that if you were going to use one location, it should have been the Codex board rather than a DST board
I'll revisit this topic in the team; there are a few paths forward. Ideally I'd like to have a column of "Open" issues that are free for volunteers to grab, and track status within our sprints if feasible.
This makes sense for status within the DST board but it should also be visible in the codex board - right now I've seen some tasks where the title was updated to reflect the status, which is a bit helpful but columns were more useful
We're actively iterating on this, so thanks for your patience. We welcome any and all volunteer contributions but are not actively seeking more until we sort all of this out, for the reasons you've stated, and also to focus on completing our prototype iterations. I've created a task T306857: Workflow for volunteer/cross-team contributions to track progress on improving this workflow. Thank you!
Happy to help
@DannyS712 I've done the Design Review of the component and I found one correction to do:
I'm going to create the Design Review checklist with this correction.
@DannyS712 I've done the Design Review of the component and I found one correction to do:
- Component height should be 16px. Now it has 18px because it seems that the outline is outside the component instead of inside (we always use outline inside the component to avoid to increase the height of the element)
I'm going to create the Design Review checklist with this correction.
Do you mean the border? The inner bar has a height of 16px, and then the outer wrapper has a 1px border on all sides, for the total 18px height. Are you saying to reduce the inner bar to 14px so that the border brings it to 16?
@DannyS712 I mean a 16px inner bar with a 1px stroke outline inside (instead of outside) so the progress bar heigh is not 18px but 16px. Something similar to TextInput outline.
I don't really understand how to do that. I don't see where in the text input this is done. Looking at the OOUI demo for progress bar, that also has a 16px inner height and then a 1px border for a total of 18px. Removing myself as the assignee, hopefully someone else knows how to address this.
Change 788792 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):
[design/codex@main] ProgressBar: Set height on root element
We discussed this more and clarified that the border and height need to be set on the same element in order for the box-sizing: border-box rule to have the intended effect of taking the border size into account when setting the height.
Change 788792 merged by jenkins-bot:
[design/codex@main] ProgressBar: Set height on root element
@DannyS712 We're keeping it (and other component tasks that have been completed and reviewed by design) open for now and in the "functional testing" column on our sprint board to ensure it's reviewed by Quality and Test Engineering. There's a bit of a backlog in that column right now, but we're working with QTE to develop processes for reviewing Codex components and they'll start working through them soon.
Moving Functional Testing of this component out of this current sprint and into the general Team Functional Testing column, in order to focus on current sprint goals, which primarily include preparing Typeahead Search and several other smaller tasks.
A related reason for doing this is to ensure we have time to triage any tickets or followup work that might come from the functional review of this fix.
Will pick up when prioritized for release.
Progress bar (inline version) is used in typeahead search now, should functional testing be moved into the current sprint? Given that there is very little functionality (just a display, no user input or changes) it should be fairly simple I assume
