[go: up one dir, main page]

Page MenuHomePhabricator

Spiderpig UI: Codex components for Main Page
Open, MediumPublic3 Estimated Story Points

Description

Wireframes

@mwilliams has prepared some wireframes for the Main Page of the Spiderpig web app.

Screenshot 2024-11-08 at 11.32.54 AM.png (2×3 px, 992 KB)

Screenshot 2024-11-08 at 11.33.02 AM.png (2×3 px, 1 MB)

@lwatson will pair with @dancy to build out this UI using Codex components.

Considerations

  • We may not need a Table at all for now, just a series of stacked Card components
  • The tabs portion of this layout can be left out for now; this is a future enhancement
  • The "queued" column inside of individual cards can be omitted if there is not enough space
  • Other elements of the designs above may be adjusted during development; the mockups here are not set in stone
  • Cards should link to /jobs/:job_id (aka the Job Details page); the "needs interaction" message should also link to the relevant job detail page

Follow-up tasks

  • Create links to user accounts. When centralized authorization is implemented, we can link to that Wikimedia Developer Single Sign On account (https://idm.wikimedia.org/).
  • Create links to Gerrit change numbers. Note that there can be more than one change number. This link depends on additional information about the change number that is not provided at the moment.
  • In Backport.vue, add a start icon to the MultiselectLookup's input. T380209
  • Add pagination or "show more" button.

Event Timeline

egardner set the point value for this task to 3.
CCiufo-WMF triaged this task as Medium priority.Tue, Nov 12, 4:04 PM
CCiufo-WMF moved this task from Needs Refinement to Up Next on the Design-System-Team board.

The new JobCard component uses a CSS grid layout to display the job information. It may be worth exploring using CdxCard and overriding its flex styles. We'd benefit from getting Codex styles like card links.

The new JobCard component uses a CSS grid layout to display the job information. It may be worth exploring using CdxCard and overriding its flex styles. We'd benefit from getting Codex styles like card links.

@lwatson I would recommend relying on the existing Codex components wherever possible, because that code has already been extensively reviewed/tested/etc. You may want to consider making JobCard basically a wrapper around <CdxCard> that places the content into the #description slot. That area could be further sub-divided using CSS Grid or Flexbox as needed, but you'd get some styles "out of the box" this way.

@lwatson I would recommend relying on the existing Codex components wherever possible, because that code has already been extensively reviewed/tested/etc. You may want to consider making JobCard basically a wrapper around <CdxCard> that places the content into the #description slot. That area could be further sub-divided using CSS Grid or Flexbox as needed, but you'd get some styles "out of the box" this way.

Thanks! The JobCard now uses CdxCard and those changes were pushed to GitLab.

The JobCard should display the job status on the OverviewPage. This feature is not represented in wireframes so this will need some design feedback @DTorsani-WMF

The job status is an arbitrary string that describes what's happening with the backport. When you run a backport, the job status text should be displayed on the overview page. The text changes while the backport is in progress (sometimes containing URL addresses). The job status should be prominent on the OverviewPage and is a top priority when running the backport.

Example 1 is a JobCard using the supporting-text slot to display the job status.

JobCard - job status.png (1×1 px, 255 KB)

Example 2 is a JobCard using a CdxAccoridion to display the job status within supporting-text slot. This CdxAccoridion is defaulted to open/expanded therefore no action is needed to view the job status.

JobCard - job status in CdxAccordion.png (1×1 px, 193 KB)

JobCard - closed CdxAccordion.png (674×1 px, 92 KB)

@lwatson Thanks for providing these two examples and explaining the context. If the job status is quite important, I hesitate to have it be in an Accordion, even if it is defaulted to be open. Maybe a stronger argument for option 1 (using the supporting-text to show the job status is that it looks like it nearly takes up the same about of space, maybe a little more, than the closed Accordion, so not very different space wise, which was what the Accordion would normally be trying to help with. So again, I personally like option 1 using the supporting-text for job status better.

Thanks, I agree that option 1 would be better. If the job status is the only other data to display, another option is to use CdxMessage to display it.

@DTorsani-WMF One thing I've been musing together with @lwatson about is the redundancy (and prominence) of the labels per Card.
In my opinion the Card has here a tougher stand vs a tabular presentation.
I'd in any case consider to remove the labels from all but the first and last card per view to focus more on content and reduce redundancy/noise. What's your take?

@Volker_E I played around with this idea of cards mimicking a tabular layout:

Screenshot 2024-11-21 at 5.53.48 PM.png (854×1 px, 149 KB)

And some inspiration from dribble:

Screenshot 2024-11-21 at 6.02.34 PM.png (502×1 px, 125 KB)

Screenshot 2024-11-21 at 6.02.50 PM.png (667×1 px, 243 KB)

I'm also open to exploring using a CdxTable when we can support clickable and highlighted table rows.

@lwatson Very nice IMHO and a real interface improvment, thanks! :)
Curious what others think…

I agree that this is a big improvement to reduce the space used, and the cognitive load with the redundancy of the extra headers. Thanks for putting this together @lwatson!