Working implementation of WYSIWYG rich text cell in Jupyter notebook...

[Jonathan Gutow]

Dear all:

My son Colin and I have implemented a WYSIWYG rich text cell in the Jupyter notebook. As this requires changes to both backend and frontend parts we have not yet figured out how to put this up on mybinder.org or something similar. As such I have attached an mp4 screencast of it working on my netbook (file: Quill in jupyter.mp4). We still have some work to do but most functionality is now available.

We would appreciate people trying it. So if you are familiar with running Jupyter notebook from the git repo please take a look and let us know what you find. You will need both updated versions of nbformat and notebook to run this. We are using the following two git repositories. Thoughts and issues can be responses to this post or through the issue tracker in Colin's repository for notebook.

https://github.com/ColinGutow/notebook (the working branch is 'withQuill').

https://github.com/ColinGutow/nbformat

We are also interested in recruiting people to help us. Let us know if you are interested. Things we know we need to work on yet:

• getting downgrading to earlier notebook formats working cleanly, since this adds a completely new cell type.
• figuring out what to do about nbconvert, which knows nothing about the internal 'delta' format used by the Quilljs editor.
• porting this into Jupyter Lab.
• setting up a live demonstration of this feature.

Thanks for any feed back you might have.

Jonathan

[Colin Gutow]

I am the other person who has worked on this so far. I will endeavor to answer questions and provide assistance related to this topic when possible. As such if you have questions please feel free to direct them to either the thread head or myself.

[Jason Grout]

This looks really cool!

I would suggest that if at all possible, you work within the existing notebook format and not introduce a new cell type. There is a massive amount of momentum behind the notebook format as it stands.

Thanks,

Jason

On Thu, Aug 1, 2019 at 5:10 PM Colin Gutow <colin...@gmail.com> wrote:

I am the other person who has worked on this so far. I will endeavor to answer questions and provide assistance related to this topic when possible. As such if you have questions please feel free to direct them to either the thread head or myself.

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/df9d2c28-b5e2-4484-aa62-ccc66bc5cea6%40googlegroups.com.

[Jonathan Gutow]

On Thursday, August 1, 2019 at 7:15:27 PM UTC-5, Jason Grout wrote:

This looks really cool!

Thanks. Glad you think it has potential. For me it solves a serious problem with convincing non-programmers to try Jupyter for simple things, because it flattens the learning curve for producing notebooks containing instructions for our students. 

I would suggest that if at all possible, you work within the existing notebook format and not introduce a new cell type. There is a massive amount of momentum behind the notebook format as it stands.

I am not sure it is possible. The WYSIWYG cell is an extension of the basic cell type not the textcell (e.g. markdown). This means a new cell type had to be defined, so that it would be interpreted properly. Presently, the cell data is stored as a wordprocessor-like 'delta' json object. At best, I can imagine a way to store the data as raw html to maintain the formatting, but that would generate more overhead when loading a notebook (still, this might make issues with nbconvert simpler to address). All that said, the extended notebook format is the addition of a new cell type to the present format, so can read the present format, with zero issues. Going back the other way is more of an issue. It is probably best to convert the new cell type to html code cells or raw nbconvert cells with html content when going backwards. We are definitely struggling with the back conversion issue.

Jonathan

[Tim Head]

This looks great!

A while ago I experimented with adding WYSIWYG (to nteract). One of the problems to solve was exactly the question of "how do we do this without extending the notebook format". The answer I found is that some of the editors (like draft.js) are able to round trip markdown to their internal format. If you want to take a look at what I did back then https://github.com/nteract/nteract/pull/3699.

T

--

You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/d0340d82-2f3a-48e7-ad1d-ee2c54cd0104%40googlegroups.com.

[Tony Hirst]

Just for completeness (?) on this thread in sense of cross-referring to other attempts at notebook wywiswg tools, I'm not sure how the https://github.com/genepattern/jupyter-wysiwyg extension handles things (it seems to drop HTML into an enabled markdown cell, which can get really messy after a bit...)

--tony

To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

[Jonathan Gutow]

Tony,

Thanks for the pointer. The extension uses CKEditor4 which we decided against because it is pretty heavy weight and used iframes, making styling consistency more difficult. I see that CKEditor5 which does not use iframes is now available. We might look into CKEditor again although they make it difficult to look at the code if there are problems. The editor we chose, Quill, is relatively lightweight. Plus, I think the argument for their internal document model rather than just using html is good.

