arimah
commented
4 years ago Hello again! :D
I want to start by apologising for never replying to your last email. Real life distractions got in the way and then enough time had elapsed that I felt too embarrassed to reply. It's good to hear from you again!
Secondly, I really appreciate you taking the time to write a comment to offer some of your thoughts. It really does inspire me to pick this back up and power through the less fun bits, so thank you for that.
Now, for the meat of your comment!
Can't say I've tried out many rich text editor libraries, there's a decent list of them here but I'm assuming you've seen most of those already.
Ah, a new list of editors! I've looked into and tried out many of these, and many others, and so far the only viable candidate for me is Slate. The main challenge I see with many editors is that they tend to be entirely too inflexible, or flexible only within certain well-defined boundaries. Some things I've run into:
- Many come with their own toolbars, and it's often difficult or impossible to customise the appearance.
- Sometimes it's downright impossible to select which features to include. Maybe I don't want image uploads, or floating toolbars that appear when you select text.
- Customising markup rendering is often a pain, or flat out impossible.
- Accessibility tends not to be great. Often no thought given to screen readers, keyboard interactivity is bad, and the like.
- Fat CSS files. This isn't inherently an issue, but Condict uses styled-components and doesn't (currently) have a CSS build system.
- No way to get the document as anything other than HTML/raw DOM nodes. Condict's markup format is (by design) stored in an implementation-neutral JSON format; converting back and forth is not fun.
Slate suffers from almost none of these issues, but is very much still in some form of beta, and has numerous small bugs around editing. Corrupt undo stacks, strange cursor movement, occasionally unpredictable typing behaviour, etc. Development of Slate seems to have slowed to a crawl, too. I've yet to find a working solution here. Writing my own rich-text editor is beyond the scope of things I want to do, considering how complex all the popular packages are. This brings me your next point:
Just out of curiosity, have you considered allowing users to use something like Markdown instead of a WYSIWYG editor? Sure it might not be as intuitive, but at least as a temporary solution it might make things easier from a frontend perspective.
I have indeed considered the possibility, even, as you suggest, as a temporary measure to get something out the door, so to speak. The main challenge I see there is with designing something that supports all the features I envision while still being straightforward enough that the average user doesn't start cursing too loudly.
Markdown specifically, I'm not entirely sold on. In my opinion, it has too many weird corner cases and not enough space for extensions. As a programmer I'm used to its quirks, but Condict is aimed at the vast number of non-technical conlangers that are out there.
For other syntaxes, I'm sure one can find or invent something that supports what I'd consider a reasonable minimum: bold, italic, underline, strikethrough, subscript, superscript, lists, headings, block-level indentation, and links. Here's a visual example (from my private testing of Slate) of the sort of formatting I want to support:
... and that brings me to links. I really, really don't want to force users to write links to condict://definition/123 or condict://lemma/456 or condict://language/3. A dialog that creates links is totally possible, and will be implemented either way, but the more I can hide these low-level details, the better. It's so easy to accidentally delete too much text and break your link. A bare ID says nothing, but it's the only stable entity reference there is.
This comment is getting long and I've spent most of it rambling about rich-text editors. But it's one of the most important parts of Condict, as it's where most user data will end up. The more streamlined that aspect can get, the better, in my opinion.
This is one of the biggest struggles in developing this app. Any ideas, suggestions, thoughts, tech demos and even just words of encouragement are welcome.
There is a newer library I've heard of called neutralino that claims to solve a lot of the memory issues of electron (although I've never used it so I don't know the pros and cons).
I briefly looked into Neutralino, and though it might solve some of my problems, it seems a little bit too simplistic for my needs. Plus, the lack of Node.js unfortunately makes it totally unusable with what I have so far. I have dependencies on a few packages with native bindings ā most notably for SQLite, without which Condict would have nowhere to store its data. The entire backend relies on Node.
Unfortunately, I think nowadays it's hard to get away from libraries like electron for cross platform apps. The only alternatives I know of are something like JavaFX (which looks terrible imo) or Qt (which is kind of a nightmare).
Agreed. Electron is the least bad-smelling apple in this particular basket of mouldy fruit.
Honestly, I think the best thing about this project is how well designed the backend is. I would personally be fine with a much simpler/less fancy frontend because it seems like the only alternative right now is SIL flex (which is windows only, and isn't exactly polished).
Thank you. š I appreciate your kind words and the interest you show. It's strange to have someone be interested in my work, but not unwelcome!
I, too, would like to release something relatively simple, slimmed down at first, and polish later. Perhaps I should put some energy into making the codebase contributor-friendly, so I can collaborate more with wonderful community members such as yourself.
zsilver1
So I just wanted to weigh in on some of the questions you mentioned in the README, cause I think this project is awesome and has insane potential.
Can't say I've tried out many rich text editor libraries, there's a decent list of them here but I'm assuming you've seen most of those already. Just out of curiosity, have you considered allowing users to use something like Markdown instead of a WYSIWYG editor? Sure it might not be as intuitive, but at least as a temporary solution it might make things easier from a frontend perspective.
There is a newer library I've heard of called neutralino that claims to solve a lot of the memory issues of electron (although I've never used it so I don't know the pros and cons). Unfortunately, I think nowadays it's hard to get away from libraries like electron for cross platform apps. The only alternatives I know of are something like JavaFX (which looks terrible imo) or Qt (which is kind of a nightmare).
Honestly, I think the best thing about this project is how well designed the backend is. I would personally be fine with a much simpler/less fancy frontend because it seems like the only alternative right now is SIL flex (which is windows only, and isn't exactly polished).