As a result of contextual views, responsiveness must be based on work item container width:
When the work item container is above MD breakpoint (768+px), show the sidebar.
At XS or SM (0-767px), show sidebar attributes and apps below the description and above page apps (designs, child items).
Individual widgets are responsible for their own responsive behavior.
Why?
Moving the sidebar attributes below the description will ensure they are visible without fully scrolling (in many cases, some will be visible without scrolling at all^); considering use cases like the board, where users today can only update attributes, this will ensure users can update items without scrolling and waiting on discussions etc to load.
Known issue: This may change the DOM order for the sidebar (i.e. is not truly responsive). This is acceptable to ensure information priority is optimized.
^ Truncation of the description will be particularly valuable when the sidebar reflows to keep a consistent height and allow attributes to be visible.
Risks/considerations
At the large end of the SM breakpoint the sidebar is reflowed, but remains relatively wide, which puts the "Edit" button far from the corresponding label. At smaller SM/XS sizes this layout is the same, but as the column is more narrow this gap is not problematic.
We explored a few alternatives, such as restricting the width of the of attributes container or breaking attributes into two columns. The two column approach worked well but for only a very limited breakpoint, and may not work well in all work item configurations as it's dependent on what widgets are present. This proposal keeps this as a single full-width column at SM breakpoint, but this is worth keeping an eye on.
View worst case / alternate approaches
767px, no change
2 col
This works only in the SM breakpoint, and as all work item types will need to use the same behavior, we can't predictably break columns "nicely" (i.e. if no apps, or many apps/attributes/values, will be unbalanced)
@donaldcook@gweaver From a design perspective this is complete. This is already fairly similar to the behavior in the 2-col FF, but let me know if there are any technical considerations not accounted for here.
Any preference on whether we close this issue and open an implementation issue, or just repurpose this one? Since this is pretty tactical I lean toward repurposing but whatever is easiest for you all to track
Thanks @nickleonard, looks good. Just had one question at the moment: what should the behavior be on mobile widths when clicking into a work item (linked tasks from issues, new create view)? Should we not use a contextual view at all if less than a certain width?
Any preference on whether we close this issue and open an implementation issue, or just repurpose this one?
My preference is to repurpose this issue, as long as you all don't need a separate issue for tracking your own progress/metrics.
Should we not use a contextual view at all if less than a certain width?
@donaldcook I don't think we'd need to change this, but unless it's a blocker here this should beconsidered as part of #409886 (closed) and for this issue just update as we have it today without changing views.
My preference is to repurpose this issue, as long as you all don't need a separate issue for tracking your own progress/metrics.
Works for me, just changed the title. Milestone is set for design complete and should be updated based on when this will get developed.
@donaldcook we are using them for something pipeline-related on MR page. There is some browser support missing (maybe only firefox ESR?).
I am pretty sure we can accomplish this without them, using display: grid and minmax to tell the sidebar when to wrap. That would also prevent the "sidebar reflowed but remains wide" issue we have currently near breakpoint boundaries.
alternatively, if we want to change document order based on size we could us JS breakpoints, then using container width is straightforward(ish..) anyway
I was thinking we could use grid to wrap the sidebar as well like Simon says if we don't have sufficient browser support for container queries. A benefit of grid would be achieving wrapping with less code.
But looking at the designs it looks like the design widget doesn't flow naturally after the sidebar in two-column view, so I'm not quite sure how we'd wrap the sidebar to slot above the design widget on narrower viewports. We could possibly resort to using grid template areas for this.
Nick Leonardchanged title from [UX] Resizing/reflow of work item layout for different screen sizes to Resizing/reflow of work item layout for different screen sizes
changed title from [UX] Resizing/reflow of work item layout for different screen sizes to Resizing/reflow of work item layout for different screen sizes
@nickleonard@gweaver Is this work a requirement for switching on the two-column work item view? I worry that we're bundling a lot of changes/dependencies in at once. If the edit buttons work is done before this one, ideally we wouldn't have to wait for this work.
@donaldcook Right now the two-column view works close to how this is described, with the main difference being the sidebar items being above the description. Is it possible to flip that order without implementing a more complex layout rewrite (it looks like we could just swap the order here)? If so I think that would be fine for MVC2 FF, and then we can follow up with any more structural changes as Coung described here (or whatever FE decides is best) - that way the general presentation wouldn't change much between iterations.
MD+
SM-
The other difference is around how height is handled and scrolling, which I realized wasn't called out here specifically (I've added it here, works similar to MRs today). Since the current behavior in work items is to scroll past attributes we wouldn't lose anything here for tasks if that's still the case, but we will want this for Epic migration.
@psimyn This looks spot on from an overall reflow perspective The bottom spacing as you note sticks out, and we'd want to add some space between the description/reactions and the top of the sidebar attributes when reflowed (it's 1.5rem total in the design), but the overall behavior looks as expected.
@donaldcook Not from my perspective. @nickbrandt do you expect any changes/additions to how the work item body reflows based on the contextual view design you're working on? From our past conversations I don't think there is.
@psimyn It looks like the current sidebar is set to 23rem (368px) while the design is 20rem (320px); from what I understand there was a glitch previously that required this larger sizing, but as we move to the edit buttons it could be helpful to review those using the "true" sizing. Is that something we could include here? It's fine to do that after all edit button changes if needed, but if we can do it now it'd make sense to do so.
@nickleonard in the MR I have fixed the spacing issue & the sidebar width, and the focus rings being cut off. There are still potential other things cut off currently (the "Assign yourself" button in Assignee widget), due to the position: sticky element also being scrolled. Will see if I can find solution for that as well.
here are still potential other things cut off currently (the "Assign yourself" button in Assignee widget)
That button and general layout changes in #429133 (closed), is that still an issue once that change is made? Assuming this change is reviewed prior to the edit button change we'll just need to communicate to reviewers those known issues/fixes in progress that are all behind the feature flag.
@nickleonard not an issue once the change is made, but I can also fix by making the button wrap so it doesn't happen. I'd quite like to get the layout change in ahead of the edit buttons; due to some strucutre/css changes it's more complex to feature flag this change.
@psimyn I'm fine with that wrapping until #429133 (closed) is merged and agree I'd also like to see this ahead of edit buttons so we can review those in the more finalized layout
I can't recall where else this is noted, but just to ensure it's captured here as well we will want to ensure that focus rings within the sidebar do not get cut off at any breakpoint. That includes both the Edit button and any focusable body content.