Completely agree with this - folding/unfolding should be frictionless, otherwise there is no point. The whole point (IMO) is to have a way to easily click to expand, then click in the same place to collapse. On the iOS beta it is particularly awkward - while reading a note, it takes four taps to fold a section. In my opinion, once a section or code block has been designated as foldable, there ought to be a toggle to fold/unfold it easily.
5 Likes
Totally agree.
Folding and unfolding should be as simple as...
one click! đ
6 Likes
I completely agree. Folding and unfolding should be a single click. And whatâs the purpose of âtoggling foldingâ on and off? It should always be on for headings and bullets. Take a look at how Reflect.app does this for bullets for a slick example.
2 Likes
I donât want to say nothing to headings as i almost never use the feature to fold them.
But one word to bullets: you can fold them by clicking on them AND by using the command-key. I cannot imagine any good reason to make the latter one necessary. Why not only clicking on them?
(and i am speaking about macOS)
1 Like
Maybe everyone else knew, but I just discovered this works on headings as well (on macOS). If you hold down the command (â) key and click to the left of a header (you donât have to move the cursor to the line to make the header icon visible⌠just clicking on where the icon would show up if it appeared on hover) and you can fold & unfold headers with a single click just like one might expect theyâd work without the command key held down. 
3 Likes
I didnât know neither. One reason is that i never tried. The other one is which i remark often enough as someone who doesnât have a workflow based heavily on hotkeys. As longs as a feature is not present visually in the ui (means: available for mouse and touchpad) many if not the most users wonât discover a feature intuitively. I like to advocate to the devs (@trix180 and @matteo mainly) to always keep in mind that there are users which main form of interaction with a software (apart from writing) is based on mouse and touchpad
1 Like
I donât see adding additional UI elements as the solution, unless contextual (when hovering next to the heading with mouse or cursor). Instead,
- make sure the shortcut keys for this feature are less cumbersome by addressing the fold all and unfold all, which are currently two different menu options, so the same key canât be bound to doing this.
- Also, folding should fold text but leave the headings visible (see C).
- Situation: you have a heading 1 and and a lot of heading 2 and 3 (see A). Doing a fold all, will fold everything under heading 1 (see B). How useful is this?
- Instead, if everything was folded, but the headers left visible Iâd be able to see the skeleton of my document and do e.g. a toggle folding on the heading I want to dive into (see C).
A) Example note with headings.
B) Currently when using âfold allâ everything gets folded under heading 1.
C) Instead this should happen. Imagine every heading have the (âŚ) to expand the text underneath.
Edit: typos
Since each heading could be followed by text before a header of smaller level comes your request could lead to confusion. Actually folded means: folded
Nevertheless: as long as there is just ONE header of level H1 (which generally acts as title) it should be excluded from the fold all feature. There is no sense at at all to see just the title or first header
It seems that you want a toc inside of the editor itself. But an toc already exists and with final release of bear 2 it will be available inside of a fourth column in the main ui
2 Likes
I welcome keyboard shortcuts but I must agree that having UI elements for folding/unfolding is equally important if not more. This is because:
-
Even when Iâm using mac, I frequently just am reviewing and thinking about my notes, without actually typing (and thus Iâm mostly using my trackpad and not keyboard). So having to use keyboard shortcuts with my two hands on my keyboard just to fold and unfold seems counterproductive. If Bear were to be vim, Iâd be fine that itâs designed just around keyboard interactions. But Bear most definitely isnât that kind of software. I also trust Bear dev teamâs design and surely the UI element will be elegant if they decide to implement one.
-
When using Bear on iOS (especially on iPhone), itâs even more important to have a simple UI element thatâs readily accessible.
4 Likes
(Deleted because I realized what I wanted to say has been said by others.)
⢠Not sure what would be confusing as there would be there three dots (âŚ) to signify that it can be expanded.
⢠And your following suggestion is making an exception to your âfolded means: foldedâ, which some could argue would lead to confusion too.
⢠Yes, thereâs a ToC in Bear. However, I do not see why getting more use/information out of folding headings should be in issue.
⢠End of day it comes down to how the rule for folding is established. I prefer that itâs functional. That is, looking at the use cases for how and when people would fold. Having everything collapse down to e.g. two H1âs I see little value in.
⢠In many programming tools there are various options (rules) for folding/collapsing (which doesnât seem to lead to confusion to my knowledge).
1 Like
Thatâs an meaningful exception because it doesnâ make sense at all just to see the title of the note. Generally the title is not part of the toc. So then everything is folded all headings of level 2 should be visible to show the main structure of the note
What you request is not folding but hiding of sections and not of the whole content under a header to which sub headers belong. Only in that sense it is a toc in editor. Why replicate an already existing feature when the current implementation offers a different and good approach
Bear is not a programming tool. So actually it doesnât matter what they do and how they do it
⢠Itâs as meaningful an exception as mine.
⢠With regards to titles. As long as âtitlesâ in Bear are not different (something else) than a H1 then you have no control over where and how many places a user might use H1s in a note. Some might not consider the first H1 at the top note as title because they use several H1 throughout the note. Some might not begin their note with a H1, but might add one further down in the note.
⢠Because I find it useful. I can more quickly see the outline of the note. I can quickly zoom in and work just on the heading(s) I choose to expand - adding the context/contrast I need.
â Obviously, all this can be done today, but more cumbersome.
⢠Iâm very curious about how you are using folding if you would elaborate on your workflow/use cases?
⢠Youâre right, letâs not learn from what others have done in this area.
Agree that folding interface is too complicated. Look forward to what the team comes up with.
1 Like
Actually I donât use apart from rare cases where it is necessary to see different parts of the text relatively near together
It is always good to learn from someone who is better: if you have a yellow belt in karate watch carefully what those ones with black belt show and tell. But you are not going to improve your karate skills by learning from a kick-boxer. You would benefit from him if you want to fight in the mma. But there is obsidian: it knows Karate, Kung-Fu, Jiu-Jitsu, Taekwondo and a little bit Krav-Maga. A few plugins more and it will know Aikido, Muya Thai and Jeet Kun Do. Nothing on a perfect level but nevertheless. I prefer bear to be a Shaolin master
I also find the folding/unfolding to be a bit of a hassle. Check out Dropbox Paper - they have a little arrow that appears to the left of the heading when you hover over it (see attached) - personally I find this UX to be a bit more straightforward but I understand Bear currently shows a hamburger menu there.
The big issue with the current folding UX is it requires three taps. Two taps would be much more bearable.
1 Like
I have an aesthetical problem with the triangle 
But i would welcome each improvement that makes possible that just one click on bullet list point folds and unfolds
I see there is already a lot of commentary on this topic, but I came here to +1 the main idea.
Workflowy I think perfected outline folding. Maybe those can be inspiration for Bearâs feature, if it hasnât already been mentioned. Iâve linked a GIF I created showing the behavior.
I also adore how Workflowy lets you zoom in on any given outline item, to hide all the other items. Probably too late to implement here, but could be really awesome.
2 Likes
Actually, I would argue it does matter, because they are âprior artâ and it is useful to see how others have solved similar problems (even if not targeting the same users) rather than attempt to reinvent the wheel, and especially when the reinvention is of a UI convention that differs from those potentially broadly established elsewhere.
In general, having just installed Bear 2.0 and reviewing the Welcome document, I have partially collapse the document somehow and, no matter what I do I cannot seem to get it fully uncollapsed or fully collapsed again.
And, for someone using software for over 25 years, I cannot remember a time when I had an issue understanding how to collapse or expand in software.
IOW, I think the current implementation really needs some work to both improve usability and learnability. #jmtcw