I’m hesitant to make any suggestion that might delay the Bear 2.0 launch, but I’ll shoot anyway.
I typically take an outline approach to writing. Working with headings or nested bullet lists to work out a structure which I’ll continually adjust by moving sections up and down in the document.
My suggestion is to add a shift modifier to the current move up/down shortcuts, and drag-drop operations which would bring any ‘children’ along when moving a heading or list item. It would effectively be like folding a section, moving it and unfolding it, but in a single operation.
Our intention is to provide a way to collapse and expand all the headers/lists inside a document. Once all the headers are collapsed should handier move sections up/down using a keystroke or drag&drop.
There’s currently some unexpected behaviour when moving folded content in a document. Say I have a note with content divided into sections by several headers, and I fold one of the sections lower down in the document so that only the header is showing.
When I use the shortcut key to move that header up in the document, it will “swallow” the content that preceded it. When this first happened I thought it was a bug and that I’d lost the content. In fact it was now inside the folded section.
This could be avoided if the move shortcuts were “aware” of the hierarchy (H1 > H2 > H3 … > Paragraph > Bullet > Intended Bullet …). Like an outliner, the content would be moved before or after its closest sibling.
I have reported same issue, that when collapsed headings are moved up down with shortcut keys, headings/content on lower level are "swallowed’'. It’s really confusing and not intuitive at all.
Got a vague reply to this bug report earlier on, but hopefully this will be fixed to work in a more intuitive/user-friendly way.
Dragging collapsed sections seems to work in the way one would expect.
I think you are referring to moving a collapsed header into another collapsed header with lower level. For example moving an h2 “inside” a collapsed h1. If this is the case, my expectations are the h2 become part of the collapsed h1 and get swallowed. If I’m not mistaken this is how the headers drag&drop works too. Are you proposing some visual clue when the above happens or modifying this behavior?
I’m strongly suggesting different behavior: that collapsed sections are moved up/down as a immutable unit when you use the shortcut keys for moving paragraphs.
Selecting and dragging a collapsed heading work this “proper way” and nothing gets “swallowed” up.
So not talking about dragging a collapsed heading into an other collapsed heading, but rather moving a collapsed section past another collapsed section without changing anything in either collapsed sections, only reordering them.
Same problem in Panda iPad alpha, when using the extended keyboard “move paragraph up down buttons” on collapsed sections.
Please test it with the Welcome note and you’ll see how confusing it works now
Thanks a lot for getting back to me so promptly
And would love to see B2 iOS/iPad beta very soon, even with this bad bug included
Ok, I got it but there are several problems with your way of conceiving the paragraphs moving tool. You can’t compare it to paragraph drag&drop: The first is fired by a single action (keystroke) the second start by moving some text and ends with its release. This doesn’t allow us to show intermediary states in the first case.
Let’s say we do otherwise and show you an h2 inside a collapsed h1 when moved with keystrokes, that state of the document doesn’t exists and if you refresh the note the h2 will be shallowed.
What you propose sounds like another tool that allows you to move an indicator, such as the line indicator of drag and drop, and end the operation, but I don’t think this can be done with one single shortcut.
