# Visual editing (WYSIWYG)

#64

At least you guys are trying your best with what you have, so that’s fine. You don’t really have a choice on Safari, or perhaps other browsers, since they all have to use the same engine on iOS.

I think a floating one is fine, as I don’t have to constantly move back and forth. It should be rigid in the sense that it appears as long as text is selected. Sometimes if you move the mouse away from the body (upon selecting text), it’ll disappear.

#65

In the app we have some more control as we can listen for some native events. All that is simply impossible on mobile Safari.

#66

[quote=“Erica, post:63, topic:34”]
The iOS floating toolbar is a workaround because Safari is special like a snowflake… on Android it has always been fixed. [/quote]

Coming from an Apple fanboy perspective , Safari is a bit of work…but that’s true of the whole OS and platform. These are some reasons to think about the process of thinking about hiring an iOS guy/girl for the team. You know your business - but hopefully iOS/Mac OS users make up a good paying percentage of the total user population.

I know I have no plans to move to Android and might consider Windows 10 (Mobile) if Microsoft could ever get their act together.

#67

I don’t think that’s too hard, it’s just a matter of having the money to compete with larger companies. As a bootstrapped startup that isn’t making enough money to pay for the full-time work that Shida and Erica put in, it has a ways to go before they invest time in developing native apps for iOS or hire an engineer.

I agree with you here. The ROI would be pretty good.

Since what Erica said directly above is that it’s impossible on Safari, but not on the native app, I guess that’s a good compromise for now (once most of the bugs are fixed).

#68

Yes, I love both Ulysses and iA Writing regarding their typographic decisions. I am really annoyed by “changing mode.” It gives me a pause and I find it distracting. (The very same reason I don’t like writing descriptions in Trello) I read through the comments, and understand Erica doesn’t like the idea of **bold text** because it looks like <div>text</div>, but like the Latex formatting and all these advanced features Dynalist offer, you need to focus on the makers, what makers really want. (writers, programmers, designers, all who make things professionally)

I am okay with WYSIWYG style, but I just think switching mode makes users unproductive.

#69

I’m a big Markdown fan, but regarding Dynalist I have a couple of factors to bear in mind…

1. Speed of use should be a key driver in Dynalist. My thinking is that as you get experienced using a tool you probably start using keyboards shortcuts, which really speeds things up. Anything that makes you have to reach for your mouse and start clicking away is going to slow you down.
2. Although I’m a Markdown fan, I’m probably in a minority.
3. If you want to format an item and/or note then likely it’s longer and I’d be happy to use my favourite markdown editor and cut and paste the formatted result.

#70

I’ve tried Typora, but I don’t think it fells under the traditional WYSIWYG category. When you press Ctrl+B, it basically just inserts asterisks for you, rather than applying the format directly. With a WYSIWIG editor like Google Docs, you’ll almost never seen the “code” that’s responsible for the formatting. You just see it.

I believe @Matt_Groth was talking about a way to switch between WYSIWYG mode and Markdown mode, which is kind of different from what Typora does.

Hi Erica, Just saw this reply.
I was actually referring to the way they treat mathematical equations - the small popup/preview with live update of the MathJax (or Katex) rendering.

#71

WYSIWYG pls

#72

I’m curious, is there any timeline for this feature now? Maybe releasing public due-dates for features is a bit much for you guys, but is it being worked on or are other things higher-priority right now?

#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!

#74

Hi,

I would also to express my remarks
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 )

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.

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

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