I can address your point about things getting messy when using the jupyter-wysiwyg extension that tries to keep everything in markdown and the questions others have asked about why I think jupyter needs a new cell type simultaneously. I have been thinking about this very seriously as I play with and debug the code we have written so far. I too would prefer not to change the notebook format if possible. However, I have concluded that if we want to continue making Jupyter easier to use and have it be useful over the long haul the notebook format will have to continue to evolve.

Ease of use considerations:

1. As you (Tony) have noted things get very messy in a markdown cell if you try to include formatting beyond the basic formatting supported in markdown. This is a problem for lots of users. Only if you are comfortable writing and editing html and are familiar with all the css embedded in Jupyter does this work OK. Others (including myself) find it frustrating to get the formatting I intend.
2. Unless you use markdown a lot it is easy to forget exactly what to do to get specific formatting. I and many users of Jupyter do a lot of other things and only use Jupyter for cases where we need to do particular kinds of coding or data analysis. This means making useful annotations in the notebook is almost always a frustrating experience. Also having to execute the cell to see if the formatting is what you actually want is frustrating. This is where WYSIWYG shines.
   
3. I think we want people to be able to concentrate on the work they are trying to do in Jupyter. Some examples where I do not think the users are likely to be interested in writing html code, but may need to format explanatory text more extensively than can be done with pure markdown: data analysis, code development, and my use case. My use case requires undergraduates to answer questions in a Jupyter notebook used for direct collection of lab data into the notebook. Freshman students taking chemistry do not need the added cognitive load of having to learn markdown to provide answers to chemistry lab questions. Additionally, the instructors who create the worksheets want to be able to use more formatting of their instructions than is available in markdown and do not know how to code html or markdown. 
4. From a user perspective I do not want a cell that I just edited using full WYSIWYG editing to open by default as a markdown cell. I want it to open as a full WYSIWYG editor when I double click on it. To be consistent with the way Jupyter works this means that the WYSIWYG cell is a different type of cell and as such has to be defined separately in the notebook format.
5. Related to the issue above is that getting clean conversion back and forth between markdown (with embedded html) and WYSIWYG is not easy. This stems in part from the ambiguity (which provides flexibility as well) of html. If the cell types are different, people have to explicitly choose to convert between the two and are more likely to accept and be prepared to deal with small inconsistencies.
   
6. The above also suggests that to make Jupyter easier to use Jupyter should also support a toolbar (that can be hidden) for markdown cells containing buttons and menus for just the formatting options markdown supports. Github does something like this. As part of the idea of markdown is that you can "just type it", I am not sure that a WYSIWYG version of a markdown cell is appropriate or necessary. I think WYSIWYG should be reserved for a rich text cell as done in the Jupyter fork I am working on.
   

Jupyter longevity considerations:

1. The currently chosen json format for the stored notebooks is admirably flexible much as xml/html and likely to have good longevity. The only issue I see is that people might want an automatic way to bundle up external files used in a workbook, sort of a zip archive. Embedded images are already handled cleanly as base64 encoded binary in the json strings.
2. The major issue is with the cell definitions. The idea of a code cell probably has staying power. However, a markdown cell is dependent upon a very specific type of coded input. Based on the number of text formatting schemes I've seen in my 35+ years of using computers, I do not have much confidence that markdown will be particularly popular in even 5 years. Therefore, to remain relevant long term, I believe that Jupyter will eventually have to add a cell type to replace markdown.
3. I do not think any of us can predict exactly what future needs will be. Jupyter should be prepared to update the kind of cells it handles while maintaining the ability to open older cell formats and convert them to newer formats when appropriate.
4. As presently coded the notebook format that includes the WYSIWYG cell accepts all V4 cell formats without any conversion. Additionally, the python code is available (although not yet implemented in Jupyter) to convert the WYSIWYG json code into html that can then be used to make a markdown cell when downgrading to V4. The key idea is that although this adds to the specification of a notebook it does not take anything away. If we were to default to opening unrecognized cells as rawNBconvert, older versions of Jupyter could open this extension without problems as well (is there a security reason for not doing this?).
   

In conclusion based on ease of use and longevity I think the Jupyter notebook and Jupyter need two changes:

1. Addition of a toolbar to markdown cells.
2. Addition of the new cell type WYSIWYG.

Jonathan

[Jason Grout]

Very interesting discussion. Just curious, did you look at Prosemirror for lightweight WYSIWYG editing for markdown cells?

Thanks,

Jason

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/2f8b6e45-84fb-41fc-b88a-29bd70f1da75%40googlegroups.com.

[Jonathan Gutow]

On Tuesday, August 6, 2019 at 2:45:32 PM UTC-5, Jason Grout wrote:

