Navigation in TaskPaper 3 is pretty awesome, I’m glad to say. One extra feature that would complete the usefulness would be a way to jump back to previous locations within a document.
My taskpaper files tend to be long because I love the way you can bring diverse bits of information together by clicking on tags or searching using tags.
This means that at any given stage I am involved with a number of different parts of the same document where one might otherwise have separate documents open.
If there were a way to go back to an earlier location by means of a shortcut or history list, without having to remember what that location was, that would be really neat.
For consideration.
I second this! It would be super useful for very long TaskPaper files. The ease, simplicity and familiarity of back/forward buttons would be great. The history list would not be of much interest to me.
Also, I would say the back/forward buttons or history list would only need to track clicks to the navigation pane. Cursoring around the actual text would not be tracked.
I agree this seems like a logical thing to add.
I’ve implemented (a few times I think) during the FoldingText development process, but not sure I ever exposed the function in the UI. I think the state to track is:
outlineEditor.hoistedItemoutlineEditor.focuseditemoutlineEditor.itemPathFilter
So anytime any of those items changes a new history item would get created. (for item path filter would need to coalesce changes when typing in the search field).
Can anyone suggest apps that do this sort of history well. I know about web browsers (page history), and text editor (open file history). But I’m wondering more about an apps that keep a history of different “views” of there document model?
Another question… what does the View menu look like. Right now we have two related commands:
- Go In
- Go Out
Adding
- Go Back
- Go Forward
Makes sense, but there’s some redundancy. And likely a bit of confusion for new users. Thoughts on if this is a problem or not?
I don’t know if there is another way to express Go Back and Go Forward (“Navigate Back” and “Navigate Forward” maybe?).
Another option is to rename Go In and Go Out. You may have already dismissed this, but what about using “Focus” and “Defocus” or “Unfocus”? This follows conventions of other popular task management software. Other ideas are “Descend” and “Ascend” which I like very much. Or “Step Into” and “Step Out” but that may only make sense to programmers accustomed to debuggers. I think I’m out of ideas at this point 
Skim (free PDF annotator that’s been around a decade or so) keeps a short history (5 pages or so) of navigation in PDFs. It was probably designed to allow easy navigation between text and references in academic papers but it’s another model to look at.
Great that you’re considering this. I agree that the UI issues are very important.
My original post had 2 different approaches.
First was a “back button”. This would be a shortcut or button that would step back through the previous locations of the cursor in the document, with perhaps a forward button as well. Like the arrow icons in the toolbar of windows in the Finder. You could limit the number of backward steps, because more than 5 is probably not useful.
Second is a history list. This is more elaborate, with a consequent risk of over-engineering. Most of the models I can think of deal with multiple documents rather than locations within a single document. They also combine History with a Favourites menu. So, Trickster, Default Folder X do both History and Favourites rather well, which you would hope for since it’s their primary job.
Another model is nvALT. Files appear in the left hand pane according to how recently they have been modified. So in Taskpaper, a shortcut like Cmd-L (which gives the project list) could give the recent locations with the most recent on top. Or perhaps there could be an option to show recent locations in the sidebar as an alternative to the project list.
Differentiating from Hoist is important, because Hoist is doing a very different job (which I really love about Taskpaper). Why not just call the commands Hoist and Unhoist. Omnifocus haven’t got those names protected have they?
No… I’m sure OmniFocus wouldn’t care. But does OmniFocus actually use the terms “Hoist” and “Unhoist”. They are the traditional outliner app terms for this sort of thing… but I think Outliner apps and there terms scare away a lot of people. I was trying to come up with simpler terms by replacing “Hoist” and “Unhoist” with “Go in” and “Go out”.
Just had a thought that might provide a simpler way of achieving the practical benefits of this proposed improvement, which is to be able to navigate back to one or more parts of the TaskPaper file that you were previously working on. Suppose that, instead of a list of locations or a back button, you were able to open multiple windows on the same file and have these listed in the Window Menu. By Command-~ you can cycle through the different windows showing the different areas of the file you are working on. Or by using the Finder commands to show Mission Control or Application Windows you could see all the Windows on the same file at the same time (along with the Windows for other files you have open).
1 Like
Interesting idea! I do have “multiple views” on my potential todo lists, but I hadn’t thought of it as a form of history navigation. I agree that might work pretty well. I think in the end both options might be nice. But now multiple views might be the more valuable one to implement first. Not sure when I’ll get to this, on other things now, but thanks for the idea.
You’re welcome. I use TaskPaper a lot, and it is mostly so frictionless, and anticipates the user’s needs so well, that where there is a possible improvement, it almost suggests itself.