Visual editing (WYSIWYG)


#73

We don’t have a public due-date for this, and it’s not being worked on at the moment, unfortunately. Our time is spent on improving mobile and capturing right now. Stay tuned for this in the future! :slight_smile:


#74

Hi,

I would also to express my remarks :slight_smile:
I really would like to have something similar to Bear (mac) or at least like typora.
If You will do it that will be awesome (from my perspective :slight_smile: )

Currently for me it’s a bit annoying if I select node and I see something like /some text instead /** some text ** -> of course w/o /
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.

So to summarise:
node edited -> ** some text ** instead of ** asdasdn**
node view only -> same as above so ** some text ** instead of some text

And this will apply only for
bold ** some text **
Italics _ some text _
code some text `
H1 = or whatever different char
H2 ==
H3 ===

Rest will remain as it is now.

@Erica, You would like to do it similar to what I describe ?


#75

Our current plan is to not use Markdown at all and use all WYSIWYG. I think the pattern you described is pretty new (Bear & Typora) but not traditional WYSIWYG. WYSIWYG is more like Word or Google Docs.

I hope that makes sense!


#76

Bummed to hear this! Markdown is great when implemented Ulysses style! One of my main drivers for switching from workflowy to dynalist was the markdown support.

The best software has some degree of learning curve!

Mediocre software just makes an icon for everything (I’m looking at you, MS Word and Google.)


#78

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.


#79

Thanks for the input @Luke @Craig_Oliver! We’ll make sure to factor that in.


#80

Switching between rendered mode and plain text is annoying. Any updates?


#81

Sorry, no updates yet as this is a huge undertaking :frowning:


#82

I like this idea, as long as markdown formatting still remains as it is.

Say, toggle to use visual or markdown formatting.


#83

@Luke @Craig_Oliver 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.


#84

@Erica, I’m not sure I understand.

Does “One way formatting via markdown, …” imply implementing the same formatting mechanics as seen in Dropbox Paper and Quip in such a way that the markdown syntax is only used as ‘shortcuts’ to implement the style/commands under the hood?

If so, then I wouldn’t personally be opposed to that as long as performance isn’t compromised for larger and heavily nested lists. However, the only condition would be such that the WYSIWYG mode remains still somewhat “à la Markdown” in the sense of only very select formatting options are available and apply simple rules (i.e. limited).

For example, font style and size selection are not a rich text feature (you can’t mix and match Arial and Helvetica with 12 and 16 pt font within the same file - these are the sources of pure evil within gDocs, mWord, and any more complicated document processors).

Also, currently the headings are implemented somewhat WYSIWYG mode, assuming because of potential tag conflicts, is there any use for them other than stylistically (bold and larger)? Like, are they used to anchor which items to appear in an outline in the side pane for example (I’m pretty sure that’s not the case right now, but that would be very cool).


#85

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.

#86

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


#87

@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?)


#88

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.


#89

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.

#90

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?

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.


#91

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.

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.


#92

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.

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/.


#93

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 :frowning:

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).