Visual editing (WYSIWYG)

[Luke]

Lots of advantages, but here are some highlights:

• Makes it easy to write with hands always on keys.
• Biggest advantage: makes data usable later and outside of Dynalist. If Dynalist are flat files in markdown, the company can shut their doors tomorrow, and I still have usable plain text files with useful links, formatting, etc.
• If I need to export to .pdf, .docx, .epub, medium, and many others, Markdown makes it possible to do that (through too many services to mention here.)
• if I find a service I like better than Dynalist, copy/paste Markdown plain text, and im good to go.

[Vincent_Tang]

@Abram_Demski

What is good about Markdown?

Markdown was designed in place of traditional formatting (bolding italics, etc) because it offers a quick way to see exactly what you get based on what formatting you put into it. It also can be used in a traditional txt file

Where as microsoft word has to be processed in a .docx file type, and transferring over formatting to other programs is not consistent

Basically, if you want some way of making consistent formatting across many platforms (reddit, dynalist, markdown blog posting, github files) , markdown is the most accepted way of doing so

[Erica]

@Vincent_Tang @Luke

Oh man, all good points. Maybe we shouldn’t do WYSIWYG after all.

(Or maybe provide a way to export to Markdown as accurately as possible?)

[Luke]

Erica, I understand that this is a difficult tension to handle. But you don’t necessarily have to choose between Markdown or wysiwyg:

DayOne app, Ulysses app, Bear app, typora.io, and others have devised creative solutions for combining the benefits of Markdown with the readability of wysiwyg.

I think the pain point right now with Dynalist is that the neat, tidy look of a bullet abruptly changes when inserting the cursor (particularly with internal and external links.) Adopting one of the link behaviors from either Typora or Ulysses, for example, would likely solve this issue for most users.

[Luke]

Ideally:

• support a writer who is typing away in Markdown
• support a novice user by also providing context menus for formatting and links
• and for both users, Dynalist would be backing up plain text Markdown files to Dropbox, etc.

[Abram_Demski]

@Luke

Makes it easy to write with hands always on keys.

@Luke

support a writer who is typing away in Markdown
support a novice user by also providing context menus for formatting and links

Hm. Doesn’t a user who is typing away tend to use shortcuts anyway, which can either insert the markdown or change the formatting WYSIWYG-style?

@Luke

and for both users, Dynalist would be backing up plain text Markdown files to Dropbox, etc.

@Vincent_Tang

Basically, if you want some way of making consistent formatting across many platforms (reddit, dynalist, markdown blog posting, github files) , markdown is the most accepted way of doing so

I’m confused. Dynalist uses double marks, such as the double underscore and double asterisk, where other markdowns use singe marks or other conventions which mix single and double. Does this not cause trouble when trying to copy-paste from Dynalist to Reddit?

I totally believe that you two have reasons for preferring Markdown, I’m just not understanding what they are yet.

[butlermatt]

@Abram_Demski

Hm. Doesn’t a user who is typing away tend to use shortcuts anyway, which can either insert the markdown or change the formatting WYSIWYG-style?

Dynalist isn’t a word processor. Nor do I think it should be. While short cut keys are acceptable for a few specific common functions like bold or italics I don’t know that, along with all the other shortcuts currently implemented, they should even try to create full shortcut mappings for every formatting option possible.

@Abram_Demski

Basically, if you want some way of making consistent formatting across many platforms (reddit, dynalist, markdown blog posting, github files) , markdown is the most accepted way of doing so

Ironic that you should mention those 4 markdown implementations, as not one of them implements markdown in the same way. Fact is, between extensions and no true markdown specification (only what the creator feels is a cannon implementation), there is no full agreement on the syntax. So every implementation has its own quirks and differences. See CommonMark for information on why they chose to try and create their own derivative.

[Vincent_Tang]

@Abram_Demski

I totally believe that you two have reasons for preferring Markdown, I’m just not understanding what they are yet.

Probably the best example of using markdown to use dynalist to brainstorm a topic (outlining), and then push it into whatever platform you want that supports markdown format

This way you can write summary reports quicker, blog posts, write a fiction novel, make a technical manual quicker, while still using dynalist is your main ecosystem.

@butlermatt

Ironic that you should mention those 4 markdown implementations, as not one of them implements markdown in the same way. Fact is, between extensions and no true markdown specification (only what the creator feels is a cannon implementation), there is no full agreement on the syntax. So every implementation has its own quirks and differences. See CommonMark for information on why they chose to try and create their own derivative.

While this is correct, there are common syntaxes between most markdown deriviatives. Bold is almost always ** bold ** , italics are almost always * italics *. In any case, it doesn’t matter which variant you use (I like github or reddits version), since you can run it in http://pandoc.org/.

[Erica]

@butlermatt

