This ticket may be out of scope for depicts crawling, but having a discussion around it could still be useful.

Right now the default desktop skin, Vector, fills up the entire width of the browser window with content – regardless of viewport size. Since the Depicts and Captions panels also take up the full-width of their parent element, that could lead to awkwardly-wide widgets, like this:

Unfortunately, this problem is not limited to just our UI elements in MediaInfo – it effects everything, article body text, other special pages, etc.

I think it is worth considering putting some kind of max-width in place, but ideally this would not be done piecemeal (and inconsistently) by every extension.

The tabbed layout that Cormac is currently working on may mitigate some of this, and it might also be worth checking in with the Readers Web team in case there are any recommended max-widths, breakpoints, etc. that they are using elsewhere that we could implement here.

If there are some quick fixes that can be applied in our code that won't create more inconsistency down the road, I am happy to try to implement them.

Pinging @Nirzar in this discussion for FYI

Let's not worry about the other elements stretching, vector not having a column grid is stopping us from implementing these changes. the task around that is pending since 2013 and it feels like a separate issue.

These are new boxes we are introducing. as far as the technical solution which is just adding width 60% to these boxes is feasible, we should do it.

either by adding that property to

wbmi-entityview-statementsGroup

or adding a container to

wbmi-entityview

also just FYI we will need to tweak the caption box fixed width mentioned when we reduce the box width
otherwise it breaks

@Nirzar do you know if there are any breakpoints / browser width values that are already in use in other places where it would be sensible for a 60% width rule to kick in at?

For example, even up to a viewport width of 1000 or 1200px, I think a full-width panel is fine:

But at extreme widths, things start to look wonky (here is the same screen at ~2550px wide):

My instinct would probably be to set a breakpoint that would take effect at around 1280px or so, or to just give the panels a max-width of 900-1000 pixels.

My final question is – will the inconsistency of widths between the different panel-style elements on the file page be more jarring than what we have currently (Summary and Licensing boxes would stay full-width even if panels get shortened):

based on our guideline

we use

• 320, 414 smartphone+ portrait,
• 568 for landscape smartphones
• 768 for tablets, 992 tablet+/netbooks,
• 1200 wide desktop

so I feel like we can do width: 60% / max-width:1200px

also thank you bringing up inconsistency!
here's my thought: we are adding new OOUI objects into old vector skin with old elements like the templates and copyright stuff. I think we should set the precedence for better layouts while we are adding new items. we can then go cleanup old stuff in future but when we do, we will just have to make the old stuff follow new guidelines and not the other way around.

does that help?

Thanks, good to know. As long as folks are okay with gradually adding more responsive features (even if it is not 100% consistent everywhere), these are changes that can be made now. @PDrouin-WMF I may have a few other questions for you tomorrow based on future UI elements that will be added here as more features get introduced. In the Invision mockups there is what looks like an explanatory text box off to the right of the structured data panels. I just want to make sure I don't end up making anything more difficult in the future.

Change 498261 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] WIP: Refactor panel styles to use LESS features, Flexbox

https://gerrit.wikimedia.org/r/498261

@PDrouin-WMF I'm working on this ticket as part of a patch to hopefully make panel styles simpler and more consistent generally. It turns out we can use Flexbox now, which has the potential to greatly simplify styling tasks.

Here is a screenshot of the current captions panel at a max-width of 768px, in both read and edit states.

Read mode:

Edit mode:

@PDrouin-WMF I'm going to now combine my work onto this patchset as well - I will upload new images later today that also reflect the changes I made together with Eric's.

Updates screenshots including work from T216773 (and in person design-dev pairing). @PDrouin-WMF

Captions -read mode:

Captions -edit mode:

Depicts -edit mode

@Ha78na a few more CSS adjustments need to be made regarding spacing/height/alignment:

Thank you!

Change 498261 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Refactor panel styles to use LESS features, Flexbox

https://gerrit.wikimedia.org/r/498261

Here is the current visual state of the panels:

Captions

Depicts

The panels are responsive at smaller sizes (as are their contents, because we are now using Flexbox for layout here). A max-width of 768 pixels has been specified. This means that users on tablet devices will generally see the panels take up all available width, but on screens that start to get larger the panel will limit itself.

As I just commented over at T216773, I understand that there may be some more adjustments that need to be made in terms of spacing, alignment, etc. Assuming everyone is happy with the new width and overall layout, I'd prefer to merge the current patch now and close this ticket, and then refine the design in smaller patches going forward.

This is looking much improved, really appreciate all the work you (@egardner & @Ha78na) have been doing!

Change 498261 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Refactor panel styles to use LESS features, Flexbox

https://gerrit.wikimedia.org/r/498261

@PDrouin-WMF Can we considered this finished and close/resolve this ticket?