[research] markdown form input

[BenGamma]

The purpose of this thread is to share opinions on this feature and found the best solution available out there to make it.

We want the user to be able to comment using markdown or an editor, like this github comment form, to make the font bold or italic, create points, title, add citations, links.

What I know :

• As an editor we could use react-mde for the editor, wich is based on facebook's draft library.
• to read the markdown we could use react-markdown.

The goal here is to test to implement these solutions in our current code base and see which one fits the best for our needs 💯

[chrismclarke]

ah cool, I had mentioned this in #209 but see it's covered here. Given the fairly general target audience I agree the most important thing is a simple set of buttons users can use instead of writing code.

I just took a look at react-mde and it says the repo is undergoing breaking changes. I imagine draft receives much better support and is more stable, so unless we have specific reason to prefer markdown over html (assuming the user won't be writing code in either case) then I would suggest just go for draft.

[BenGamma]

@tx4x markdown would be nice yes. Do you have any recommandations on a markdown library we could use ? Cherries on the cake would be a working example component 😍

[BenGamma]

React Draft Wysiwyg sound like a strong candidate. Thanks for sharing 🖖

[BenGamma]

Yes we'll probably need some custom integration at some point, thanks for asking 👍

For now what would be nice to have is a working example of React Draft Wysiwyg integrated in the project. If you want to go further I suggest you create a branch from master and from there create a working example on a new url (for example if I visit /discussions/post/<slug>, the editor is displayed and we can console.log the submited data)

[chrismclarke]

I personally much prefer writing things in in markdown, so if we expect people to be writing in a code format it makes a lot more sense (anyone who prefers html can still write it in markdown).

I think most users will be looking at using premade buttons however so I the number one priority has to be an editor that a) is easy to customise and b) integrates well with react.

Point a) might seem moot as at this stage pretty much all editors give you control over which buttons can be seen or hidden, however I'm thinking more ability to add custom buttons and bind to events (e.g. when the user drag/drops on to the editor). Not that we would want to do too much initially, but I think it makes sense to keep options for the future if we wanted to integrate custom web-components or functions on the rest of our db/services.

Point b) is probably less of an issue as building a wrapper really isn't a huge deal (easy enough to query the dom element and get the value from it if not already bound to the state), however if we can avoid doing this I'd definitely be in favour.

Draft looks like it should do what we want. Another I'm using a lot at the moment is quill, however by their own admission the only real benefits are for people not using react (https://quilljs.com/guides/comparison-with-other-rich-text-editors/). I particularly like that it stores info in json format to convert to either html or markdown (everyone's a winner!)

I'd be really interested to hear what features you think we need in the editor @tx4x

[chrismclarke]

Good point about referencing quoting other messages, I hadn't thought about that... There will also be things like @mentions to think about. We will need to talk with @mattia-io to better decide how we want the users to interact before taking the dev too far (e.g. would messages all be displayed in a list, nested chats, seperate threads, quotes etc.)... I'm assuming the answer will vary for our different use cases.

For the first implementation I think the backend is mostly just a set of fields within the database (firestore) entry. We would later want to build apis on top of this, cloud functions already has the functionality to observe database changes (e.g. new comment added with fields x,y,z), and then we could look into building various microservices like email/push notifications etc. I think we're currently planning to implement Algolia for search.

Dream on. Anything is possible.

[thisismattia]

Hey everyone, thanks for all the inputs. It's now officially in my list to be discussed with Dave and UX. Will update soon on this.

@chrismclarke in regards to user interaction we have 3 posting types:

How-to: Author posts the How-To with all the different steps (no comments on individual steps). Users and the author can comment below the How-To and nested reply to comments.

Discussion Author posts the topic/discussion. Users and the author can comment back and forth and nested reply to comments.

Q&A Author posts the question. Users can comment their answers below (author cannot post answers). Users and author can nested reply to comment. Author can choose an answer to be the correct one.

Hope this clarifies it a bit. Let me know if still unclear.

[chrismclarke]

Awesome, Crystal (ish). Brief follow-up:

1. How many of these places do we want people to be able to edit their original comment? All? If so would we want to mark with the word 'edited' or keep track of the old comment also?
2. In terms of sorting do is chronological by sufficient, or would you also want to be able to swap between most commented/replied, most recently updated etc? (none of these too difficult as long as we have the data structured correctly to begin with)
3. Once the Q&A author has marked a correct/useful response should the thread be locked? (but maybe still allow for direct response to the chose solution?)

[thisismattia]

Hey yo,

1. Added to my query list for UX
2. Chronological / Most Useful / Most replies
3. Added to my query list for UX. *The thread should be treated as answered when the author picks one answer

Peace 👀

[chrismclarke]

• It will definitely want to be its own standalone component to be implemented across at least 3 or 4 different places (ideally want to remain fairly flexible).

• Custom tags could come through without any extra work if we build the custom components as webcomponents, otherwise yes I'd expect either to work with their existing extension system (haven't tried myself), or take a fork (less preferred but still possibility). Will be interested to see how showdown gets on

• My initial thought would be that at the database level we would have very minimal nesting, most comments would sit as siblings with a single 'parent' or 'repliesTo' field to reference parent conversation if it is a response. A nested structure would be built once imported (so every comment could have a 'children' or 'replies' field which would hold more comments), and we would have _created and _modified properties which could be used to sort by date

