Type up requirements issue for Zoom fixes

[trallard]

From #11 #16 #18 #12 #14

• Review the findings
• Turn the findings + recommendations into concrete actions/tasks
• Assign ticket and work on

[steff456]

This is a summary of the Zoom audit in the latest Jupyterlab interface

Referenced issues

• Left sidebar audit
• Right sidebar audit
• Main content area audit
• Menu bar audit
• Context menu audit
• Settings audit
• Status bar audit

Findings

• The definition of vertical padding and height are working as they are and they have sense to leave them in px in the sidebars items.
• 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.
• Files in the main content area are wrapping lines instead of having a horizontal scrollbar, which allows to see all the code without any action.
• If zoom is activated some filenames are not visible in the tabs, but hovering over them will give the complete information of the file
• Opening a lot of files in zoom may cause to just seeing the icon and not being able to even close it
• The notebook's toolbar is responsive and all the options are visible and usable
• Cell options layout breaks with 400% zoom
• Python logo in the launcher pixelates with zoom
• Dialogs occupy the complete interface with 400% zoom
• The menu items start getting lost as zoom increases
• The dropdown menus are not visible or usable with 400% zoom
• Modifying to responsive layouts break the menubar and its usability
• Automatically we have a scrollbar to navigate through the options in context menus if not visible at first
• The size of context menus is fixed in px which occupy a lot of space in small screens or high zoom
• Settings is not usable in small screens or with zoom, the options are chopped and not readable
• Settings left menu area doesn't resize
• Settings is using the same gear icon for multiple entries
• The Status bar is responsive for even mobile screen sizes

General questions

• Do we want to support changes in the default text size of the browser? This will affect all the UI and right now it is using the minimum text size set in the settings of the browser.
• Do we want the dialogs to occupy and block the complete interface when zoom is high?
• Accessibility guidelines support the idea to have a button for context menus, do we want to follow it?
• The same gear icon in multiple entries of the Settings pane is intentional?

Tasks

• Define a new UX for the left sidebar when they are taking too much space compared to the main area
• Define a new UX for the right sidebar when they are taking too much space compared to the main area
• Define a new UX/UI for the tabs in the main content area, especially the cases where too many of them are opened.
• Make the cell options layout be responsive (it may include removing some options or adding ellipsis when the space is small)
• Change the python logo to a new image that has better resolution
• Dialogs sizes need to be checked for high zoom or small screens
• Add a hamburger menu in the main menu bar when the space is smaller to avoid loosing items.
• Dropdown menus from the main menu bar should open to the left/right depending on the space in the screen
• Check and define the UI/UX for context menus in small screens and/or high zoom
• Define a new UX for the Settings pane to handle small screens and/or high zoom

For more info about each pane please see its particular issue where screenshots and more notes are described.

[gabalafou]

Thanks for summarizing this!

I have some thoughts and comments about the above which I will cover in no particular order, one quoted line at a time.

If zoom is activated some filenames are not visible in the tabs, but hovering over them will give the complete information of the file

I could check on my Windows laptop to see what happens in similar situations on Windows if you like.

Do we want the dialogs to occupy and block the complete interface when zoom is high?

Ditto, could check something similar on Windows.

The menu items start getting lost as zoom increases

Ditto, could check on Windows.

Accessibility guidelines support the idea to have a button for context menus, do we want to follow it?

Can you show an example of this, a button for context menus?

Settings left menu area doesn't resize

I think I was able to resize settings left menu on mine. I can show in tomorrow's call.

Settings is not usable in small screens or with zoom, the options are chopped and not readable

Good catch on the Settings Editor. I imagine that our planned extension will need to make use of the Settings Editor. On my dev machine, which has a pretty high resolution (3072 × 1920), it starts to get hard to use at around 150% zoom in Chrome.

Modifying to responsive layouts break the menubar and its usability

I'm not sure what you mean by responsible layout breaking the menubar. Also not sure about your comment about the status bar and responsiveness. Perhaps we could cover this in the team call.

[isabela-pf]

Thanks for giving such thorough review and compiling your findings, @steff456! This is so pleasantly skimmable so I can figure out the best places to dive in with the more focused issues.

I'm not sure how much this comment will help, but I do want to say I think all your findings and tasks make sense to me. I think the following apply to me immediately