Ironic that you should mention those 4 markdown implementations, as not one of them implements markdown in the same way. Fact is, between extensions and no true markdown specification (only what the creator feels is a cannon implementation), there is no full agreement on the syntax. So every implementation has its own quirks and differences. See CommonMark for information on why they chose to try and create their own derivative.

Yeah, that’s why we have mixed feelings about Markdown. It’s nice for the writers, but not nice for the programmers. It’s not a strict markdown language and it’s more human friendly than machine friendly, at least that’s how we feel about it

@Luke

I think the pain point right now with Dynalist is that the neat, tidy look of a bullet abruptly changes when inserting the cursor (particularly with internal and external links.) Adopting one of the link behaviors from either Typora or Ulysses, for example, would likely solve this issue for most users.

Ulysses and Typora do no need to support custom objects like dates and internal links, it’s way easier for them to implement.

We prefer the Typora way. “The neat, tidy look of a bullet abruptly changes when inserting the cursor” This is true for Typora also, we’ve tried our best to position the cursor as the right spot as you see it, it used to be the same fixed position but wrong relative position (the cursor lands at where you click, but far away from where the character that you intended to click on).

[Craig_Oliver]

@Abram_Demski

What is good about Markdown? Keeping the option of markdown for those who want it would probably be good, but, I lack an understanding of why someone might want it.

Hi Abram,

Thanks for your note. My main reason for loving Markdown is that it is an excellent way to organize and format text documents. As a software developer, I do a lot of work in GitHub, Visual Studio Online, and other collaboration platforms. The teams I work with use Markdown as our common text format for documentation, instructions, reference, and even online discourse such as this forum. Because it’s plain text, it’s easy for both humans and computers to work with. It can be read by humans without special software, imported and transformed by computers, and easily version-controlled.

I also use Markdown in my personal note-taking, because it allows me to focus on the content of the text (e.g. headings, tables, and emphasis) without getting distracted by the appearance of the text (font family, size, margins, etc.). In graphical text editors such as Word, I sometimes get distracted by trying to make a document look perfect instead of finishing the content. Using Markdown helps me to focus instead on what needs to be communicated and leave the formatting to the many excellent tools available.

I don’t just write in Markdown, I think in it.

I love Dynalist because it not only gives me powerful tools for organizing my thoughts into a hierarchy, but also supports the formatting I use every day. I use Dynalist to organize my to-do lists, plan projects, draft documentation, compose messages, write prose, and a dozen other things – all using Markdown. And the best part is, when I need to export out these documents to GitHub, VSOL, Discourse, etc., it’s already in the format the target system wants, no conversion required.

So these are a few of the reasons I love Markdown. As you might guess, Dynalist’s support of Markdown is one of its most important features for me, and I’d be very sad to see it dropped.

[Daryl_Mander]

So many replies in this thread, did not have time to read all so apols if this has been covered. When WYSIWYG editing is implementeed, will this also cover the issue where clicking into a line makes the links / tags no longer clickable?

Sometimes my cursor is inside a line and I want to click the tag or link in that link… currently I can’t. Is this issue going to be fixed as part of this WYSIWYG update or is this a separate feature request?

[Alex_Pasternak]

@Daryl_Mander, DL’s management of URLs in notes is one of my top pain points vs. Workflowy. I’ve suggested by email (before I was aware of this forum) an improvement to show a launch icon next to URL, to allow best of both worlds for inline editing and launch. This reminds me I should open up a separate thread on that in Improvements area; will try to do this soon.

[Chancy_Kennedy]

Great points, @Craig_Oliver !

I think Markdown also encourages adopters that are familiar with Markdown, and feel like their notes aren’t lost to another proprietary system if they have the safety net of exporting everything as Markdown.

Others have mentioned Typora and Bear. Maybe a source mode, similar to Typora’s Source Code mode, that has predictable cursor behavior by keeping the markup in place and applying the styling once valid? And then a separate presentation mode for users that aren’t interested in Markdown syntax, with a medium-like menu.

Honestly, I think it may just be the psychology that Markdown is a simple, portable, human-readable format, more than wanting those shortcuts. It seems related to the growth of JSON over XML, even though JSON is lacking tons of features as a serialization format that are now being bolted on as JSON schema and such, it got mass adoption as a readable and comprehensible format that has a limited set of rules. It’s a gradual increase of complexity from visually organizing a simple text file with notes that are related as hierarchical bullets, to introducting a little more syntax for document linking, checkboxes, tags, etc., that have special and non-portable features attached to them.

It’s the convolusion of a set of community accepted behaviors that eventually trickle down to people that don’t care about syntax, but it’s so simple and distilled that the utility is obvious. Like “hash tagging,” that was possibly cemented for the general public by Twitter’s adoption? Now it’s used in Slack and Dynalist, and the syntax doesn’t create friction for general users since they’re already familiar.

[Joel]

