I’m not sure if you take feature requests. Your apps seem very minimal on purpose. They have a great UX.
But I need a toggle for hiding/showing completed tasks.
I don’t want to delete them or move them to a new place.
I need to look back at completed tasks and subtasks (in context) at times, but I do not want to see them most of the time. Less overwhelming to look through my notes and tasks that way.
I prefer Bike over TaskPaper. It just feels better. But even in TaskPaper, it seems like the only way to do this is with a (not @done) search. And it’s quirky to go between working on tasks for different projects and peeking at completed tasks.
it is a good point.
today I have a line called DONE and when I complete a task I drag it to that line. because it bothers her to just be crossed out with the others and at the same time it’s important to have a history.
Bike 2 (in progress, not sure when will be done) should bring more options for handling this.
First it will support custom stylesheets. So you could for instance change the font size and colors of completed tasks to make them minimally distracting, while still also seeing their presence in your outline.
I think (though not 100% certain) that Bike 2 will also add TaskPaper style query/filter UI. So you could use not @done to hide your tasks.
I don’t think that I would like to have a generic “hide tasks” command. To me it makes more sense to use a user defined query/filter for that behavior.
In the end I expect I will include outline filleting. I do have it in the current codebase. At the same time I also feel like it’s a non-perfect feature, since it somewhat unpredictably hides parts of your outline without any good indication that something is hidden. I can be quite confusing.
Alternatives that I sometime ponder and start to implement are:
Instead of completely hiding I just change representation of non-matches. Maybe make them really small for example.
Another thing I don’t love about filtering is that it is somewhat destructive to your current state workflow. So if for example you are working in some part of your outline and click a tag to filter… it’s not particularly easy to get back to your old view. That’s made me wonder about making search into a separate non-editable view that “pushes” over the current view (like on simple iOS navigation). Then you could always “pop” to get back to your last state. Or if you wanted to edit a search result then you click it and that’s the navigation step back to your original outline.
But most of the time I think that I should implement TaskPaper style filtering and I could add the above features later if I wanted… and that’s where I am at the moment.
Hm. I’ve always felt that the search bar and/or highlighting results is a good indicator of filter status. I don’t imagine the competition does it in a wildly different way.
As for current state workflow…can’t really comment on that because I’ve never found it an issue. Can’t speak for others, obviously, but when I really work on an outline, and that requires jumping to different sections, and filtering, I’m either working with 2 windows, or I’ve already forgotten what I was doing in the first view anyway
Bike is more optimised for thinking, drafting, and document preparation workflows than TaskPaper (which clearly shines for working fluidly with nests of tagged todo lists).
Where your project management spans everything from gathering and shaping thoughts to drafting and sharing project documents, Bike is probably the instrument.
( Formatting and persistent hyperlinks to individual rows, in an HTML format which is accessible to standard tools )
