As someone who is familiar with how that tool works (I’ve experimented with similar, though a desktop software’s take on the idea rather than a website), I know of what you speak of in terms of how both Scrivener and these sorts of tools are outliners, and so a most literal mapping of a “bullet” in a block-based system like that is to a binder item. That was of course the underscored point that I was making in my response—that in Scrivener the bullet points are in the binder not in the editor.
That said, I do not see what you are referring to in your interpretation of the request, and to me it is clear from the way in which they described their request, that they use bullets in the text editor in Scrivener, and were hoping to see a type of document (aka binder item) that would work like these tools do, as an inline outliner with native folding built into the model of how one works with information. It goes directly back to what I spoke of in the thread I linked to, of how there are two predominant models for outlining: the embedded text editing approach and the list of headings w/ “notes content” approach, which Scrivener uses.
Be that as it may, if we are for some reason all wrong about a request for “Collapsible bullets in doc” not being about folding outlines in documents—then I’m afraid I don’t actually understand what part of the request does not already exist already. If we are talking about using the binder outline to its fullest, where each dictionary word is an entry in the binder, and definitions are indented child items beneath the word entry—then we can already fold the outline. Right?
Do you mean folding text chunks in the editor, as in a function of Scrivenings mode? If so, we can already do that as well. Sure if you just click on a folder you see everything below it and have no say beyond that, but Scrivenings otherwise only ever shows what you’ve selected in the main editor. It is a naturally folded and isolated view. If you want to fold a section out of its view than remove it from the selection that is driving the session with a simple Ctrl-click. I would hasten to add that I do not feel the correlation is perfectly similar, but if you go from that seed as a starting point and start thinking of Scrivener’s capabilities elsewhere, such as with collections and how selections become pseudo-elements stored in history, etc., you can see how there is a lot of support for this approach.
@Tim_H: The request is about improving this (superior) model.
So to speak abstractly on that, yes I think there are things we can do to improve this model, but my thoughts on that would orient more toward how the outline/editor relationship can be improved, rather than pushing the editor toward an outlining model, even if only to dip a toe in—because sometimes that all on its own starts to muddy the water. Bear in mind we already have threads like this, and the one I linked to, and many more besides—threads that demonstrate how there is a learning hump involved in fully grokking that the list of things in the binder isn’t a file management system but an outline. Those that are very familiar with outlining, but come from tools where outlining is purely a construct embedded into the text editing interface naturally gravitate toward this kind of feature request: “Scrivener’s bullets are awful, make them act more like folding outliners”. This is fine, to be clear, and I don’t mean that in a derogatory way at all! I don’t even mean to suggest that folding editors are inferior in a general way—for some things they are incredibly powerful.
What I’m getting at is that we already have a hurdle to overcome in that editor outlines are far more prevalent and common than “two-pane” outliners. If we already struggle to convey what the latter is, would adding even a semblance of folding metaphor into the editing environment serve to make it easier or more difficult for Scrivener to be learned? And I think that’s the most important question here, since we’ve already established that the actual act itself, of “folding” text out of the session is already perfectly functional and well supported in the software.
