Improvements
Triage

Five clicks for activating/deactivating the Side Peek layout is too much

What could be better?

Actually, it needs four clicks to activate the Side Peak layout, plus a fifth click to get the open menu away.
That's too much!

My ideal would be a one-click solution with an always available switch button.

But even if you don't want to add such a button, you could at least compactify the View setting menu.
There is no need for the sub-menu "Layout".
And there is definitely no need for the absurde sub-sub-menu "open in".

-- If you move the stuff from the sub-menus into the first (and only) level of the View settings menu (there is more then enough place in it), then it would reduce the amount of needed clicks from 5 to 3 clicks.

These kinds of unnecessary nested sub-sub-sub menus was always an illness of legacy Anytype. A daily peeving dose of friction.
AnyTwo shouldn't repeat this UI mistake.

How so?

I think that activating/deactivating the Side Peak layout is an often needed option in the daily workflow. Therefore I would favorite a one-click solution with an always visible switch button.

1 Comment

Sign in to comment

AL
Alex Lins (Bao)·about 3 hours ago

Thanks for reporting this — the detailed breakdown of the click path and the comparison to nested-menu friction helps clarify the pain point.

To move this forward, a couple of specifics would help:

  1. When you say "daily workflow" — are you toggling Side Peek on and off within a single session, or activating it once per day and leaving it? That shapes whether a persistent button or a faster menu matters most.
  2. Where would you want that one-click switch to live? (toolbar, view header, a floating button, somewhere else?) That's the design decision the team needs to make, and your sense of what feels natural in your actual workflow would help them land it.

The UI simplification angle (flattening the Layout and "open in" submenus into a single View menu level) is separate from the one-click-button request — either or both could land depending on what the team prioritizes. But understanding your actual usage pattern first would help them figure out which solves your real problem.