Right now, whiteboards lack the organization/linking/etc. of pages/blocks. It would be nonsense to create an entirely separate system just for whiteboards, so here’s my proposal: allow us to create whiteboards as blocks on pages. That way, the whiteboard can inherit all the PKM magic of page properties (and even block properties) without any major overhauls!
This solution is elegant because of its versatility. You can create a page intended to only house a whiteboard, and you still have the freedom to add typed blocks later. And if you intend to make a typed page and later realize you need the freedom to scribble on a whiteboard, you can do that.
Example: I’m taking notes for a lecture, and I want everything in one place. I have a namespace hierarchy i.e. Fall 2023/Class 1/Lecture 3. But I want to use a whiteboard to draw and scribble with more freedom than typing allows. With whiteboards as blocks, I could have 1) the freedom of whiteboards 2) the PKM magic of Logseq and 3) room to later process my whiteboard scribbles into typed blocks, all in one place.
I know you can embed whiteboard previews in pages already, but it’s really not the same thing. What I’m proposing here is more fundamental to the way Logseq manages visual vs typed content in its database. If you would also like to see whiteboards as blocks please upvote!
We could boil it down to: Allow to create anonymous/inline PDFs or Whiteboards (which aren’t pages and have no name).
Or even more general: Blocks should be the central atomic management unit in Logseq.
For this it is probably needed to assign types to blocks (internal or external), like Whiteboard as block type, to make use of its specific features. Like opening the canvas for a whiteboard.
EDIT: I also would favor to completely ditch “Whiteboards” section in the left sidebar for this reason. It adds unnecessary friction between all entities in Logseq. Instead make everything uniform and allow to search Whiteboard via their block type. Or just auto-assign a tag #Whiteboard to it.
I really like your approach. My idea in the other FR was way to big and I thought my use case is so particular that it makes not sense to implement such a thing.
However starting with simply allowing whiteboards to be parts of pages would already unlock so many features. Implementation wise, I think most of the tooling would already support it, as whiteboards are in fact blocks in the database. The UI simply does not allow you to create them as a block on a page.
One problem however is storage! The page it self is a markdown file (this will change with the db-version). If you want to store the whiteboard in the file, the markdown file becomes unreadable as any element on a whiteboard has a corresponding block with lots of properties. The underlying markdown file thus becomes pretty much unusable for external tools.
I think it would be a lot of work to adapt the file parser to parse subsections of the markdown file as a whiteboard and if you make changes externally your whiteboard would break most certainly as logseq could not load it any more.
Maybe a solution would be to allow whiteboards as page blocks for the db-version only?
Yeah probably a feature to come after the DB version. Although the markdown file could just store a text ID that Logseq matches to a whiteboard file somewhere else
Yeah, you can achieve something similar already, but the UX just isn’t there. Like @debu described, Logseq should embrace everything as a block. That means getting rid of whiteboards as a separate, fragmented feature and integrating them into Logseq’s original purpose as an outliner.
For me great note-taking is all about reducing friction, and that’s what this proposal is for. But to get there, Logseq needs to change its fundamental UX philosophy to: all content belongs in blocks.
Why should Logseq have fragmented PDF/whiteboard/etc. features when everything can be consistent with a straightforwardish change?