• Define a new UX for the left sidebar when they are taking too much space compared to the main area
• Define a new UX for the right sidebar when they are taking too much space compared to the main area
• Define a new UX/UI for the tabs in the main content area, especially the cases where too many of them are opened.
• Make the cell options layout be responsive (it may include removing some options or adding ellipsis when the space is small)
• Dialogs sizes need to be checked for high zoom or small screens recommendations for dialogs in small areas
• Dropdown menus from the main menu bar should open to the left/right depending on the space in the screen
• Check and define the UI/UX for context menus in small screens and/or high zoom
• Define a new UX for the Settings pane to handle small screens and/or high zoom

Does that sound correct?

I've been looking into patterns for zoom behavior and small screens in tandem. Zoom is an areas I've worked on less, so I think I'm still synthesizing the info I've gathered there.

I think my direct next step is to provide a low-fidelity visual and pattern for how each content area (from what you've listed) behaves in

1. a small screen (roughly mobile device sized)
2. a larger screen at 400% zoom (roughly laptop sized)
3. the ways they overlap/interact

[steff456]

Does that sound correct?

Yes, it sounds like a good plan :)

[trallard]

Questions to dive into

If zoom is activated some filenames are not visible in the tabs, but hovering over them will give the complete information of the file

Settings is not usable in small screens or with zoom, the options are chopped and not readable

📌 - need to scope/design

Do we want to support changes in the default text size of the browser? This will affect all the UI and right now it is using the minimum text size set in the settings of the browser.

Fix Zoom issues first and these should help with most of the issues.
📌 text sizing/scaling will be re-discussed

https://adrianroselli.com/2019/12/responsive-type-and-zoom.html

Do we want the dialogs to occupy and block the complete interface when zoom is high?

@isabela-pf will look at other tools and how they deal with these

Accessibility guidelines support the idea to have a button for context menus, do we want to follow it?

Refs:

• https://www.w3.org/WAI/ARIA/apg/example-index/menu-button/menu-button-links

• https://ux.stackexchange.com/questions/1173/custom-right-click-context-menu-on-a-web-site

• https://discussions.apple.com/thread/8271259

• https://stackoverflow.com/questions/29145435/are-custom-context-menu-accessible

• In zoom - if the option is too long then some of the content is lost

• Menu always opens to the right - we could try and define where this will open (left/right) depending on where there is more space

The same gear icon in multiple entries of the Settings pane is intentional?
⛔ out of scope for this work

@isabela-pf will work on:

• Define a new UX for the left sidebar when they are taking too much space compared to the main area
• Define a new UX for the right sidebar when they are taking too much space compared to the main area
• Define a new UX/UI for the tabs in the main content area, especially the cases where too many of them are opened.
• Make the cell options layout be responsive (it may include removing some options or adding ellipsis when the space is small)
• Dropdown menus from the main menu bar should open to the left/right depending on the space in the screen
• Check and define the UI/UX for context menus in small screens and/or high zoom
• Define a new UX for the Settings pane to handle small screens and/or high zoom
• Dialogs sizes need to be checked for high zoom or small screens

@steff456

• Change the python logo to a new image that has better resolution - tracked in ENH - Update Python logo in JupyterLab jupyter-a11y-mgmt#152

TBD

• Add a hamburger menu in the main menu bar when the space is smaller to avoid loosing items. - @isabela-pf might be incorporating into the mocks

• Need to add this audit and findings to the jupyter/accessibility repo - @steff456

[gabalafou]

One question all of this raises for me: should we say that we won't support screens below a certain width?

[trallard]

This sounds reasonable - might need to define what certain width it is

[gabalafou]

I was hoping that by taking a look at how Windows handles scaling, we might find solutions for squeezed tabs, dialogs, and file menu bars, since Microsoft has done a lot of work on accessibility. However, the results were a mixed bag. At 400% scaling, I came across multiple dialogs that had content off screen and with no way to reach it. With lots of open tabs in Edge, I found that there was no way to scroll through the tabs, but you could use keyboard shortcuts to cycle through tabs. In Microsoft Word, I discovered that the menu bar had a neat feature of putting little left/right arrow buttons at the left and right ends of the file menu bar; this keeps the bar on a single line, as opposed to wrapping the bar to two or more lines; however, at 400% scale, the fine menu bar disappeared completely and I had no idea how to find it, so that seemed less than ideal. I also noticed that in the settings app, the two-panel layout switched to a single panel after a certain point.

