I can't be the only one who believes this...writing in a 2 panel markdown+preview side-by-side view is just horrible and backwards.
And I like the idea of markdown! Of course I want the ability to export to markdown for portability to the web. But for the love of god, don't make me surround my words in 4 character markup to make them bold, and then show me a second panel next to it so I can "preview" what bold looks like. Didn't we already solve this with 1980s word processors?
Hell, why don't we create a 3 panel writing view? On the left you can write in binary, in the middle you can see live base64, and on the right you can preview what it will look like to actual humans. Awesome!
The only good implementation of writing in markdown I've seen is Typora or Bear, which abstracts/fades away the markup after you type in a single view.
Notion also solves this by only allowing you to select from semantic HTML styles (ie. H1, H2, H3, etc) but you see what the final text will look like in one view. When you export, generating markdown is trivial since you're already using a markdown-esque set of options to style your text.
The whole point of Markdown (in my opinion) is that the formatting is a function of text that you can see and edit. The entire state of the document is visible, and there are no formatting operations you have to learn, just regular text editing operations like backspace, copy, paste, and so on. For example, if you press backspace, you always know exactly what the result will be: it will delete the character to the left of the cursor.
This is not so in rich text editors; when you press backspace, it changes both the document and invisible internal state, and you can't easily predict what will happen simply by looking at the screen; you need to be aware of the invisible formatting structure, or perhaps a recent history of things you did, or it might be entirely impossible to tell because it depends on some invisible state that was created weeks ago and saved in the document file.
For this huge advantage in predictability and simplicity, Markdown sacrifices formatting power (you can only do a limited set of things like headings, lists, bold, and italic).
That's why Markdown tools that hide the markup are, in my opinion, the worst of both worlds: you sacrifice formatting power, and you sacrifice editor predictability. After the markup is gone, how do you edit it? How do you unbold something, or change the indentation of a list? If there are separate commands for all that, then there was no point in using Markdown.
I see it as the opposite. If you give a 2 panel markdown editor to any non-developer human they will be baffled at how to do any formatting with it. Rich text editors are intuitive, that's why they've dominated computing for the last 30-40 years.
> you can't easily predict what will happen simply by looking at the screen
Huh? In rich text you see what everybody else will see. In 2-panel markdown you need the second panel to see how your final text will look to the rest of the world because you can't predict that easily when writing in an esoteric markup.
> For this huge advantage in predictability and simplicity, Markdown sacrifices formatting power
I wouldn't call requiring a second panel to preview how the actual text will look predictable or simple. It's a rube goldberg machine. On the other hand, I think the best thing about markdown is the restrictions to formatting. It forces you to write in semantic HTML.
IMO, Notion, for all its sluggishness, nails this part. They provide the intuitiveness of a rich text editor, while restricting the amount of styling to a markdown-esque set of properties so what you write will be easily portable to the web.
Both tools do it differently. Typora shows it when your cursor is there, but otherwise hides the Markdown. Bear always shows the Markdown but applies the corresponding style to it.
Rich wysiwyg editors also seems to have issues where the visible editing and internal formatting state breaks or behaves in weird ways. Like when you insert links and it automatically formats it as a link in some cases, and not in others.
Edit: Personally I always though the split view was okay as long as the compile times weren't too bad. Having a markup editor and then a view of the result is what I do for coding, so why not when writing stuff as well.
The point of markdown is literally that things don't hide. Wanna know if that semicolon is included in the italic styling? You will see it right away. Wanna know if a link has an old URL or is pointing to a weird domain? You see it.
This alone makes it worth it. Forcing the whole thing back into a WYSIWYG-editor will just mean that markdown becomes unreadable. A bit like when people used MS Word to write HTML.
It's called markup and a matter of efficiency. With richtext I need to mark the Text and click some button/menu-item OR learn a gazillion shortcuts for every little syntax-function. With Markup I use the same keys that I use for writting text, because the syntax is internal to the text, not some hidden external thing.
Of course it's possible to make a hybrid, something that displays richtext instantly while still working with syntax. But this is hard and cumbersome. Nonthless, Obsidian has it on their list as a longterm-goal, so maybe in some years we will see it.
Cmd-B for bold is exactly the same number of keystrokes as shift-8, and is exactly the same amount of cognitive load to learn. (You can also apply styling both on selected text and for text about to be typed, unlike plain text environments like this textfield I'm using now where you can't do shift-8 on selected text.)
When you get into the more esoteric syntax, it's still a tie: look how often even Gruber gets the Markdown link syntax wrong, and he designed it.
Joplin also has a beta single pane WYSIWG view which is like, I believe, Typora or Bear (markdown in the backend, but you type in what is effectively the preview window). I haven't really tried it out yet though. If it works well though, it might solve your concern though.
When writing longer things on either, I find myself firing up vim to copy paste afterwards, just because it's impossible to get into any kind of flow in these apps.
VS code also falls into this category by the way, albeit less severe.
For notion specifically, the total lack of keyboard navigation within a page (PgUp/PgDown, Space, Shift+Space, nothing works!) as well as the fact that wherever I click I will make immediate changes to the document (even if I just want to deselect some text or so) just makes the editing hugely frustrating, slow, and anxiety-inducing.
Seriously, if one day I wake up and write my boss that I'm outta here, notion and slack (and asana...) are way up there on the list of reasons.
Not that I don't believe you, I know this is real stuff that bothers people!
But it's so nice that this stuff never gets to steal brain cycles or cause me stress
Writing code in a heavy editor over VNC from the dog park wifi where I can type out my statement and pet my dog before it finishes? No problem!
Powerful IDE with everything including the kitchen sink but in some Faustian bargain it chugs at basic text editing? Let's try it!
Cool new editor doesn't have Vim bindings and a ton of mouse movement required? No problem!
It feels like I'm unencumbered by so much that some of my colleagues are always obsessing over, and yet we're all capable of the same output
I'm sure you have some efficiency built into your life that makes you more fragile.
(I don't use vim/emacs etc.) But you're saying that running water is a not a good idea because what if you have to go and get water from the well every day when the water stops running. You'd be so annoyed...
That reminds me of this blogpost [1]. It's definitely possible to optimize the input latency of rich text editors in the browser: they just have to be close to the metal of the 'contenteditable' browser api.
[1] https://juretriglav.si/what-happens-when-you-type-a-single-l...
No wonder these things are so unusable. But I guess slack know who they're targeting? People who won't notice the latency because when the pixels show up they're still busy finding the next key to press, or trying to find the right button for the text formatting... /s
I had forgotten how nice it was to quickly go through email and remember how quick gmail was when it launched. A colleague said “it’s just five seconds to open and load an email, that’s not a lot of time.” But that adds up.
That’s an extreme amount of time… GMail and Outlook are both horribly slow and I can’t understand how anyone wants to use them. Outlook even manages to be slow with their desktop app. Not as slow as either web app, but still a noticeable delay.
Fastmail at least is true to it’s name and fast.
I guess that is why people dont understand I am annoyed as I will only give a time budget of 500ms to open and load an Email on the Web.
If that is the case, I advise you check what's taking so long, I get nothing like it with my thunderbird setup.
Given, I disable html formatting where I can, that might make a difference. But even on my 2009 i5 desktop with hdd storage it doesn't take that long to load the actual email.
opening an email is always longer than 500ms, rendering it isn't in any system i use. hence i am not sure what we are talking here. if we are talking opening, then the 3seconds initial bootup of gmail isn't worth talking about imo.
the bottleneck for me at least is always finding the email and thunderbird is by far the worst unfortunately.
E-Mail is just a transport-protocol, poor in ability compared do other solutions and rather complicated, especially when it should be made safe.
The email standard(s) are great. Powerful, decentralized, and damn near universal. It's just that we live in a world where a Duopoly has taken over most of what we consider to be email.
If this comment resonated with you, I am working on something you might be interested in. Feel free to DM me for details.
Speed and snappiness don’t always come together, but when they do, there is no going back to something even a little slower or less reactive.
That’s why I don’t test nor try new hardware until I actually need more than what I have. It’s too strong to resist ;)
Decided to build an app where it's fast to start writing but is also set up to keep your notes sane over time. The app has a built in scratchpad where you capture notes in small chunks, like texting yourself. Then you triage the notes into categories later. https://youtu.be/xRxn4iiWZUM
Would love the community's feedback.
In a text editor, you would just have multiple windows, panes, splits ... and it’s just fast to jump, reference, copy/paste, etc. On trello, you need to reload the full board in another tab or lose context.
And you can't load multiple pages at once, it has to be in focus!
Is that a new thing? I just noticed that bit yesterday. I often have to load multiple pages and this is such a flow breaker...
"Come use a version of our website where you can't tabbed-browse!"
Yeah, that's a hard no from me...
EDIT: apparently not, according to [ https://joplinapp.org/conflict/ ] -- that's a bummer, it rules it out for my use cases :/ I really don't think a filesystem-based sync mechanism works great for a collaborative tool, which is much of the value of Notion to me. It seems really cool for single-user, never-shared stuff, though.
Nothing beats the writing experience of iAWriter for macOS users.
Is no-where close to the completeness (and complexity) of Notion, it works as WYSIWYG editor, no Markdown.
But it is very fast (hosted in Europe but underneath does basically nothing), with search, free if you don't want to pay, and it will stay since I host my personal notes on it.
Friction can be at different levels. All text editors especially the ones we are used to are friction less when we want to quickly open a new file and jot down something. But then, many higher levels things you want to do with chunks of text are not straight forward. You'll have to use plugins or write your extensions which sort of do what's required, but then they become clunky.
Doing the following things in a text editor is very clunky 1. Drop files from a file browser 2. A wiki that you'll stick to and not want to switch every month. 3. Write reasonably large documents that you'd actually also read in a text editor. 4. Have the same experience on all devices 5. Tables that are pleasing to the eye. 6. Visuals cues that enhance understanding of the content. 7. Select a bunch of text and convert them into pages or todos or tickets.
But, everything is slow these days. Aside from Roam, HN and maybe a handful of native iOS apps, I can't really name any app/site that I use on daily basis that isn't painfully slow.
Notion mobile apps are quite good, so I never have to tell myself I'll do something when I go to my desktop.
Seems like a very different app to Notion.
Notion is much better for businesses IMO. Like I said above, I use it for my startup. Specifically for task management, and even for our public docs site, ex: https://docs.haekka.com/
Maybe I should avoid anything faster than Notion so I don’t get spoiled.
...but the deeply ambiguous licensing info makes it a non-option for a lot of people.
But Obsidian has more points speaking for it. It works on local files/folders with well known types. No special formats involved which lock you in. Recently it started development of it's plugin-API which already started gaining some useful plugins from the community. And overall it's quite polished and userfriendly, not many quirks and corners which stay in the users way.
Basically, I want an app I can run on my desktop and phone, I can shovel every random thought, link, idea, code snippet, etc. into it, and I can find it quickly.
Joplin does this. Notion does this. Notion also has a lot of other features Joplin does not, true, I just didn't care about any of them. :)
This is way so many just try to fit their the note/task/wiki/etc.. flows to their text editors(vscode,emacs,vim)
I think that the wiki in Teams is not intended to be used but is rather there to tell someone in a position to buy who wants a wiki, but doesn’t use them, that the product has a wiki.
I tried using it and just basic stuff like linking to the wiki from various places is so difficult. I think the (incorrect) assumption Teams makes is that users are super stupid and only use Teams and nothing else, and only use what they are explicitly trained to use.
- crazy fast
- saves to plain text
- renders to html with links between pages
- one keypress to turn a word into a link to a page with that name and create the page
Try Vimwiki!
Unfortunately, it's too slow, at least for me. For a tool like that I need it to be a frictionless as possible, and Notion (for me!) is just a bit too annoying for me to put up with after extended usage.
If you value features over snappiness, Notion may be great for you though. It's an amazing concept! And I certainly understand why they'd choose the tech stack they did...
...but I'll stick with Joplin. :)