Good luck with the implementation and thanks!

[chrismclarke]

Could you explain a bit more what you mean by the experience sucks so we can know what your thoughts expectations are, and help decide also what the mvp for the community should include (separate out 'must haves' and 'nice-to-haves'). From the screenshot it looks like a pretty standard editor...

[chrismclarke]

Really useful, thanks a lot! @mattia-io , you might also want to take a look and add your input.

From my side I would have the following points:

1. Agree standard text editor, would suggest not custom fonts as we'd rather keep things looking more uniform and not have the extra font-loading overheads.
2. I hadn't thought about tables but could see how they would be useful for research data so would think worth keeping
3. Images I would also suggest youtube embeds. I would strongly suggest no fancy editing or resizing for images though, we don't want to have to rely on users to make sure an image doesn't take up the whole screen. Instead we would have specific dimensions on all images (probably reasonably small with ability to view full on click). You have extra problem when trying to resize images because essentially you need to send the image to the database alongside styles objects (or all as inline html, markdown would struggle here), and then you can get new dom sanitization issues as you try to inject it back into the javascript template (fine on static server-rendered content, browsers less consistent on dynamic).
4. Links - as in hrefs? if so agree and imagine comes pretty standard. Bespoke links to things like other comments and automatic snippets might be tricker.
5. Mentions - think it would be a really nice-to-have, but I don't think I would push it as high up the priority list (people can still write thanks @whoever and people will get the gist, it only becomes of benefit when we have a decent notification system to let you know when you've got mentions etc., and even then you will likely still be happy with updates on the entire feed (like any thread on github))
6. Tags - I think this is a 'must-have' but it wouldn't necessarily be required to be part of the editor. In fact it might be better if kept outside and reuse code from other content creation pages.
7. Source/HTML - I'd be in favour of and 'advanced' editing mode, although I don't think this would have to be a priority as most editors still would allow you to copy/paste from your favourite external editor. Not as streamlined granted, but equally why bother trying to replicate the best parts of everyones' favourite editors when people can still just use them right?

[thisismattia]

Hey all,

@tx4x big up on all the research and summary, helps a lot 👍

First of all I'd like to maybe clarify in which instances the text editor would be used:

1. User upload content (how-to, discussion, Q&A, events etc..)
2. User comments (newsfeed, how-to, discussion, Q&A, events )
3. Admin posts content (main news)
4. Can't think of any other instance, but maybe you guys have more scenarios in mind where it could be needed?

Commenting on the table @tx4x nicely created my feedback pretty much agrees with @chrismclarke in all comments. Few addition:

2. Not sure how much work this is but is def a nice-to-have feature
3. Didn't get this 😇

Nice one, let me know if you need more inputs from me.

[chrismclarke]

7. Most editors are simply visual interface for the code below (sometimes html, sometimes markdown, sometimes something else). The buttons in a toolbar execute little snippets of code (like formatting a header), and are there so users don't have to manually type in all the

   , ## etc. tags.

Even if there aren't buttons most editors will recognise any html/markdown typed in them directly (hence the giant text above), so for the most part whatever editor you are typing into you could always just use another and copy/paste the result if it doesn't give quick access to all the features you want.

This no longer applies if you're trying to do things outside of basic text blocks like images, mentions etc. so these are the things you ideally want to make sure you get right in your own editor. Although in the case of images (cropping, resizing, filters etc.) people can always of course do the heavy lifting outside too and just bring the final product in. I imagine people will always want all options, but would be pretty quick to adapt to whatever subset we offer.

[chrismclarke]

Sounds like a plan, will be interest to see what TinyMCE can offer (took a look at ck editor and their pricing is insane!). I see they have a wrapper for react already too: https://www.tiny.cloud/docs/integrations/react/

The api endpoints shouldn't be too difficult, will be happy to help with them once we have the core in place (probably makes sense to initially work with some mock data to see what type of format is easiest to work with).

Agreed on the title and searching, but all that is independent of the editor. As mentioned above in this thread we plan to use algolia which will have good ways to handle this.

[chrismclarke]

also keep the code for draft so we can keep a comparison of the two. I definitely would be too quick to discount it, it's still a popular library: [edit, figures wouldn't take into account people just using hosted solutions, so should read more popular for people that want to create their own editor] https://www.npmtrends.com/draft-js-vs-react-tinymce-vs-tinymce-vs-tinymce-react https://js.libhunt.com/compare-tinymce-vs-draft-js Remember that the editor itself should be the easy part, the potentially more challenging will be adding the customisations we want, which could swing things either way.

[chrismclarke]

thanks for the update. Assuming we get this in this week I think we can start some user testing at the workspace on Friday and pass any feedback along following. Most of the users here are unlikely to care as much about the advanced editing, but may have some useful comments more generally.

[chrismclarke]

I think this has been a really good conversation, tinymce is now integrated and working well so will close

[thisismattia]

Nice one. Thank you @tx4x 👊

[davehakkens]

i dont think we are ready to implement markdown or rich editors. yet. It's easy to implement but hard to implement properly. Opens up to many possibilities and options to mess up the layout and create a mess. Needs more thinking.

[chrismclarke]

I really like markdown and am much more efficient with it, although at this stage I don't think it would have much use as we are literally only using plain text inputs + image uploads in the platform to keep a very consistent style for all posts. The academy site is all markdown though.