So like I said, mixed bag. But we may want to steal the left/right arrows for the menu bar. And we may also want to adopt the approach of switching a two-panel layout to a single panel with a back button to a one-panel home menu.

[isabela-pf]

Long overdue, here are some ideas on how to approach the reflowing and content prioritizing needed forJupyterLab to zoom up to 400% without losing content. I’ve been noodling over this at a few different levels, but I think we need to start with thinking about how all the parts interact before spending time on how each detail fits in the many JupyterLab regions. That's why we're operating in a neon, quilted JupyterLab land for now.

I think the core problem from @steff456’s review is the conflict of

1. Anything greater than 100% zoom limits how much can fit on a screen at once (like character count)
2. JupyterLab’s dense UI
3. Limited responsiveness of JupyterLab UI. What I primarily mean is that setting horizontal scrollbars for overflowing horizontal content, while technically means to access all the UI, are not generally best practice. Especially since many of the scroll bars have small target areas to scroll.

Only 2 and 3 are in our control, so my goal is to get us discussing what UI we want to prioritize as visible by default, what UI is collapsed (but not gone) as default, and how to optimize the responsiveness of these areas.

Option 0-3

This approach

• Removes side bar tabs
• Collapses the Main menu area into a single menu button
• Collapses tabs to prioritize the open tab/document name, New Launcher button, and ellipses to expand tabs as a list
• Adds all menus and side bar content to the collapsed main menu area
• Expanding this mega menu lists commands by region and takes up most of the window

Option 0-5

This approach

• Removes side bar tabs
• Collapses the Main menu area into a single menu button
• Collapses tabs to prioritize the open tab/document name, New Launcher button, and ellipses to expand tabs as a list
• Adds all menus and side bar content to the collapsed main menu area
• Expanding this mega menu brings up a command palette with commands by region marked a la table of contents

Option 0-9

This approach

• Removes side bar tabs
• Removes the document menu
• Collapses tabs to prioritize the open tab/document name, New Launcher button, and ellipses to expand tabs as a list
• The command palette, which can be found via the View menu or the shortcut, is used to access all else

Option 0-4

This approach sets the UI based on how the user is interacting with the document. Command mode is for high-level document traversal and edit mode is activated when a user has entered an editable part of a document (ie. when focus in a notebook moves from outside a cell to the editor region of a cell).

When in command mode, this approach

• Removes side bar tabs
• Removes the document menu
• Collapses the Main menu area into a single menu button
• Collapses tabs to prioritize the open tab/document name, New Launcher button, and ellipses to expand tabs as a list
• The command palette, which can be found via the View menu or the shortcut, is available

When in edit mode, this approach

• Collapses the Main menu area into a single menu button
• Collapses the side bars into their narrow variations
• The command palette, which can be found via the View menu or the shortcut, is available

Notes

All of the above are very rough explorations to get discussion started, so they all need more ironing out in order to fill out what the user flow would actually need to be from end to end. Please point out missing gaps, but also know I may not have all the answers yet.

I think option 0-4, while pretty logical and following patterns of other dense, document-based interfaces on small screens, probably isn't viable. It's a totally different experience than JupyterLab unzoomed or at a large screen, and it seems wrong for the UX to be that great. Still, I wanted to provide in case it sparks ideas that are more flexible.

As always, feedback and questions are useful. Thanks! 🌻

[steff456]

I also like a lot the option 0-4, I think is the less disruptive one in terms of the current UX in JupyterLab. I think we might need to explore the idea of completely collapsing the main menu, in terms of API flexibility and location of panes.

I think my main concern with options 0-9, 0-5 and 0-3 is how to manage hiding the sidebars, are they going to be always hidden? How are we going to manage all the options that are inside of them?

[gabalafou]

Thanks @isabela-pf for providing the scaffold for us to have more concrete discussions.

I finally got a chance to re-review these proposals.

I also did a deep dive into WCAG 1.4.10 - Reflow aka 400% zoom. I played with Google Docs and Google Colab at 320 CSS px. On desktop, 320 CSS px means start at 1280px width at 100%, then zoom up to 400%. I also played with JupyterLab on my Windows laptop. And I played with it on my iPhone at various levels of zoom and text sizing.

It reminded me of my findings when I scaled up Windows really high and tried to work with Microsoft Word: disappointing, discouraging.

