I just accidentally closed a large Bike document, and had to open it again. I realized that when I open a document EVERYTHING is expanded by default!
To me it’s very important the state of expand/collapse of every item, because I use outliners (like Bike and previously Workflowy) to organize tasks, and the information that pertains to tasks.
I use many levels of indentation, and I’m expanding/collapsing as I need to deal with problems—When I want to leave something for later, I collapse/hide it. And when I want to deal with something now, I expand it. And that occurs at multiple levels of indentation.
So it’s kind of scary to open a document and part of this map of what I need to do now vs later simply gets lost. Basically to me the state of collapse/expand is a key part of the information that the document itself should contain and always keep untouched. It should only be changed by me.
Sorry for that jolt, hope things are back under control now.
If I’m hearing you correctly I think you already know how Bike will save/restore focused rows when documents are restored. It’s only when you explicitly close a document that expanded state is lost. (Or when you have the setting “When Quit Bike: Close Documents” selected)
Basically to me the state of collapse/expand is a key part of the information that the document itself should contain and always keep untouched. It should only be changed by me.
I think the core complication is that Bike can have multiple views on the same document. For example when you already have an outline open choose File > New Window.
The new window will show the same outline state as the original window, but can have different size, scroll position, selection, focused row, and expanded rows. You can open many different windows to get different “views” onto your outline.
Now think about Bike’s file format, there’s not really a clear way to save expanded state since each row might have multiple expanded states from the different views.
That’s all why it works the way that it does right now.
With all that said I may revisit this. I can imagine maybe only saving expanded state for the frontmost window as document metadata. Or maybe even saving all window state as metadata and then when opening a document maybe multiple windows will open. That would be interesting and maybe useful, but it’s not really the way that macOS document based apps are designed to work, so its against the grain about.
Yeah, precisely the feature I’m looking for is “collapse/expand” memory. Sorry to be “that guy”, but it’s also kind of a deal breaker to me, because I use outliners to manage deeply nested webs of tasks and information, and working with tech I’m always working on dozens of “problem threads”.
Ps: Sorry for “reopening” this subject, hadn’t seen there was another thread on it, as pointed above.
Workflowy (an outliner that works as a single document) saves the expand state (even across different browsers or devices). I have nodes there that I haven’t touched in years, and when I revisit them it’s exactly as it was… feels like time travel.
Regarding the “multiple views” issue, I’ve just opened multiple views of the same document on Workflowy to see how it behaves. It is not syncing the collapse/expand state in real time. I suppose they eventually merge the states of the two views, because every view that I open simultaneously starts from the same collapse/expand state, even if I open in another device. I don’t know what merge strategy they use, but it works fine. (I’ve waited a little while and haven’t seen any live syncing of states)
But anyway… I really like how Bike feels!! I’ve used Workflowy for almost 10 years… but their desktop app is too heavy on ram consumption for my old Mac Mini haha. So I’ve come across this very lovely app called Bike. But I have to say, the lack of collapse memory is a big deal.
For now I’ll keep using Bike trying to never close the window. But it’s a big compromise.
Huge thanks for your reply! Congrats for this app, really cool stuff.
I did not realize I could open multiple windows of same Bike document.
Perhaps the design ship has sailed but if multi-window behavior was simply “different view port on same document” (ie. any expand state changes made are reflected in all open windows of that bike doc) then you don’t have to worry about tracking or determining which expand state to remember.