No, it's an editor, not a immutable website for consumption. The whole goal of them is that you can switch fast between editing and the rendered result. In that sense they are like word processors. But yes, adding an option for locking the document can be important, and usually they have them. I mean it's not even hard to implement. But probably not something people are mindful about.
I mean, an immutable website for consumption is exactly what most people want. I want to differentiate content editing and content viewing much the same way in software development you edit source code which is then built into an immutable read-only artifact.
Is it really such a foreign concept that people want a dedicated editing-focused mode whose source is published into the final wiki page for viewing? Is this not how basically all tools worked pre-Notion?
> I want to differentiate content editing and content viewing much the same way in software development you edit source code which is then built into an immutable read-only artifact.
On that note, I'm increasingly considering making my Emacs open all files read-only by default. When coding, I'm usually viewing many more individual documents than I end up actually editing - and multiple times a day, I end up accidentally typing (and then immediately deleting - muscle memory, this) a character into some file I was reading - and causing a spike in CPU usage, as the Language Server tries to reprocess the change. $deity forbid I do this in a widely-used header file - if I'm not quick with undo, LSP will churn through dozens of translation units before it realizes the edits were reverted.
This is not a big deal - usually just the cooling fans spinning up for a few seconds, and the editor (or whole system) getting slightly less responsive. It's just that the "slightly less responsive" part is really jarring.
> I mean, an immutable website for consumption is exactly what most people want.
Do they? Then export your documents to an immutable website. That's why those options exist. Personally I don't want that. I want to edit my content fast and the hybrid-solution doesn't bother me. So we are talking here about a conflict of interest, not an anti-pattern. And solutions for this already exist, maybe they should just advertised more prominently?
> I want to differentiate content editing and content viewing much the same way in software development you edit source code which is then built into an immutable read-only artifact.
I don't read the compiled artifact, I use it, which is very different from what we are talking here. A more equal example would be reading code on github or reading in a code editor.
Microsoft Word no longer does it, at least not for a typical experience - that is, opening a file you sourced from elsewhere (Internet, or your company's Exchange server, or e-mail attachment, or ...). Word, Excel, and PowerPoint will all open the document in "Protected View", indicated by an ugly yellow bar above the document with an [Enable Editing] button in the middle. Sure, it's done for security reasons, but for actual user experience, it's almost equivalent to opening all files in read-only mode by default.
This would be fine except for the fact that all changes are instantly committed in realtime, which is such an incredible usability antipattern.
If Notion had to be everything-editable-by-default, make it so that changes need to be explicitly committed and saved, much the same way one would do with Git. Otherwise it becomes impossible to track down these kinds of accidental mutations to the document, much less even realize that they have occurred.
Also, pointing to existing tools with glaring usability problems is not a justification for creating yet another tool with those same usability problems, amplified.