Very interesting discussion. Just curious, did you look at Prosemirror for lightweight WYSIWYG editing for markdown cells? 

I did briefly. It may deserve more investigation. It was meant to provide an intermediate between true WYSIWYG and markdown. It may be what should be used as the editor for markdown cells. A key is that I think there is some value to the markdown cells being a place you can just type away and get out formatted text. This is useful for people who are good typist and know markdown well. There is an example on the Prosemirror site where the user can switch between text markdown and what they call WYSIWYM.

After I get full rich text editing working and ported to Jupyter lab, I might be convinced to work on getting Prosemirror working on markdown cells. Is there somebody else who might work on this?

It did not look like Prosemirror could be used for full WYSIWYG rich text editing. Did I overlook something?

Jonathan

[Jason Grout]

I don't think it offers full WYSIWYG rich editing (that an html editor would). It's a simplified solution that may well work for many people (since you were talking about a solution that was really simple).

Jason

[Zach Sailer]

Dropping in here to say... we have a group of interns at Jupyter Cal Poly working on a Prosemirror extension for JupyterLab. It's still under heavy development, but they're extension already replaces markdown cells with Prosemirror editors for lightweight rich text editing. I would expect the first release in two weeks.

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAPDWZHwW8o-LMfX6ohGbR9P-b-QEt%3DXoi9r%2BORj4rC2eNDwXpg%40mail.gmail.com.

--

Zachary R. Sailer, Ph.D. 

Software Engineer | Project Jupyter

Github: @Zsailer | Twitter: @zrsailer

Email: zachs...@gmail.com | www.jupyter.org

[Jonathan Gutow]

On Tuesday, August 6, 2019 at 3:39:04 PM UTC-5, Zach Sailer wrote:

Dropping in here to say... we have a group of interns at Jupyter Cal Poly working on a Prosemirror extension for JupyterLab. It's still under heavy development, but they're extension already replaces markdown cells with Prosemirror editors for lightweight rich text editing. I would expect the first release in two weeks.

Zachary,

Great! Get it done.

I will keep working on the full WYSIWYG rich text cell in Jupyter notebook. Does anybody there have interest in helping with the port of WYSIWYG to JupyterLab? I suspect the experience of getting Prosemirror to work would make that easier.

The back end stuff we are working on should be independent of a JupyterLab port. The Javascript jupyter-notebook changes we've made do need to be translated to the JupyterLab environment.

Jonathan

[Zach Sailer]

If anyone wants to test the current progress of the Prosemirror editor extension in JupyterLab, check out this Binder.

--

You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/6c73425a-bf2b-4907-8e62-6b6b64a0b9c1%40googlegroups.com.

[Thorin Tabor]

The aforementioned extension is an nbextension only; it doesn't need an extension on the server or a change of the notebook format. It works by creating a CKEditor instance in front of a markdown cell and then embedding the HTML/markdown produced by the editor in the document once the user is done editing.

A CKEditor 5 version is in development but hasn't been merged into master yet:
https://github.com/genepattern/jupyter-wysiwyg/tree/ckeditor5

Thorin Tabor

[Tim Head]

Hi,

On Wed, Aug 7, 2019 at 2:56 AM Zach Sailer <zachs...@gmail.com> wrote:

If anyone wants to test the current progress of the Prosemirror editor extension in JupyterLab, check out this Binder.

This is super cool CalPoly interns!

Sometimes it seems to "eat" whitespace between words. As in I type a sentence with a space between words but no whitespace appears.

Another question (maybe to the JupyterLab experts) is: is there a way for lab to not capture keyboard shortcuts like `apple + b` when tying in a markdown cell? I just discovered that all sorts of "crazy" stuff happens to your notebook UI when you press apple + I or apple + B which I had guessed would change the formatting but turn out to already be bound as commands.

T

[Jonathan Gutow]

Sometimes it seems to "eat" whitespace between words. As in I type a sentence with a space between words but no whitespace appears.

Another question (maybe to the JupyterLab experts) is: is there a way for lab to not capture keyboard shortcuts like `apple + b` when tying in a markdown cell? I just discovered that all sorts of "crazy" stuff happens to your notebook UI when you press apple + I or apple + B which I had guessed would change the formatting but turn out to already be bound as commands.

T

A pointer to the probable cause. In Jupyter notebook, We saw similar behavior when we were not reliably making sure that the notebook knew it was in edit mode when editing the WYSIWYG cells. As JupyterLab duplicates the functionality of the notebook I suspect something similar is happening.

Jonathan