Just curious. 
I’m really looking forward to it. I hope it will expand the functionality of the app. I was close to switching to a new app, but I decided to stick with Dynalist.
1 Like
I’m interested in more info on WYSIWYG in Dynalist, but also, especially after reading the blog post and not being convinced it was a great idea, what is the point? I like the editor just as it is.
1 Like
For starters, we’ll try our best to match the same features of current Dynalist but in WYSIWYG mode. That means formatting like bold/italics, strikethrough, etc, plus date/reminder, latex, links and images. We’ll consider expanding functionality once WYSIWYG is stable.
There’s a couple of big issues with the current editor that makes for a poor experience.
- The most complained one is the different length in formatted vs plaintext editing mode, which causes jumping around when focusing on different items. This is especially bad if you use a lot of formatting like links and dates.
- Having to switch between formatted vs non-formatted is a performance hit. If items seen on screen is exactly as they would be for editing, it would reduce the repainting needed (and also the number of elements in memory).
- Markdown isn’t for everyone - some people love it, but a lot of people find it confusing and prefers a “MS Word” like experience.
4 Likes
I think it’s a mistake. But, it’s your product. At least we can migrate to something else before being forced to use a “MS Word experience” for note taking.
If implemented, how WYSIWYG is going to affect every user preferences and their ways of using Dynalist today? Can they still do whatever they do today, with an option to activate WYSIWYG?
Hasn’t been decided, but most likely we’ll continue to support both formats for some time before making a decision. If the overwhelming majority likes the new version then we might consider deprecating the old one in the future. In the worst case if WYSIWYG doesn’t work out at all, we could always just roll it back. There’s also the option of indefinitely supporting both.
We’ll see how it goes. It’s as much an adventure and unknown to us as it is to the end user.
4 Likes
In the beginning I really wished for the WYSIWYG to be implemented in Dynalist. That was one of the reasons why I postponed so much the move from Workflowy, but then I decided to use Dynalist in paralel for a while and, just like magic, I got myself used to the Markdown, which to be honest was something I hated in the beginning.
As I said in one of the posts, now lost somewhere, if once Dynalist could have implemented a simple Padlock, so we could just toggle from normal / rendered mode to Markdown mode, same behavior we have on mobile, that would be great. To me it would be a simple solution, but maybe not everyone would agree with it and, also as already said somewhere on this forum, it’s pretty hard to please everyone.
But in fact, I’m completely used to Markdown now and don’t see anymore the need for the WYSIWYG. It’s amazing and crazy because I was also one of the voters for it on Trello.
Let’s just hope Markdown and WYSIWYG can co-exist in the future, or we can have the choice to toggle between one and the other. Since a refactor might be needed, I’m not so sure about that. What I know is that Dynalist has a great team and support and they will do a hell of a job. Keep up the good work!
2 Likes
A big refactor is overdue anyway. Over the years, Dynalist’s internal code has been through various iterations of guidelines and practices. Web technologies have evolved and we have adapted, but there are still many lines of code that was written back in 2015-2016 that hasn’t been touched.
2 Likes
I’m quite used to Markdown as well, but I’m looking forward to WYSIWYG for the smoothness it it bring to editing. I’ve accepted all the countless manipulations that markdown requires, but I can imagine a great weight lifted once they are no longer required.
1 Like
“MS Word like experience” is a bit of a red flag, since MS Word is full of issues with formatting, and complexity. I assume “WYSIWYG”, a term that peaked in the early 90’s (check Google ngrams), and is not used much anymore, is actually code for “rich text”. So, what kind of rich text would be exported? Word XML (.docx)? RTF/RTFD? Some sort of Dynalist XML?
Rich text is far less portable than Markdown. Far less.
I too am looking forward to WYSIWYG.
I’m indifferent between a “markdown with live syntax highlighting” approach and a more MSWord style rich-text editing experience. Either approach is superior to the current implementation because both would involve live creation of inline DOM nodes which brings with it the potential for all kinds of improvements of user experience (esp. via custom CSS & JS etc) not possible in the current framework.
depends on how WYSIWYG storage is implemented, i’d say. If it is some sort of MS Word XML… i would stay away, but if it is implemented like in Typora (https://www.typora.io/) this would be a welcome improvement. (underlying Markdown with a way to switch between modes)
1 Like