Very interesting discussion. Just curious, did you look at Prosemirror for lightweight WYSIWYG editing for markdown cells?
Thanks, Jason On Tue, Aug 6, 2019 at 12:23 PM Jonathan Gutow <[email protected]> wrote: > 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, <https://quilljs.com> 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 <https://github.com/forgeworks/quill-delta-python> > (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 > > On Tuesday, August 6, 2019 at 12:00:28 PM UTC-5, Tony Hirst wrote: >> >> 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 >> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jupyter/2f8b6e45-84fb-41fc-b88a-29bd70f1da75%40googlegroups.com > <https://groups.google.com/d/msgid/jupyter/2f8b6e45-84fb-41fc-b88a-29bd70f1da75%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAPDWZHxFLdREZjGhVY0Loxvi7Jck%3DSFJ73nqNnyZQR0G0aPt3Q%40mail.gmail.com.