I'm starting to feel that it simply might not be realistic for us to try to rework JupyterLab to meet guideline 1.4.10.

I'm not saying I think it's impossible for us to conform to the guideline. But I want us to ask if it would be worth it. This guideline might be the hardest of all of them to meet with JupyterLab. I have yet to see a classic desktop-style app that strictly conforms at 320 CSS px. Can someone give me a counter example?

Now, the counter argument is that Isabela's proposed layouts could conform to the guideline. But my guess is that Isabela's suggestions will take a lot of effort to implement. I'm not sure they can be done in an extension, and if they can't, it would require either a fork of JupyterLab or a lot of changes to the core of JupyterLab. Maybe this is where we need an engineer with lots of JupyterLab experience to give us a quick size estimate.

That being said, my alternative suggestion is that instead of trying to conform at 320 CSS px, we try for analogous reflow conformance at 640 CSS px (aka 200% zoom instead of 400%). We will need to do that anyway to conform to guideline 1.4.4: Resize Text. This will still give us a lot of work to do, but it seems more tractable to me. 400% zoom is much more than twice the work of 200%; to me, it's like 10x or more. That's because 200% zoom unlike 400% doesn't require a complete re-think of the existing UI, which is what I consider Isabela's layouts above to be.

Correct me if I'm wrong but I think 320 CSS px was chosen to ensure that web pages would be responsive across a very broad array of mobile devices. Perhaps it's okay for us to say that it's a higher priority for us to focus on the accessibility of the desktop experience (plus tablet).

I dunno, what are all of your thoughts?

[trallard]

Some thoughts 🤔

1. Going back over the criterion and many docs - from https://www.digitala11y.com/understanding-sc-1-4-10-reflow/

Generally, if a menu is horizontally spread over a big screen, it either shrinks to a single column menu or further wrapped in a hamburger menu at the top of the main content when the user zooms the page. Similarly, content can be wrapped within a toggle type element that can expand/collapse or show/hide them in a single column. All that matters is that the SC requires that there should be no loss of content or functionality and/or a horizontal scroll bar.

So TLD;R the expected behaviour of the reflow is that at 200% (and +) the content will be a single column, and navigation menus will appear below or under the main content.
This paired with:

