Visual editing (WYSIWYG)

🌟Features
#118

Indeed, totally - although there are several efforts to try and refine and resolve that somewhat. But that’s kind of what I mean - other people have already dealt with this (to at least a large extent) so using a third party Markdown parser/renderer both takes the load off in terms of working out how to deal with mismatched or intermingled asterisks and underscores and things like that, and simultaneously potentially provides supports for tables and code-snippet syntax-highlighting and a bunch of other text-feature stuff at the same time.

No worries - as I have been working through the forums I am massively impressed by the community support, and the responsiveness and attentiveness. Hence the motivation to take the time and give input here and there. [EDIT: Although I confess to not looking at the posting dates!]

#119

Just to add to what @Erica said. We must implement our own Markdown parser/renderer for a couple of reasons:

  • Dynalist has our own flavor of Markdown, to support things like Date/Reminders, LaTeX, etc.
  • Dynalist ONLY supports inline Markdown, and does not support any document level (things like making a markdown bullet list, paragraphs, etc). So those won’t be necessary (and also must be disabled).
  • Each Dynalist item has its own editing box, and each “note” has its own editing box as well. For performance reasons, we can’t really turn every editing box into a 3rd party markdown editor, because that would end up with potentially thousands of instances. Dynalist with our feature-rich formats is already taking a toll on performance compared to competing products, and this would make the problem even worse.
  • There are many many things that will need interfacing with a 3rd party editor system, that we need to take over and write ourselves anyway. This would almost defeat the purpose of using one.
    • Undo/Redo across the whole document, not just within an item’s editor box.
    • Saving selection positions (for example, if you “Undo”, we’ll put your cursor at the position that was undone).
    • Implementing custom boxes with custom behavior would be a big pain (date/reminders, LaTeX, etc).
    • Debugging 3rd party code, tweaking the internals for our purposes, and end up having to maintain it ourselves anyway.
3 Likes
#120

To me the argument for markdown is more about portability of my data, and less about the editing experience. What I don’t like about a pure WYSIWYG editor is it makes it much easier to add data to my lists that will be harder to export, or be interpreted by other software. As other’s have mentioned there are a ton of tools for converting markdown into other formats. Even if Dynalist uses some custom Markdown formatting for not standard elements like dates, they are still human readable text that could easily be modify later with basic find/replace/regex tools.

Also, with markdown it’s also easy to see exactly what information is included, and well as not included. I hate exporting from one software file format to another, and never being 100% sure if all my data was move from one format to the other.

3 Likes
#121

today is 2020-02-01, will this feature release soon?:grin:

1 Like
#122

I very much worry about the release of this feature. I hope it will be purely optional, allowing those of us who prefer to stick with plain-text and Markdown, to be able to do so indefinitely.

I have seen many pieces of software destroyed by the introduction of supposedly “advanced features” that were not strictly necessary. A huge chunk of developer resources went that way, with little profit eventually.

I hope this will not happen to Dynalist.

3 Likes
#123

Yes so for those wondering about how this is going - It’s still in the pipeline but we anticipate it’s going to take a long time before it’s production ready.

To address the concerns people have, it will be optional, and perhaps enabled by default for new users. Our current plan is to store the data in markdown format as it is right now, and the WYSIWYG editor is a pure augmentation that works on top of the markdown format.

In terms of development cycle, we developed a separate proof-of-concept to test the waters with current browser technology and it’s mostly working. The difficulty right now lies mostly on merging that into current Dynalist, all without interfering with the regular editor mode that we currently have. The other big project that affects development is a big code cleanup of the editor (which was mostly developed around 2015-2016). Given our current experience with Dynalist, there are many previous design decisions that we think could use some improvement and rethinking. This will give our new WYSIWYG editor a better base to work on, which means we won’t need to write hacky code to make it work, less chance of bugs, and easier to maintain in the future.

