Visual editing (WYSIWYG)


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


#94

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. :slight_smile:


#95

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?


#96

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


#97

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.


#98

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

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.


#99

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.


#100

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