Make "toggle" a feature of every block

[qualquertipo]

@bOokWorM

Create these toggles in such a way that columns and other stylish formatting remain unchanged after moving under the toggle, unlike in Notion.

Good one. Did not know that. If you have Notion and it’s quick for you to do, add an image to illustrate your point.

Ideally as you nest stuff, the only difference should be that the width of the block gets slightly smaller at each level. Whenever the width gets too small to fit the content gracefully, just use whatever layout would be used for mobile.

Also, ideally the user should be able to just click on a block to “zoom” into it, making it take the full width (and also increasing the width of it’s children.

For example (in RemNote):

Click on Sculptures:

[qualquertipo]

I don’t think this FR was referenced here:

Use the keyboard to collapse a toggle block

Is your feature request related to a problem? Please describe. It’s a personal preference how you use your keyboard to interact with software (that’s why I like the Customizable keyboard shortcuts feature request). To outline the current behavior for toggle blocks as tested on Anytype for Windows 0.24.0. To make a new toggle use ">" + space, then a name OR use toggle in the / (slash) menu Note that the behavior between “>” and /toggle is different! “>” creates a toggle and expands the toggle…

[BabbageCabbage]

Just my 2 cents as you work on this - it would be really nice to be able to differentiate toggle blocks that do/don’t have children. 2 example implementations:

Notion (good)

Coda (better)

And lastly a good system of hotkeys for organising / indenting. Again Coda has the best implementation I’ve seen - e.g. Alt+down shifts a block down but at the same level of indentation (unlike Notion, and indeed Anytype).

[Mccbrennan]

+1 to this idea. Being able to toggle anything is incredibly useful as it helps to organize any given page and note. That way things don’t become to cluttered

[jannis]

+1 here, would love to see this feature

[qualquertipo]

Any updates on this @ignatovv ?

[ignatovv]

Hi @qualquertipo we were really focused on making a new sync infrastructure and public release prep. I personally want it too but there are too many things to do around. You will definitely see a lot of updates in next product update . This one in a list of core updates after public release.

[qualquertipo]

Thanks for the update!

Have you guys considered having a Forum category for discussion on designs? You guys could use it to share the designs you have for new features, so we can already start commenting even as you implement it.

[Narvey]

@ignatovv which approach are you taking? eliminating toggle as a type and making all of them toggles? or only those with children?
For the record, I’m OK with the former approach because I don’t think everything-can-toggle is intrusive in LogSeq. I’m also OK with the latter approach as long as ¶ after H1 is considered a “child” even though they aren’t technical children as far as indentation.

[ignatovv]

The overall vision atm - styles (H1 H2 etc) and decorations (toggle, checkbox) should be separated thus every block can contain a toggle.
However we need more upvotes to make this happen

[Filip]

So you would still need to manually convert blocks to toggles?

[ignatovv]

If i get you right you want every block have a toggle by default. Anytype is not an outliner and so far we do not see any signs it will be. So toggle is just another decoration of block. If the demand will be high enough or we will see how this approach strategically helps we will change the direction.

[Flip]

Exactly. If I’m not wrong that’s the wish of this whole topic.

[Filip]

Yeah, that’s how I’ve understood this topic as well.

I’m not sure about all blocks, but use cases for headings and lists should be pretty obvious. If you section your canvas with headings, you can then easily toggle them on and off to hide the text that you might need or not need at the moment. Especially if you have a lot of text in one object.
Similar use case for lists. If you have a really long list that also has a couple of indents, that can easily get out of hand.
Obsidian has automatic toggles for those, for example.

[Oshyan]

I can’t speak for everyone who voted for this, but I thought I made pretty clear in my original request that I did not want Anytype to turn into an outliner:

@Oshyan

If you look at other systems that use blocks, such as Roam, every block can be collapsed. This is a good example, however we do not want everything to be an “outline” (set of bullet points) as it is in Roam. That’s fine, Anytype already works this way, everything is a block, and blocks can be nested (parent-child) without being “bullet points”. So simply add toggle state to block controls would work well in the existing system, along with a visual indicator when a block is collapsed and has contents inside.

Also see how Capacities implemented this exact request in exactly the way I hope Anytype will:

Make "toggle" a feature of every block instead of/in addition to a block type

I saw a recent implementation of this that I really liked, and which aligned with much of how I had been thinking about the “formatting” vs. “functionality” of blocks as well. In short, I think an extension of the “toggle on every block” concept is that certain kinds of functionality could be separated from formatting, as they are arguably separate concepts. How something looks vs. how something works (what you can do with it, how you can interact with it, if at all). To some degree the lines ar…

It’s really quite simple, and IMHO quite useful. And the entire point is to avoid having to re-implement toggle for each block type that gets enough votes over time: just implement it for all block types and be done with it.

[jannis]

@Oshyan

And the entire point is to avoid having to re-implement toggle for each block type that gets enough votes over time: just implement it for all block types and be done with it.

Thanks @Oshyan for coming back to this post and pointing it out again! Totally agree with the points you made.

For me the this whole topic was straight forward and I think most people correctly understood the idea. I somehow don’t understood why the chances of implementation went from 100% here …

@ignatovv

This request is 100% on track
Designs are already in progress.

… to nearly 0% here …

@ignatovv

Anytype is not an outliner and so far we do not see any signs it will be.

Perhaps it’s just a misunderstanding due to the unique design concept, but I believe this request would be a great fit for Anytype even without turning it into an outliner.

Only reason that comes to my mind that would speak against this idea, is if Anytype is actively moving towards becoming more of a browser. Traditionally, browsers as we know them do not support the toggling of blocks. While it may be a long journey from the current knowledge tool to a space builder and ultimately a browser, it’s possible that this is the vision of the product team.

@ignatovv, could you please elaborate once again on why this doesn’t align with your vision? Maybe we can find common ground. I can see there is a significant level of engagement in this discussion.
Thanks!

[Filip]

@jannis

Traditionally, browsers as we know them do not support the toggling of blocks.

There are ways to implement similar things like collapsing sections etc. today already in browsers.

[ignatovv]

So you would still need to manually convert blocks to toggles?

I think I still do not get this one. Regarding rest of conversation - we want to give an ability to add toggle to any type of block.

[sambouwer]

It’s mainly a user experience question whether you by default can toggle (expand and collapse) any block you add to a page, or whether you need to manually add the toggle option to every block you want to toggle. Of you need to manually add it, requires one more click/step from the user (i.e. add the toggle) compared to every block being a toggle by default.

[ignatovv]

This is why I interpreted this request as a request for outliner capabilities because in any other circumstances toggle could not be a default state for each block.