Explore per-cell UI

[isabela-pf]

When exploring where the formatting buttons could be placed in the existing UI, one of the options we considered was a per-cell UI. This means that the formatting buttons would only appear near a Markdown cell in edit mode (instead of being persistent buttons on the toolbar as they currently are).

Reasons to explore

• Users see the UI they need when they need it, right where they would need to deal with it. It provides a direct, activity-based experience.
• The Jupyter community has expressed concern about adding more persistent buttons to JupyterLab's interface. This approach would mitigate the concern.
• Competitive analysis shows that per-cell UI is relatively common. This approach could help us stay in step with other notebooks.
• Eye tracking studies showed that users almost always look at the document first, so this UI puts tools they need in the first place they usually look. Participants were asked to complete the same text formatting task on two interfaces, one with the buttons in the toolbar (as they are now) and one with the buttons in a per-cell UI to the side of the cell. Participants found the formatting buttons slightly faster than in the toolbar.

Potential problems

• All current features may not fit comfortably in the space available for per-cell UI. There may need to be exploration for how the content flows into another space.
• It is less familiar placement. Word processors consistently put this content in the toolbar.

I will follow up with mockups to give a better idea of potential UI.

[isabela-pf]

Here are our top two options for how per-cell UI could appear. Both are not persistent toolbars and only appear when a Markdown cell is in edit mode.

First is above cell UI. It sits on the top of the Markdown cell, but, like the borderless Markdown cell itself, does not have borders but only the divider line to define the content area versus toolbar. It looks like this:

There could be some issues here if there is a long Markdown cell. If the toolbar stays only at the top of the cell, then you would not be able to style via button without scrolling back up. And I don't know if it's ideal to have the toolbar be sticky and overlap with text content.

Second is a UI that rests to the left of the a markdown cell. It could either be sticky, or appear next to the selected Markdown cell; I haven't decided to which might be better UX-wise.

This choice has issues because we can't use the same menu structure that we currently do, or at least not without modification, because the toolbar is no longer a long, horizontal bar but rather is more vertical. We would have to think about how the menus would change or if the content would overflow somewhere (like the side panel).