Change Markdown editor to WYSIWYG editor

[blackforestboi]

Hi there,

I continue the discussion of the closed pull request #1478 here as a new feature request.

Original Message

Hi there!
We are the WorldBrain Team, our goal is to develop a browser plugin, that allows it to see, if an article, blog post or video is trustworthy, based on how well it represents scientifically verifiable facts.
As a first step, we are working on a book webmarking tool for skeptics, science journalists, scientists and STEM-students. (www.worldbrain.io)
For this we want to fork hypothes.is, but contribute as much as possible to the hypothes.is core, so that everyone benefits from this solid foundation you built there in the last years.
Thank you so much for this. You didn't an unbelievably awesome job with it.
Looking forward collaborating with you 😄 🎉

COMING TO THE FEATURE

We are picking up this feature, because we see the value of having a slim WYSIWYG editor for the broader user base.
Many people are not really experienced in markdown and it is a new hurdle for users to conveniently use an often used software.
It is time consuming to get into this new habit, which many people are not familiar with.
Also there are other convenience problems in the current version when other files have to be somehow saved to commentary too - like charts or pictures.

We also found an alternative for the TINY MCE editor:
An open source project, licensed under MIT: https://mindmup.github.io/bootstrap-wysiwyg/

PERKS OF MINDMUP WYSIWYG

• Same slim customising feature set -> Individuality but still structured
• PLUS: Allows (drag&drop) picture upload from local file system
• Undo - Redo Buttons
• 5kb in size
• MIT license

DOWNSIDES

• currently no easy way to add images via a link, like your markdown editor allows it.

QUESTIONS

• What do you think about this idea?
• Is there an issue where you discussed about the pro's and con's of both approaches?
• Maybe there is also the possibility of merging features of both?

SCREENSHOTS

WYSIWYG:
Normal:

File Upload:

Current Toolbar:

USER STORY:

Richard a skeptic and heavy web user and has massive amounts of text, files and pictures he processes every day. He needs a quick way to save up all necessary information like pictures.
The current editor doesn't allow him to easily add his own pictures, which he saved in his extensive offline folders and files or draws from the web to his commentary. Instead he would have to upload it to a separate service like imgur.com and then attach the link in the markdown language - for every picture or chart.

Richard also saves up his research (good links, titles, notes, images, files) into large wordfiles to consolidate it. If he is not able to do this with the comments of the annotations, there is important information only saveable with inconvenience(as explained in first story), so he might rather stay with his word files.
For hypothes.is and WorldBrain to be widely adopted, there should be a way to add more than just a link-based image to comments.

[decentral1se]

Maybe there is also the possibility of merging features of both?

Yes, I think it is also worth debating if making the editor configurable would also be an option. In which the markdown exists as the default and WYSIWYG is an optional. Not sure how feasible this is (reading the code in the coming days!)

[blackforestboi]

This is the answer to the last post by @robertknight in the issue #1478

We consider this feature as quite important, regarding our user feedback.
Can you explain a bit more about who "we" is in this context and who you have feedback from already?

We as the WorldBrain team. Over the last 7 months I have been conducting around 40 user interviews with skeptics, scientists, journalists and students.
The found theme:

• Many images to process (charts, memes etc)
• Medium to low technical affinity -> Convenience is highly important.

Since the editor we suggested is really slim in customisation,
it shouldn't be a huge problem to convert it into markdown I assume?
I wouldn't have thought so - but the best way to find out is to actually try implementing it.

Ok:) @lwm @Geass

I think it is also worth debating if making the editor configurable would also be an option. In which the markdown exists as the default and WYSIWYG is an optional. Not sure how feasible this is (reading the code in the coming days!)

@lwm top! all right. Looking forward to your feedback

[tilgovi]

Chiming in to say that I disagree with @robertknight that whatever is used must be able to be converted to markdown. Another path to consider is one where the annotation body gains a content type and a migration declares markdown for all existing bodies. Such a change would make the body an object rather than just a text property, too, which accords better with the web annotation data model.

[JakeHartnell]

Chiming in to say that I disagree with @robertknight that whatever is used must be able to be converted to markdown.

+1

I remember part of the reason we didn't choose a WYSIWYG editor at the time was that no one was really happy with TinyMCE or what was out at the time. After playing around with https://github.com/mindmup/bootstrap-wysiwyg/ for a bit, it seems very promising.

[tilgovi]

Here's a list: https://github.com/iDoRecall/comparisons/blob/master/JavaScript-WYSIWYG-editors.md

The two that stick out to me for are:

• https://github.com/yabwe/medium-editor
• https://github.com/guardian/scribe

I like them because:

• Active, modern development
  • automated testing
  • npm packages published
  • recent commits
• Self-contained without pulling in large libraries (bootstrap, jquery)
• Extensible
• MIT and Apache licensed respectively

Scribe may not work in IE. It's not tested. It's not known to work. It may work with Rangy from what I see.

[blackforestboi]

Thanks @tilgovi for joining in :)
And thank you all for the warm welcome! 👍

Sooo after...

...I found out the following

Medium Editor

https://github.com/yabwe/medium-editor

The medium editor looks pretty awesome.
As far as I can see, it lacks some features like strikethrough or bullet points though, while I find the latter to be essentiell.

For everybody to test: http://yabwe.github.io/medium-editor/

Scribe

https://github.com/guardian/scribe

Here the picture upload is not possible, as far as the demo allows it.
Even the markdown editor allows images to be imported at least via links.

For everybody to test: http://guardian.github.io/scribe/

MindMup Wysiwyg

https://mindmup.github.io/bootstrap-wysiwyg/

Downside I see here is that it not really well maintained. Last commit was in April 2015.

