First Release Goals

[isabela-pf]

After adding features for the past few months, we want to temporarily switch our focus to cleaning up each existing feature and resolving bugs associated with them. We've decided to focus on the following features first:

• Bold
• Italic
• Underline
• Text Styles

All the other features we've added will not be going away, they will just remain as-is until our next round of feature clean up.

Why are we doing this?

• We want to make sure that the features that are likely to be used first (by those new to our extension) or most often are as reliable as possible.
• We need to clean up some of the implementation methods to create more solid and sustainable code.
• We are interested in proposing our extension be added to JupyterLab core. We need to clean the extension up to do this.

[isabela-pf]

Here's the first idea of how this change might be represented in the UI.

As previously mentioned, all features outside of our first release focus will remain in the extension. They also will be moved from being immediately visible in the toolbar to a "More" (... icon) on the end of the toolbar. This menu not only clears up the toolbar, it gives us the opportunity to mark these features as "In Progress" so that users know they may still run in to issues when using them.

Much of the menus for these features remains the same after that, and the shortcuts for them will not change.

To make sure that math/LaTeX auto rendering is still properly seen as a work in progress, users would also need to enable math in the extension. After enabling it, it works the same as it does currently.

[krassowski]

I understand the aim of hiding the things away for the first release and to mark them as "in progress"; given the choice of the features you decided to focus on first I just wanted to share my use case for a "code" button and why it is very important for me:

The backtick key is used in my system for terminal so I cannot type variables nor code blocks with the backticks easily (I need to copy the character from somewhere else; it can get really annoying; I cannot get to change my tilda = terminal habit neither - which seems to be a common thing); for me the foremost advantage of this extension would be the presence of a "code" button easily exposed (like this on the GitHub):

Furthermore, I find the code feature to be the most frequently used feature (just ahead of "bold") in my notebooks. I not only use it for code implementation discussion, but also to present identifiers such as transcript or gene names (which need to stand out semantically).

I appreciate your work on this extension and please do not take this as a critique but as advice on a user case in case you will ever need to decide which buttons should be visible (or not) in the future versions (e.g. to reduce the clutter). Thank you.

[isabela-pf]

I really appreciate your feedback @krassowski . It's great to hear that this extension has been helpful and to hear how you are using it!

We chose the highest-priority features based on writing-centered use cases formulated by looking at how people used notebooks on GitHub, and so we decided that character-level formatting (like bold, italic, and underline) were some of the most useful to a wide group of users. I know you mentioned that you use the code feature similarly to these, but we focused on the standard Markdown understanding of the code feature, so we don't usually consider it a part of the character-level formatting group.

Our choice to use backticks as a shortcut for code blocks is also founded on Markdown syntax. Because we are still working with Markdown and know this extension is frequently used by people who are already familiar with Markdown syntax, we wanted to support familiar keystrokes to make for an easier and quicker transition to our extension.

Still, you likely aren't the only person who may have custom key setups that conflict with our shortcuts. Here are a few solutions that could be explored:

1. Provide an alternate keyboard shortcut for code blocks. Right now inline code uses Ctrl/⌘ + < rather than the associated Markdown syntax, so inline could should still be easy to access in your case. We would still want to keep the Markdown syntax available, but there could be another way to trigger code blocks. The immediate question is how to handle the choosing a language for the new code block.
2. Make the UI of the extension configurable. In this case, users could choose which features they want immediately on the toolbar in the settings or extension manager. The extension isn't currently set up to support this or an easy transition to it, but it could be a future goal to better address the wide variety of ways custom controls could conflict with our preset shortcuts.

I also want to note that there could still be changes to this UI as I get to iterate on the problem more, so there's always a chance to come up with or incorporate new solutions. Let me know what you think, and thank you again for weighing in!

[krassowski]

The second idea (configurable UI) sounds great to me. Given my knowledge of the extension development, this seems relatively easy to implement.

A more ambitious idea for the future: maybe (just maybe) it would be worth bringing this up to the JupyterLab core (and design) team (@ellisonbg?), to implement a JupyterLab-wise solution? If the problem to solve is that many extensions add custom buttons and those may clutter up the top panel of the notebook (if the user installs many such extensions), could we create a way for the user to rearrange the buttons (e.g. drag-and-drop) and decide which buttons should be shown? This is a common feature in advanced text editors (MS Office or LibreOffice) and in some IDEs, with a few design options to explore (e.g. a dedicated modal window, or just context menu commands).

Edit: and of course, many thanks for your work here and the exhaustive response @isabela-pf!

[ellisonbg]

I think eventually we will need to do something like that as more extensions add buttons.

…

On Fri, Oct 11, 2019 at 9:09 AM M. Krassowski ***@***.***> wrote: The second idea (configurable UI) sounds great to me. Given my knowledge of the extension development, this seems relatively easy to implement. A more ambitious idea for the future: maybe (just maybe) it would be worth bringing this up to the JupyterLab core (and design) team ***@***.*** <https://github.com/ellisonbg>?), to implement a JupyterLab-wise solution? If the problem to solve is that many extensions add custom buttons and those may clutter up the top panel of the notebook (if the user installs many such extensions), could we create a way for the user to rearrange the buttons (e.g. drag-and-drop) and decide which buttons should be shown? This is a common feature in advanced text editors (MS Office or LibreOffice) and in some IDEs, with a few design options to explore (e.g. a dedicated modal window, or just context menu commands). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55?email_source=notifications&email_token=AAAGXUBBG66WI6S3LG26UG3QOCQNBA5CNFSM4I6KUPU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBAPA2Y#issuecomment-541126763>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUESJCJKYVWUVXS2YK3QOCQNBANCNFSM4I6KUPUQ> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform (brgrange@amazon.com) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub