| What you call "seamless-editable-by-default" is my biggest frustration with notion; I wouldn't characterize it as "seamless-editable" though, I'd characterize it as "accidental edits". Like the OP, my org has taken to locks/unlocks all the time. (And this is extra frustrating, because the load on "unlock" is often worse than the actual page load!) Several months ago, I got so fed up with edit-by-default that I started a chat in the feedback thing in the lower-right. What I learned from that chat is that other people weren't using Notion the same way we are. We use it largely as a wiki & knowledge base; it hadn't occurred to me that other people aren't using it as a knowledge base, which is almost by definition read-heavy. But I also want to point out that editable-by-default is exacerbated because other aspects of the UI have trained me to have behaviors that result in accidental edits. ---- Me: > I'm sick of making accidental edits. > 9 times out of 10, when I go to page it's to read it not to edit it. Editing is rare enough that when I want to do it I'm 100% down with having to click an "edit" button or something to explicitly switch to an editing mode. > This isn't a permissions thing. I should be allowed to edit all of these pages. It's a UI thing that it's too easy to accidentally edit. > This is an account-scoped problem. It shouldn't be broader; other people in the org shouldn't be affected by my preferences. It shouldn't be narrower; I don't want to have to configure this for each page. > Many parts of the UI seem to be designed to cause accidental edits. Positioning the cursor at just the right spot can introduce an empty line. It's easy to accidentally drag something when highlighting text to copy. Clicking a link to another Notion page opens in the same tab normally, so I get in the habit of middle-clicking them to open in a new tab. But if it's an external link, then for some moronic reason middle-click doesn't open it (just use damn `<a>` elements! stop breaking the web!), and then I get middle-click paste (because X11) and I end up accidentally pasting some garbage in to the page-- _because of a behavior that other parts of the UI trained me to do_. > I'm sorry for the rant, but it seems like such a basic thing, and it's been so frustrating. > Like, my ideal resolution is you point out a setting on a page that I missed and I say "nevermind, cheers". Gerard: > (a lengthy reply explaining how to use page locks and database locks) Me: > Re: Page lock: That's not a solution, for a bunch of reasons that I'd tried to express in the original message: > - I don't want to manage this for individual pages, that is error-prone and tedious; if there's a page that doesn't have it set, I won't notice that it's not set and risk making accidental edits. I don't want to have to remember to turn it back on after making an edit. > - I don't want prevent others from editing it, just myself > - I don't want others turning off the page lock to affect me. I don't want to have to train everyone to always set it after editing a page. > Re: Database lock: I'm not sure about other parts of the org, but I don't really use database pages, so that's not of interest to me. Winnie: > Hello Luke, > Winnie here, jumping in for Gerard. Thanks for sharing your thoughtful feedback! > We don't currently have page setting that lets you be on a viewing mode and have some sort of prompt if you want to edit a page. It’s a legit use case, though, and definitely something we want to support in the future. > This would totally help those that are creating wikis or knowledgebase, so I've passed this to our product team to take to heart for further improvements. |