Independent from what we find out to be the best option, there might be some extra chance with MindMup.
After some research I stumbled over on of the guys behind the WYSIWYG editor, Gojko Adzic.
He is one of the creators of MindMup, the open source mindmapping tool.
He might be a good person to talk to in any case.
The theories behind mind mapping, and a software that can support them, could play an important role in letting users connect notes and their research with Hypothes.is and WorldBrain.

Summernote

Was the first place of the list of editors to use.
This. Is. Awesome.
Allows everything.

• Picture upload from local file system. Also drag&drop
• Picture attaching via link
• Video attaching via link
• leightweight (80kb)
• in active development
• MIT license

Downside:

• A little bit too much to modify in my taste (fonts, Code view).
  Happy if we can switch off some features, which is surely debatable.

For everybody to test: http://summernote.org/

Summing up:

Disclaimer: I am just starting with Python and have only superficial knowledge about many technical aspects. So please forgive me, if I am missing out on perspectives. I am eager to learn though :)

1. From my POV, I don't see a real alternative in Scribe or the Medium editor over even the current Markdown editor. The WYSIWYG editor seemED for me like the best option from the user experience and functionality.
   If we can remove some functionality from the Summernote editor, then for me this is the winner at this point.
2. We should contact Gojko Adzic for a chat about our projects.

[robertknight]

I like them because: ...

@tilgovi - Thanks. These criteria are all important for me as well. Additional criteria I would add are:

• Size - We've recently slimmed down the Hypothesis client considerably and there is still substantial room for improvement. We might look into lazy-loading functionality in future, such as editing and math support, but I still have a strong preference for something small.
• Mobile UX - This will be an area of focus for us after direct linking.
• Minimal UI - Related to mobile UX, we have limited horizontal space to play with in the sidebar

@oliversauter - I'm afraid you can't just take the quoted size on the homepage at face value. In the case of Summernote for example, it has a dependency on jQuery and Bootstrap. Add in the CSS and the minified size comes to >350KB. Gzipped that's ~100KB, which translates to at an extra 2-4 seconds load time on mobile.

MediumEditor looks promising after a brief initial look, except for the absence of mobile support. I'm inclined to suggest that overriding the browser's default selection toolbar is not a good idea (though extending the native toolbar would be nice if there was an API for that), so we'd need to present the UI some other way.

[blackforestboi]

@robertknight

thanks for your input.

Size - We've recently slimmed down the Hypothesis client considerably and there is still substantial room for improvement. We might look into lazy-loading functionality in future, such as editing and math support, but I still have a strong preference for something small.

How much in size is the current editor?

but I still have a strong preference for something small.

They are already working on a lite version without bootstrap.
summernote/summernote#1756
Its finished, they just haven't merged the pull request yet.

Mobile UX - This will be an area of focus for us after direct linking.
Minimal UI - Related to mobile UX, we have limited horizontal space to play with in the sidebar

Works with Summernote and looks pretty (at least on iOS)

[tilgovi]

Also likely worth looking at the editor Wikimedia developed:
https://github.com/wikimedia/VisualEditor

On Thu, Mar 17, 2016, 01:56 Oliver Sauter [email protected] wrote:

@robertknight https://github.com/robertknight

thanks for your input.

Size - We've recently slimmed down the Hypothesis client considerably and
there is still substantial room for improvement. We might look into
lazy-loading functionality in future, such as editing and math support, but
I still have a strong preference for something small.

How much in size is the current editor?

Mobile UX - This will be an area of focus for us after direct linking.
Minimal UI - Related to mobile UX, we have limited horizontal space to
play with in the sidebar

Works with Summernote and looks pretty (at least on iOS)
[image: img_5367]
https://cloud.githubusercontent.com/assets/7870039/13840868/9aa08ef6-ec25-11e5-9f13-1b532998c716.PNG

but I still have a strong preference for something small.

They are already working on a lite version without bootstrap.
summernote/summernote#1756
summernote/summernote#1756
Its finished, they just haven't merged the pull request yet.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#204 (comment)

[blackforestboi]

@tilgovi

Features:

Woah! This editor has a whole lot of features. Too many to list and maybe even too many for our use cases? https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide

Size:

I havent found any number of the size of the editor. But when downloaded, VE has a size of 2,4mb (summernote: 545kb)
As a rough assumption, I guess that VE is bigger in size than SN or the current editor when implemented.

[robertknight]

How much in size is the current editor?

About 10KB gzipped for the markdown renderer plus the editor implementation.

Its finished, they just haven't merged the pull request yet.

I'm afraid that means there is a big gap between the current state and finished. Finished means that the code has been reviewed, sufficiently tested and released. That's usually a fair amount of work.

I think this discussion is focusing too much on implementation details though. Putting together a minimal working prototype with just the essential WYSIWYG functionality that could be trialed in different contexts might be a useful thing to do. Please be aware though that whilst prototypes are very valuable, there is usually a significant gap between the kind of code that is fine in a prototype and a polished implementation that we could consider shipping to users.

[blackforestboi]

@robertknight

Putting together a minimal working prototype with just the essential WYSIWYG functionality that could be trialed in different contexts might be a useful thing to do.

Ok, I would suggest we leave this one at this point.
We have some other features, that we consider to be important and will gradually comment on overlapping feature requests already listed in your issue tracker.
Then at some point we can come back to this one and start with a first prototype.
Let's see how that works out then. :)

I'm afraid that means there is a big gap between the current state and finished. Finished means that the code has been reviewed, sufficiently tested and released. That's usually a fair amount of work.

Yes sure, careless choice of words. What I essentially wanted to express is that it is not like they have this issue lingering around, but people actually working on it and that it is in the process of being integrated.