Thanks for everyone who voted on next Bike feature. I’ll be working on “Go to heading” for next release. I think it’s a pretty nice and self contained feature, so shouldn’t take too long (famous last words!).
I’m looking for design ideas!
My default starting point is TaskPaper’s “Go to” UI:
The work part is building the fuzzy matcher and UI. Once I have that then easy enough to match against headings or all rows. I expect (again!) it will be like TaskPaper where there are a few menu commands, one for only headings, one for all rows, one for commands down the road.
As far as what will be available in this very next release, I’m not quite sure. Still working on lower level stuff, but I expect both headings, and all rows.
@jessegrosjean I like the Go > Focus Heading a lot! Very nice. I know you need to restrict things somewhat but I’d love if it included Level 3. Level 1 is the “whole thing” (or so it seems), so I’d mainly use for moving to various Level 2 and 3s. Don’t know how practical or possible this is. But already command-P is muscle memory when working with Bike!
Performance wise searching through many large rows seems to be no problem at all. For example I can open the Moby Dick test document and search the full contents with instant results.
The issue is that “fuzzy” matching doesn’t work so well when matching against rows with lots of text. It’s not a performance problem, just lots of hard to understand match cases… if a row has a lot of text then many different combinations will match something. This (plus limited display space in the results) makes it pretty hard to understand exactly why a row with lots of content matches a particular search.
On the other hand fuzzy matches work really well when matching agains “names”. Things like projects, headings … as opposed to descriptive paragraphs. So that’s the reason for the limits right now, I want to match again names not paragraphs…
The problem is it’s hard to tell what things are names in outlines vrs paragraphs. Some outlines will consist of many “names” at many levels. While other outlines will contains many longer paragraphs.
This all means… I’m still thinking. Options are:
Just search headings. This gives you control over exactly what is searched, though also means you need to use headings when you might not want to.
Search everything and don’t care about low quality matches in prose style text. Generally they will be lower in results anyway.
Add settings. Longer term I could do this via a path query (that I will be adding next). That would be very flexible, allowing you to define exactly what items you wanted to match against. It would also be pretty complex if you didn’t already know about item path queries, and we still need a good default.
This go-to-heading UI is wonderful, just what I had hoped for. Thank you!
I would also love to see this interface reused in an improved link-adding feature in the future. Currently when I want to add a link in row A pointing to row B, I must find row B (losing my context if I don’t remember to open a new window or tab), copy a row link, and then go back to row A, and paste. It would be great if I could type cmd-L (or something) and then a row palette would appear letting me easily pick a row to link to.
Ah, I got it. Realistically I’m always using levels 2 and 3 for headings. I hadn’t considered folks would be doing otherwise (silly me). But, yes, an option to “just search headings” (however that gets defined) would be perfect.
Just reformatted my most important document to use the recently introduced headings to make things work. Would appreciate it, if the go-to-heading would work with deeper-level outlines without explicetely declared headings.
What were your reasons to prefer the flat presentation?
Wouldn’t that mean the goto menu would have to list the entire text (or every single parent node) in flattened form ?
(sounds quite large and unwieldy …)
( We could probably sketch you a script to automate marking the top N levels as headings, if that sounded useful )
Perhaps some variant of roughly this kind of thing, which (N=2) sets the type of all rows of levels 1 and 2 to headings.
property pHeadingLevels : 2
tell application "Bike"
set doc to front document
if doc exists then
tell doc to tell (rows where its level ≤ pHeadingLevels) to ¬
set its type to heading
"Rows (at levels up to " & pHeadingLevels & ") marked as headings"
else
"No document open in Bike."
end if
end tell
I think eventually there will be some sort of preference for this.
I’m still not 100% sure on this.
But the reasons for going with the flat approach compared to TaskPaper’s approach is:
It means you can include parent path as part of filter.
Maybe filter operation is more understandable. Best match is always at top.
More space to show row’s text, since don’t need to indent things
It’s what everyone else does
Drawbacks:
Maybe results are less understandable. The paths are there, but hard to understand outline context of matching row.
It’s less efficient, need to build ancestor path for each row (maybe not really problem in practice, performs fine with Moby Dick test document).
I think maybe the flat approach is better when you have lots of items and you know what you are looking for? The TaskPaper approach is better when you have fewer items and want to browse?
For example in TaskPaper I can use “Go to Project” even if I don’t remember the exact project name… it shows me a list of projects and I can browse and then once I see it filter or use arrow keys to select. This works well when the list is relatively small.
Bike’s flat approach isn’t as good at that case. It shows same list, but it’s a little harder browse and make sense of. On the other hand if you have more projects then fits into the window without scrolling then it starts to be benefit to use as much space for text as possible, and allow including parent hierarchy as part of search.
It’s not so difficult to support both options in Bike, but then it’s a UI problem of which option to use and when. I can imagine a preference for these things:
Display: Flat | Tree
Include: Headings | Level 1 | Level 2 | etc
And if I added that it would probably make sense to have it be per use case … for example “Go to Row” maybe only wants to go to headings, while 'Link to Row" (I like that idea) probably wants to include all rows in outline.
I’m leaning in this direction. Default to all rows shown flat. Allow customization through preferences. The only issue being that it will take more time, and maybe add some extra complexity to UI.
Any thoughts on that option to add customizations?
When I go to a collapsed heading, it remains collapsed. I had assumed that going to a collapsed heading would automatically uncollapse it. What do you think?
The latest preview release adds settings for the “Focus Heading” choice view. You can use Bike outline paths to select exactly the rows that you want to see. Unfortunately these outline paths are undocumented and very much in progress. I don’t expect to give them full attention until Bike 1.15. In the meantime it shouldn’t be too hard to modify to your liking.
The default outline path for “Focus Heading” is:
//@type = "heading" or @level <= 1/ancestor-or-self::*
You can change @level <= 1 to @level <= 3 to include three levels of outline items.