We’re doing this slowly and cautiously, given that we’ve seen some examples of how NOT to do WYSIWYG (see Slack). We’re also still spending a significant amount of time improving Dynalist in other ways: fixing bugs and developing other highly requested functionality unrelated to WYSIWYG. This is more of a long term project that we primarily see as making Dynalist more friendly to users (especially new users) who are less familiar with Markdown.

9 Likes
Board view (like uchhh) Workflowy
Double-Click to Edit
#124

To add to Shida’s reply, here are some things we’ve been up to in parallel with WYSIWYG: https://blog.dynalist.io/2020-january-update/

3 Likes
#125

“To address the concerns people have, it will be optional, and perhaps enabled by default for new users. Our current plan is to store the data in markdown format as it is right now, and the WYSIWYG editor is a pure augmentation that works on top of the markdown format.”

Sigh if relief

Although I expected as much. It’s nice to hear you say it.

3 Likes
#126

Thanks for the clarification. I see that this is a huge undertaking and I think it’s wise to implement this slowly step by step and don’t rush things.

One thing I want to ask if “a long time” means months or a year? Can we look forward to this feature in 2020 or will it take longer?

Ty!

#127

I really hope so, but I can’t really commit to any specific times because of constant changing priorities. We’ll try to include any relevant progress updates in our monthly blog post so you guys can have an idea how it’s going.

5 Likes
#128

Alright, thank you for the info!

#129

@Erica and @Shida

Have you guys done any hardcore scientific surveying—specifically of pro users about this specific issue? More specifically, have you asked pro users—who’ve been pro users for lets say… more than 3 months—whether they want:

  • Wysiwyg
  • Markdown, or…
  • Markdown that’s rendered as wysiwyg?

I’m asking just because I’m a internet marketer, and I’m curious. (Very.)

My theory is, the majority of pro users who’ve been pro users, want wysiwyg. I’ve always wanted to know whether I was right or wrong on this point. Lol, and it’s not even my app!

Why is that my theory? It’s my theory because I think that the majority of dynalist pro users are “normal text” people. People who—when trying to make text bold—like seeing the text they’re trying to make bold… actually become bold. And don’t necessarily like seeing asterisks appear instead, nor understand why those asterisks appear instead of bold text—when they do appear.

Note: Like I said, this is what I THINK! I could be wrong. Just curious is all. (Very.)
Note 2: No offense meant by “normal text” people to anyone who likes markdown.

1 Like
#130

Hmm honestly we never did! I’m convinced a lot of people would appreciate it, and a lot of people can benefit from it. In either case though, having the option to turn on or off wysiwyg is still the best option.

Just a quick update on the matter: I think we will be able to get a demo done by end of april. There might still be things not working but I feel like it should be mostly working by then.

10 Likes
#131

In this case this is technologically an advanced feature but is to users a very elementary feature likely one that’s a stay/leave decider for a lot of potential users who visit DynaList and quickly move on. Having WYSIWYG will I assume quickly result in more people picking up the tool.

4 Likes
#132

Me too! I can’t wait for it. Ever since you announced it, I’ve been all giddy.

3 Likes
#133

I agree. It is a very smart decision of the team to implement WYSIWYG. This is nowadays considered as a standard in web applications.

It will make Dynalist more attractive non-tech people because believe it or not markdown syntax is hurdle for people without much technical expertise and at the moment I have the feeling that Dynalist Users are quite “tekki”.

Maybe Dynalist will crack 2k pro users with the new feature.

2 Likes
#134

@Shida @Erica When will this “big project” be released? I am so sick of the jumping of the format.
image
but during navigation
image
now if i want prevent the format jumping, I have to toggle the lock and access the last bullet, like below:
image
image
If the WYSIWYG cant be done soon, is it possbile to provide a feature that no format jumping in the lock mode? Thank you very much.

3 Likes
#135

I would say WYSIWYG still has some way to go but in the meantime, you could switch your font to Consolas for monospaced editor font.

1 Like
#136

Still on track for the end of April?

1 Like
#137

We’ll provide an official update in a few days, but right now it doesn’t seem like we’ll make it that quickly.

2 Likes