Thanks for this Jonathan! My main priority is to make sure the URL feels trustworthy...simple, clear, and familiar. Sticking to something very close to what we currently use for consistency and familiarity also seems like a good path forward.

I think you are heading in the right direction Eric! Really like how Bulma is approaching this, makes a lot of sense quickly. I think deciding what the core components are to create a responsive layout for most of our future use cases will be interesting, for example, we probably don't need to support nav or hero for v1?

Really nice work @Mariam, I found your tutorial / documentation on Medium to be really thorough. I especially liked how you described challenges, like these ones:

Thank you for your submission and tutorial @Enakeno! After reviewing your Penpot file some of the spacing and the icons are different from the Figma component.

Looks reasonable to me! I think the numbers can be a regular weight (they look bold?) and I was thinking we don't have to show the indicators if there is only one image but don't feel super strongly about it.

I'd be happy to support this from the design side. Maybe we start with getting the prototype up and running with the Codex components and then I could provide a few high-level suggestions?

I'm worried about using the MoveLast icon like this and it being universally understood quickly, especially on it's own and used from the very beginning I find it a bit confusing.

@simon04 @Jdlrobson I think it's a super reasonable idea to use MMV on Minerva and converge on one media viewer experience!

Myself, @cmadeo, and @DTorsani-WMF did an an initial round of reviews to begin seeing if Penpot could meet the criteria listed in this task's summary. Here are some of our rough notes and next steps.

@Sneha Has volunteered to work on this component and has begun some preliminary research. @DTorsani-WMF will be her DST design buddy and I'll be bringing this topic back to the DST team to appropriately scope and find an engineering buddy!

Just reviewed with Bárbara and I think it looks great! A couple of thoughts I shared that shouldn't interrupt this from moving forward...

I also did a bit of competitive analysis as a part of our design decision brief.

Looks good to me!

Yup, I think you are right, stands out too much. Lets leave the blue focus border, remove the other border, thanks!

Looks good to me!

Nice! The bg box behind the icons is a bit big - mapping it to the icon only button's in Codex would have it at 32px x 32px. The arrow buttons are bit unique, but making the box a bit smaller makes sense as well, 44px x 44px.

Hmm, yeah I might be missing something or I explained myself poorly, let me try again!

@TheDJ Thanks for your patience awaiting my feedback on this.

Yesterday @VirginiaPoundstone, @cjming, and I discussed this and decided that we should proceed with option 3. But that a text input for "Custom" couldn't be the longterm solution since typing in a custom schema would go wrong more times than right and that it probably should be a select.

Curious if this would/should/could support a lookup as well? That is a use case (https://phabricator.wikimedia.org/T366325) that may needed for metrics platform

@VirginiaPoundstone, @cjming, and I met yesterday to update the design of this and this is about where we landed. This mockup also has adjusted the order of the form to accomdate for location and sample rate being next to each other.

@TheDJ Just to make sure I'm catching everything that is changing before giving feedback, I'm seeing...

• Larger icon sizes
• New background color circle behind the icons
• New hover and focused states (white border around the background circle)
• New pressed states

Agree with @bmartinezcalvo - default pagination at the bottom and having both is a choice for folks that know that their table is going to be really long.

Do we still keep the unit and sampling rate fields above in the "Type" sectioon? Is that the overall sampling rate or is that not needed if there is a sampling rate attached to each environment?

Thanks for the update @cjming! I don't totally follow all of this but is there a certain set of stream names and this should be a select? Or just an open text input again?

The seemingly simplest possible solution for this to meet the needs of the MVP would be to use the same layout as the form but rather than editable inputs, it would be plain text.

We discussed a few options and directions in these slides.

Seems reasonable to me, especially to start with. Here it is with updated copy and removed the optional bit.

Posted some ideas about the phab ticket field question at https://phabricator.wikimedia.org/T366394.

A couple ideas for this...

Thanks! Updated those and Option 2 is probably requires too much text. I agree it is confusing without it but its so much text in a form like this that people will most likely skip over it and end up getting stuck.

Thanks for the additional details! The design and layout of what you are proposing seems good to me as it maps to the spacing and positioning of the current lock icon and seems flexible to swap out with the icon needed.

Here are a couple quick mockups to see if I'm understanding this correctly from the design side:

@KColeman-WMF When we chatted I believe I pitched this with rows being customizable since your GUC use case could have some very long lists so starting with 5 isn't particularly useful. Anne has given some good reasoning here why we wouldn't go in that direction but could you give a bit of insight into your scenario and how many rows you were hoping this could handle?

@TheDJ Thanks for the screenshot, seems like a good use of of the Codex Progress Bar to me - lets merge it!

I chatted with @Cparle a bit to get more context on this and it does seem like we might have some other more effective UI solutions - I'll give this another shot and update next week!

Thanks for drafting that up @simon04, that seems pretty reasonable!

Thanks for sharing @Soda! I'm seeing the same icon (Lock with nothing in it) for both semi-protected and fully protected. Is that to be expected as any update to the icon to visually communicate its protection level would be at a higher/ more specific presentation level?

The design teams initial review can be found here

This seems related to https://phabricator.wikimedia.org/T363431. That is a ticket for a component needed in Metrics Platform that is very similar to MenuTagMultiselectWidget in OOUI.

List seems accurate to me, thanks for compiling everything into one spot @TheDJ !

I had considered this to be an expansion of the Menu component, which is already not a standalone component. So just like how Select and Lookup use it, a button could use this component internally.

Just noticed that this ended up on production on Commons even with the bug that @Esanders found and what @Edtadros brought up. You can see it on any file, example here.

Attaching some explorations into the "Above Fold" and "Metadata" elements.

• There are various interaction patterns that don't feel as straight forward as they could be. We wanted the content to be as simple and straightforward as possible.
• Switching this to Codex, we adjusted some spacing and icons to better map to our current design guidelines.

Here is a mockup before you scroll...

Here are the missing SVG files for @Gopavasanth

@simon04 and I worked through some possible UI changes for the download and share icons. Our main goal was to simplify the UI as much as possible by using the entire space available, combining different states and views when possible to reduce clicks and "hidden" features. There are also some changes due to certain components being different or not existing in Codex (The dropdown/select) button.

After poking at this for bit, I think there is some confusing overlap between the Menu, Popover, and Dialog components. For this specific task I'd like to propose focusing on the most simple version of a tooltip with a draft definition of: "Tooltips are brief labels explaining UI elements, triggered by hover, focus, tap, or click.". These don't include any links, buttons, etc.

Bárbara, Derek, and I met to discuss what would be the most simple and useful first version of pagination for the Table component for the upcoming use cases (GUC, Metrics Platform, Wishlist, etc.) and landed on this solution heavily based on Sarai's great work on this. This would be a great "fast follow" after the Table component MVP is finished.