My Discord post got lots of positive feedback, so I’ll post it here for further discussion:
UI suggestion: rather than defining the view using one main pane, a top toolbar, and 1 (or 2) sidebars, have Logseq use a more modular approach where the user can define a view with one or more panes, each of which can be set for certain types of content (whether Logseq pages, a sidebar, an outline view of a document in another pane, or an iframe). I was motivated to post this because I’m dealing with a certain writing problem that in this specific case really needs 3 notes open at once, which I can’t do.
Justification:
users have lots of different and very particular preferences, and this would satisfy the most people
it doesn’t need to complicate things in terms of new users, who can be presented with a simple default UI and change it only as desired
different tasks demand very different workflows that would benefit from different UI setups
ideally, users would be able to define certain frame schemes as a type of UI theme and share them, either as part of a theme packaged with css, or as an independent config file.
I am imagining something with the flexibility of emacs windows, but an easier user interface. Add new pane, delete pane, lock pane in position, split pane, save pane view (with name), open pane view, and assign pane function (e.g. sidebar, outline preview, note pane, iframe, etc.).
Note: just realized that this is related to a discussion here, but I don’t think the Logseq team commented on that thread.
Technically, it should be possible to bring buffers (as in Emacs) and windows into Logseq, it will enable more workflows, but it creates problems and make the whole app more complex at the same time.
For example, when you have multiple buffers/windows open, which one should be the chosen buffer/window when shift+click a block? Have multiple windows and buffers also means we need a robust layout to make it effective. There’re some open source solutions, but afaik they all have some edge cases. Another thing is that it increases the complexity of the UX, which is against our goal to make logseq used by more young students or even children.
Another idea is to just use a canvas instead of multiple windows and buffers, then we can open a page/block and drag-drop to anywhere, it also makes it easy to see some connections between those pages.
This is an important question, we’ll keep it in mind when we’re fixing issues and making logseq reliable. Any suggestions are welcome, let us know if anyone wants to play with those ideas!
Complexity/simplicity from the user perspective: this should NOT be a concern. There are MANY programs that are used at both simple and complex levels by users. Children can use Microsoft Word. They cannot use Visual Basic scripting, but that doesn’t mean that Word shouldn’t support such scripting. Children cannot use Styles easily, but they are available for mid-level users. Logseq’s default layout and options can stay simple, and you can still allow users to make it more complex if they choose to do so. Logseq can easily have the current simple layout with one window/buffer, and allow advanced users to optionally activate additional buffers. Can children use Losgeq queries? Should we have them? It is great to have a program with the goal that anyone can START using it, and they can grow with the program and learn to enjoy all of its potential.
So everyone, STOP worrying that the option for a complex UI means that everyone has to learn a complex UI! It doesn’t!
Now, as for technical complexity, that’s another story. First, I don’t really know the difference between a canvas and multiple windows, but either approach is fine if it lets me choose how many notes to see at one time and customize things like putting in iframes or an outline view. As for edge cases, if the basic idea of a more customizable UI is a goal, I am sure we can figure out solutions for these particular things. If you have multiple windows open, when you shift/click the block, can’t you choose the window under the mouse cursor? It will be easy to think of potential problems, and it is important to do so to figure out solutions, but I would love to see custom UI layout be on the roadmap as a long-term goal to keep in mind.
Maybe other more technically knowledgeable users can comment on ways to actually implement this concept?
You can have the ability to create multiple panes but choosing not to do it. It can even be toggled with a config parameter.
I’ve said the same on discord but IMHO having just 2 sources of information (notes/blocks) isn’t enough sometimes when you want to correlate information. That’s one side where Obsidian excels (with or without Andy mode) and you can move between panes with the keyboard or the mouse.
The side bar is really useful but the limiting factor is that opened notes are stacked.
If you have 2 notes opened in the sidebar and you want to take a look at the first one, you need to scroll a lot since backlinks are at the bottom and could be a large list. Of course you can collapse them but it feels like too much friction some times.
As well, I see in the roadmap that logseq will have a PDF mode to create highlights and annotations. How is it going to work if not with a “Multi-Pane” view? You will need to have either the PDF opened or your note opened but not both?
Thanks for this “suggestion”, it hits everything I want to say and I totally agree on: when more than 1 notes are needed to refer to, the sidebar solution will be hard to use (too much friction). I think this greatly limits the power of logseq to learn or write things that are conceptually complex.
I think this sliding pane style needs to be considered. See here(Just go there and try clicking on some links)
There is a plugin for obsidian that provides exactly this functionality that many people use.
I think simple horizontal splits should be priority but a vertical split might be handy too
I agree that sliding panes should be available in some form since there are some people that really like them. I think we should consider sliding panes a separate issue from the modular UI described here, since the two can be implemented separately and have no logical dependence. Sliding panes have been implemented in Roam with CSS alone, for example. So if you want sliding panes, I recommend making a separate thread in Feature Requests if there is no current request. Thanks!
I’d love to hear if there are plans to build out the view API. I too am entranced by the multi-column UI from Andy’s site and the Obsidian plugin that it inspired.