The Success Criterion is met as long as all content and functionality are still fully available - either directly, or revealed via accessible controls, or accessible via direct links. (from https://www.w3.org/WAI/WCAG21/Understanding/reflow.html)

These behaviours are, IMHO what we should strive for rather than trying to be extremely precise and adhering to the 320 CSS px requirement.
Why? - As we have discussed (many times), JupyterLab is not a website or desktop app but something else. And this is one of the cases where we can meet the criterion (or at least the critical bits of this) even if we do not rigorously meet the nitty gritty details.
I am not saying completely scratching the 400% support - but we need to find a balance among work towards meeting the criterion and understanding and verbalising the limitation of WCAG in our particular case (i.e. Lab). Also we should be aware of the fact that many uses of Jupyterlab (outputs and the such) will fall in this criterion exception:

Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

This is not a simple problem - and we cannot anticipate/fix/prevent all the scenarios and possible fails.
The goal here - is not to only meet WCAG criteria to the T as a check boxing exercise but making JupyterLab usable in situations and by folks who currently cannot use it (at all). And @isabela-pf 's solutions (or at least one of them) might get us there.

2. Now on the effort/time/approach

But my guess is that Isabela's suggestions will take a lot of effort to implement. I'm not sure they can be done in an extension, and if they can't, it would require either a fork of JupyterLab or a lot of changes to the core of JupyterLab. Maybe this is where we need an engineer with lots of JupyterLab experience to give us a quick size estimate.

They will require a lot of work, yes. More thoughts:

• This is a case I would rather not have in an extension (IMHO an extension is a suboptimal approach for this case): the maintenance, alignment, and hacking work is not worth it. We might be able to get this in an extension, we might not - but is that is the case we will have to spend significant time experimenting.
• We want this to end in core anyway - and personally, I do not want to do a fork of JupyterLab this is not good for the community or us.
• We have folks like Gonzalo and Mike who have spent a good amount in Lab - we could and should work with them to gauge scope and estimates internally (though estimates are rarely perfect so I always approach this with a pinch of salt). They have spent a good chunk of time working on Lab, and we should definitely leverage their knowledge and expertise.

As we discussed last week (or maybe the previous one) the best path forward is this and it is what we should do:

1. Decide on 1 or max 2 mocks or approaches (from Isabela's proposals) that will help us to get JupyterLab to be usable at 200% + (aiming for 400%) and meet the reflow (sans pixels - or maybe with if possible?) criteria/expected behaviour within JupyterLab.
2. It is a significant change, so we need to discuss this with folks like Gonzalo, Matthias, and Mike first and get their feeling for this proposal and the following work.
3. Propose to Jupyterlab - I do not want to delay this step; it is a significant change, we have been collecting information, and @steff456 did a fantastic job with the audit and documenting the findings. Delaying this by working on a fork or extension will more than likely/surely lead to more back and forth and more work and effort on our end. The sooner we can align with the Lab team, the better for us, them and the community. And I have confidence that the Lab team wants accessibility/usability improvements in core so let's aim to have this in core from the start. We have done our due diligence with the audits and documenting the findings, we will have the first iteration of our "accessibility checker" soon, and we will soon have some proposals to address the usability issues from the reflow criterion. And we need to put all this evidence together and articulate why we are proposing said path and the limitations of such an approach. Whether this is dropping (a maybe terrible and extremely burdensome) implementation in favour of finally making Lab usable for low vision folks. Because to me, that is what matters the most; great if we can meet the criterion to perfection and to the smallest of requirements - (remember, we can have a perfect score and still end up with something that is not usable), but we should keep in mind that our goal is to improve access to Lab instead of bending over to meet criteria that were developed and designed with different tools and workflows in mind.

I know it can sound like a drag (😉) aiming to align multiple stakeholders and potentially ending in many calls, syncs, and the such. But this is inevitable - and the sooner we get this done, the better. I am happy to join all the calls, align all the folks, and have all the discussions needed, it might seem like a big hurdle at first but long-term this will make it easier for all parties involved and we will be wasting less resources.

[isabela-pf]

Following up on the discussion from a few hours ago, we will be moving forward with working on this from 200% zoom. I don't think this changes much from a design perspective in the sense of interaction patterns and needing to free up space for the document.

[isabela-pf]

Okay, here’s another idea for review! Please note that this is an opinionated take because I think it’s easier to critique that way. I have some issues with this solution—or at least questions that need more attention—so I’m expecting we’ll end up with a more moderate compromise.

The major changes:

• This version continues to put the document area into focus at small sizes by removing some of the surrounding UI and adding it to the command palette.
• The command palette is given a button for easy access, and regions that collapsed have sections to group their commands pinned to the top.
• Open document tabs are grouped and hidden behind the ellipses, but switching them does not open new browser tabs.
• UI areas originally in the sidebar become their own tab in the document area a la the launcher or settings. UI areas that are reliant on a selection in the main area appear as an overlay to the tab, but this should be used with discretion.

All at once, here’s a basic set of interactions for when users zoom and and how they might navigate when the layout changes.

Screen.Recording.2022-09-28.at.5.00.59.PM.mov

Breaking that down, I’ll explain key points with notes.

The main menu and both sidebars disappear at 200% and not before. Document name/open tabs are at the top followed by the document menu if the document type has one. Any document specific UI (like the notebook cell toolbar) would stay.

The command palette stays as an overlapping dialog-like thing. Pinned at the top are sections for easy navigation of the UI areas removed, in this case the main menu and side bars. I do believe this could be open so that extensions could opt in to add themselves as well, so I like the potential for it to scale even if it’s not our main concern. I do think all commands we add should be available in the command palette at all times, but they may not need to be pinned by UI when the main menu and side bars are visible at lower zooms.

Areas from the sidebars that are not document-reliant can open as their own tabs. For example, the file browser can exist totally separate from all open documents. This behavior matches the launcher and settings. Tabs also can be listed for easy switching without relying on the main menu or sidebar options that are less available. I think this should exist for JupyterLab at any zoom level, to be honest.

Areas from the sidebars that are document-reliant can open as some kind of overlap. For example, the table of contents is generated based on the open document selected and can’t work without a document chosen. I don’t love having these two behaviors at once, but it’s what I have for the time being.

Finally, this shows how the approach can scale to 400% browser zoom. I know 200% is the current focus, but I think it’s worth noting. I also think this can work with different screen orientations.

Questions that might help you get the feedback muscles moving!

1. How do you think this compares with JupyterLab’s current behaviors at 100% zoom and higher?
2. What problems and edge cases can you think of facing with removing areas of the UI? Or with the ones I’ve proposed adding?
3. What technical constraints come to mind?
4. What UI do you think does a good job at this?
5. What parts do you like? Why do you like them. You can do the same for dislikes.

[gabalafou]

Thanks @isabela-pf for amazing work, and once again providing the scaffold for us to have concrete conversations.

I have some thoughts that I want to break down into two sections. In the first section I remain a bit abstract. And in the second section, I try to offer thoughts that are more concretely tied to Isabela's idea.

Translating Dimensions

I think one of the biggest challenges we face with WCAG 1.4.10, or making JupyterLab work at 400% zoom (or 320 CSS px) is that much of the JupyterLab UI was built around the assumption of having enough space to work with in both the x and y dimensions. Let's take the Contextual Help feature for example. You can get to it by right-clicking on a code cell and clicking "Show Contextual Help" near the bottom of the context menu that pops up on right click. That opens up a Contextual Help tab to the side of the notebook document tab. So together, the notebook and contextual help are displayed side-by-side. It looks like this:

We could keep going like this, pulling up example after example of how the current UI has been built around the assumption of having horizontal space to work with. (We could also pull up examples of the how the current UI has been built around a similar assumption in the y/vertical dimension. For example, in the left sidebar, if the vertical space reduces too far, some of the buttons disappear and you cannot scroll to them.)

But I think that in order to properly meet the 1.4.10 guideline, we will have to translate that UI paradigm from x and y to y and z, by which I mean, we will have to think about pulling things that are laid out horizontally and stacking them vertically, and whenever we can't stack them vertically, we'll have to stack them on top of each other in the z axis (the axis coming out of the screen). Let's take the Contextual Help feature, as an example. Instead of opening it to the side, we could imagine opening it as a modal. As another example, I don't think we've considered taking the sidebars and laying them out horizontally instead of vertically.

To continue on that last thought, I could imagine getting rid of the top menu bar (File, Edit, View, etc.) and replacing it with a band at the top that acts as a kind of app switcher. The File Browser would be an app, the Open Tabs and Kernels would be an app, as well as the Table of Contents, the Extension Manager, the Debugger, the Property Inspector, the Settings Editor, the Launcher, the Notebook Editor, and so forth.

But I think translating (x, y) to (y, z) is a pretty drastic refactor of the UI, which is why I've had my doubts about being able to meet this WCAG guideline.

More Concrete Thoughts

That said, I'd like to offer some thoughts on Isabela's idea. I'm not sure how to organize my thoughts, so apologies for the stream of consciousness.

First of all, I think the idea of getting all commands into the command palette is a really smart idea. Whatever route we decide to go down, I think having an always-visible button that opens the command palette is an accessibility feature that we should consider adding to JupyterLab.

Secondly, I still see this as a kind of mobile-first renovation of the JupyterLab UI. On Monday, it might be worth discussing the trade-offs of going down that route versus one that attempts to patch reflow issues in a minimally invasive manner. In a previous conversation that I had one-on-one with Isabela, she pointed out that if we go down the route she proposes, it might save as much work as it creates. Specifically, we won't have to spend time fixing the various side panels if they disappear at 200%. But then again if the aim as suggested by the new 200% mocks above is to pull the side panels out from the side and into document tabs and on-top-of-document overlaps (or modals), then we're back to either having to create new UIs (such as the new open tabs UI imagined above) or having to fix these sub-UIs for narrow screens / high zooms (such as in a table of contents overlap at 200% or greater zoom).

Another thing—I'm sure you've already thought about this—but I'm not sure that it's feasible (from a usability perspective) to take the debugger panel out from its side position and into either a modal or separate tab. I'm not sure (perhaps for lack of imagination) how I would use a debugger without seeing two things at the same time: the code that I'm stepping through and the tools to step through that code. That said, I don't want to imply that I think we should abandon Isabela's proposal just because it may or may not work for one or two extensions that ship with JupyterLab by default. Because overall I think Isabela's designs are the best choice we have right now for the end user experience (over and above conforming to WCAG 1.4.10). The question that's been turning in my head, and for which I don't have a very confident answer, is whether it's feasible—or whether there's a more feasible route.

On a smaller note—the mocks above don't show this—but I think we should get rid of the status bar at 200%.

I hope some of that is helpful! :)