@Pawel_Rugala

I don’t like that text is changing once I edit the node I really prefer that * stars or __ will be constantly visible but with font color light grey. That’s tiny visible.

This seems something like Whatsapp formatting which I really don’t mind.

@Craig_Oliver

For what it’s worth, I love the app’s current support for Markdown. It’s one of the features that drew me to the product.

This is quite true for me also. I love the idea of Markdown text but at the same time I hate when editing text and everything becomes jumbled all over in plain text.

I do like both ideas posted above, one being that the rendered and edited text show the Markdown in light grey, while keeping the formatting of the text…and I also like the idea where the user can pick a default (WYSIWYG or Markdown) and switch between modes.

[Mark_Arness]

The main reason I’d prefer WYSIWYG is because I like my formatting to remain persistent when clicking through things, not switch from THIS to * * THIS * * when I select it, in particular if I have code snippets I want to copy out and paste into a command line. Just personal preference I guess.

[Dmitry3]

Here are some pain points mentioned:

• some people prefer Markdown, some people prefer WYSIWYG; the ideal solution is the one that combines both
• converting between Markdown and WYSIWYG is highly nontrivial
• Markdown is underspecified
• WYSIWYG is also very nontrivial (ContentEditable is a massive PITA)
• even with WYSIWYG the text must be stored in some form

There is a way to have them sorted: ProseMirror

• it is a react/flux-inspired (that is, it separates state, updates it with incoming events and updates the representation) WYSIWYG over a structured text
• it comes from an author of CodeMirror
• that “structured text” is in fact just a collection of plain JS objects that is trivially encodeable in JSON and amenable to JSON schema
• text is 100% specified by the state schema
• one can have a schema that is renderable both as Markdown and as WYSIWYG, here is a demo
• it has a very clear concurrency model/collaborative editing (because those “events” can be treated as “deltas”, transmitted over the network and applied independently)

It has some downsides:

• it’s more complicated than other drop-in replacements (it’s more of a framework for editors than a ready-made editor)
• it may be too expensive to have it on every line of the tree or enable it on click/focus

[Erica]

Thanks for the clear summary, and thanks for the pointer to ProseMirror. @Shida, could you please take a look?

Here are my thoughts:

@Dmitry3

it has a very clear concurrency model/collaborative editing (because those “events” can be treated as “deltas”, transmitted over the network and applied independently)

This and other ProseMirror features are nice. We still need to do the work for incorporating them though, which is not the fault of ProseMirror, but because of all the existing work we have done.

For example, we have done the entire “concurrency model/collaborative editing (because those “events” can be treated as “deltas”, transmitted over the network and applied independently)” part and now if ProseMirror also has that, we’ll need to somehow reconcile the two.

@Dmitry3

it’s more complicated than other drop-in replacements (it’s more of a framework for editors than a ready-made editor)

This doesn’t really make a big differnet, thankfully. Given the huge size of this project, this part is insignificant, as long as it works well in the long term.

@Dmitry3

it may be too expensive to have it on every line of the tree or enable it on click/focus

This is the real concern. With native ContentEditable people are already complaining about how long it gets (they have really huge documents), I can’t imagine how it would be like if everyline is a ProseMirror instance.

Have you worked with ProseMirror? Do you know if it’s possible to only activate one instance at a time, and leave others as non-editable elements until clicked? That might mean a ton of extra work…

[Ellena]

OMG I’m have PTSD from work with this thread! (HTML/Markdown to WYSIWYG system is not a small task)

My personal use case is I like markdown in theory - it translates well between softwares and is simple enough for a luddite like me to write quickly - but hate the jumpey experience. So I’m all for this.

My two caveats are:

1. I need to be able to export to markdown or copy text in markdown/html - like caret does for html and rich text (its a markdown editor)
   

2. Please keep it accessible - I’m enjoying dynalist a lot because it is pretty good about keyboard accessibility. Solutions like the pop-over on highlight for editing controls are hellish.

[Chancy_Kennedy]

SlateJS might be another option to consider as a contenteditable replacement. It’s quite flexible with a conceptually minimal design, and is supposedly designed with collaborative editing in mind. I’m only superficially familiar though.

[Schultzter]

@Erica

Our current plan is to not use Markdown at all

What?! For those of us who can touch type Markdown is the best thing ever!!!

WYSIWYG only works if every formatting option has a keyboard short-cut. And those keyboard short-cuts follow a standard - except there is no standard!!! If I have to remember which short-cuts go with which app then I’m just going to be reaching for the mouse every time I need to format something. So either I won’t format as much or using Dynalist will become inefficient and cumbersome.

I’ve lost count how many times I’ve bookmarked a Gmail instead of deleting it because I Just came from Outlook (where Ctrl-D is delete, but in Chrome Ctrl-D is bookmark).

PLEASE keep Markdown!