AUDIT - Left Sidebar Zoom

[trallard]

• 200%
• 400%
• Change the default value of text size from 16 to 30 in the web browser
• Test with different screen sizes

References

• Theme scope checklist
• Audit spreadsheet

[steff456]

These are the results of the Zoom Audit,

Icon behavior

Left pane behavior

Notes

• The directory icon is not centered vertically opposed to the other icons in any zoom - this happens only in binder
• Vertical padding is defined in px, therefore it doesn't change with the zoom or default text value in the web browser
• Changing the default text size doesn't do any effect in Jlab UI, but changing the minimum text size in the browser does create changes.
• Modifying to responsive layouts doesn't break the sidebar and its usability
• Sidebar container changes size dynamically for the height, the width always remains in 250px. This needs to be discussed to allow the rest of the interface to have more space.

Suggestions

• The definition of vertical padding and height are working as they are and they have sense to leave them in px.
• We need to define a new UX for when the left sidebar is taking too much space compared to the main area. My suggestion will be to compress the left pane to give priority to the main content area.

[isabela-pf]

As I was investigating solutions, I found that the scroll bars in the Running Tab also resize in a way that hides practically all their content at 400% zoom. I'm guessing there's some kind of maximum size for the scroll area, but the text within it resizes without constraints.

Note: Stephannie and I have noted we have differing results for 400% zoom. It's probably a combo of Chrome vs. Firefox things and my admittedly older JLab 3.0.3 that I default to for the time being. I need to verify if this is still a problem in newer versions.

For records, I found this with a combo of

• Operating System and version: MacOS Mojave
• Browser and version: Firefox 103.0.2
• JupyterLab version: 3.0.3

[isabela-pf]

I'm following up on this now that we have a direction for how the whole interface will interact with zoom and reflow. Based on this audit, to improve this area for high zoom we need to

• (as @steff456 noted) Design how the sidebar interacts with the main content area so that it can scale with the larger font and icons while not pushing things out of the viewport. This is a big question, and it's going to rely a good bit on me. It can be mirrored to fix the same problem in the right sidebar.
• (as noted above) Fix the header styling in the Running tab so that the contents under a header (like Open Tabs or Kernels) do not overflow when zoomed in. The sections can collapse and have a side bar scroll bar like the sections in the Extensions Manager tab if there are concerns about how long each section may get. (Was this already worked on and I just can't find it?)
• Make an overflow/"More"/… collapsing menu for the left side bar tabs. @steff456's audit doesn't show them running off the viewport, but it is a problem I have on my smaller monitor and one that could easily come up if more items are ever added to the left sidebar in the future.

• (Optional/Precautionary) Make an overflow/"More"/… collapsing menu for the File Browser's top button menu. Right now these buttons never overflow, but that is because the sidebars have a strict minimum width and they juuuuust fit within that space. I'm flagging this in case our solution to the above to do list involves removing that minimum width and makes it possible for the buttons to run out of the area.

[steff456]

I think we've discussed the second point, I think the fix is already in notebook v2... (Or in the demos maybe?) I remember seeing it but I'm not sure when that will be merged into Jupyterlab.

Make an overflow/“More”/… collapsing menu for the left side bar tabs. @steff456’s audit doesn’t show them running off the viewport, but it is a problem I have on my smaller monitor and one that could easily come up if more items are ever added to the left sidebar in the future.

In here you are referring to the tabs that have an icon? I may need to do some research because I think I’ve never seen a collapse menu on a vertical tab, like I’m not sure if we want to collapse everything if it doesn’t fit or if we want to do it depending on the screen size and the objects that fit. Do you have a vision for that?

I feel removing the minimum width may bring more problems with the items that are inside the sidebar.

[isabela-pf]

Point 1

Nothing to report yet. This is still in sketches.

Point 2

I think we've discussed the second point, I think the fix is already in notebook v2... (Or in the demos maybe?) I remember seeing it but I'm not sure when that will be merged into Jupyterlab.

I thought the same. I will go try and find the PR and see what the status is. Thanks for confirming.

Point 3

For point 3, "Make an overflow/"More"/… collapsing menu for the left side bar tabs" I am thinking of a collapsing behavior like the gif on the main menu collapsible menu PR. While I'd like to refine it a little more, here's my first pass at what that would behave like.

Screen.Recording.2022-12-22.at.3.32.08.PM.mov

In this case, the tab icon buttons that would be pushed out of the viewport when the page zooms are grouped and replaced by the more-vert Material icon. Clicking on the button breaks out a menu to choose from the collapsed options. This can be done as needed to switch between the collapsed tabs. Does that help make it more clear?

Point 4

I feel removing the minimum width may bring more problems with the items that are inside the sidebar.

I totally agree. There's so many moving parts that I don't think having no minimum width property would work well. But do you think there's no way to improve the minimum width? One of my initial ideas has been having the minimum width be a percent rather than fixed pixels, though I could see how that might create the same problems with small viewports.

I wanted to flag it since adding even one more button to that section will create an overflow (even at 200% zoom). Full disclosure, I'm not aware of any current plans to add to the file browser's top menu. If we don't want to change the current minimum width properties, then this point is probably future-proofing too aggressively and we should drop it for now.