Is there a way of moving past the first matching note for outlines where there are several matches with the note $Name ? As an example consider the following demo. I’ve coloured the two notes of interest “Note 10” and “Note 1000” in red for visibility.
I would like to match Note 1000 but it’s been a long day and I’m too lazy to type in all the zeros. So I go ahead and simply type 10 in the window. The blind typing does a good job and matches “Note 10”.
What I would like to do quite often is move past the first match and go to the 2nd match (or 3rd etc…). This situation arises when I would like a quick match for notes in a container who’s names that are quite similar. Typing in a long name with all the characters to ensure a perfect match with a specific note is tedious and prone to error.
For more complex matching across containers I find the rarely discussed “Filter” function very useful.
This is overkill for a one-off quick search through matching notes in a given container.
Tips welcome. I might suggest this as a feature for future releases if there is no good workaround.
With regard to blind typing. The matching seems to require at least 2 characters to work. If I have “alba” as a note, “a” will not match, but “al”, “lb”, “ba” will. Notice, the matching is “contains” not “begins with”. So in your example, you must have at least “10” to get a match. And “100” or “000” are the minimal strings needed to find “Note 1000”, I believe.
Concur, the concept of the mechanism—as currently implemented—is that after the low-end cut-off of 2 characters you type enough characters to gain a single (or closest match).
So you are, albeit unknowingly, actually asking for a slightly different blind typing handling mechanism where it invoke a list of matches after N typed characters. I’d suggest you mail in a feature request explaining the use case.
In the meantime you have Filter and find bother of which give much (all?) of what is being asked for.
Best to summarise the desired functionality first. The intention is:
select the first note Name which matches the already typed characters (minimum 2 characters is ok but consider also simply one character e.g. first note starting with “w”). Question: is the position of the currently selected note taken into account or does the search always start from the “top” ?
move to the next match based on a TBD keystroke
also provide the option to move to the previous match again (e.g. backwards) should you select this
In terms of keyboard shortcut it should be a key simple combination for speed which is not likely to be used in the search term itself.
I like arrows but these need to be differentiated with the Expand and Collapse options in Outline view. If I simply use the right arrow now with a container highlighted the container and it’s contents are expanded (e.g. same functionality as the Cmd + Option + Right Arrow). Cmd-G and Cmd+Shift+G would we consistent with the Devonthink mapping.
Makes sense to me, @mdavidson . I believe the search “starts from the top” and scans all visible notes in the outline (e.g., any notes viewable depending on the expansion state of their containers) – so the result is “first found from top”. Would a different algorithm make sense? Not sure.
I agree with @mwra – using the same shortcuts for next / previous available in the Find tool context would make sense also in the blind typing context, for consistency.
Query: we are discussing enhancing blind typing. Is it worth stepping back and recognizing that we have three overlapping methods to find notes: “blind typing”, Find, and “Use Filter”. Is it sufficiently clear to readers (both new to Tinderbox and long-time adepts) what the different use cases for these methods are?
Concur. This doesn’t diminish @mdavidson’s request in any way, but I do think @PaulWalters is right to point out the unintentional complexity created by accreting process features without regard to the user experience in wider scope.
Seasoned users are prone (guilty!) to assume we just ignore the bits we don’t want/use/like. But, helping here is a constant reminder that to a newer user there can be a blizzard of choice all seemingly of the same merit but with not much to explain why there is such choice. It may just be a case of better documentation derived from stated design intent, but I think the point above is very valid, even if talking myself into more documentation work
For the shortcuts I believe we can converge quickly. I’ve checked as a reference what OmniOutliner does and CMD+G and CMD+Shift+G are used as well.
Now for the functionality:
I don’t see Blind Typing being confusing even to new users. It’s everywhere including DevonThink, the Finder, OmniOutliner and I assume other similar programmes which display lists of files or notes.
Similarly the Use Filter functionality will be familiar to users accustomed to outlining programmes or more generally mind mapping programmes. Essentially it says show me all the branches or rows with the following content determined by the actual filter expression. The outline structure is shown and helps the user understand where within the whole structure the matching notes are located. The challenge for new users will be more the syntax e.g. $Name.icontains(“my text expression”) instead of just inserting the text expression itself. For power users access to filter expressions is very powerful, for the TinderBox beginner likely a step too far. I think uptake would be improved if the Use Filter defaulted to a $Name.icontains filter function and let the new user type in the search term with power users still able to add their own expression.
The general Find I find more ambiguous and slightly overlapping with the others. It acts like a specialised Agent, retrieving the notes matching the expression (with 3 selectable attributes), sorting them in a user specified way and displaying the result in a separate window for the user to click on and discover. Personally I don’t like the way this Find takes you away from your original note and also leaves the Outline in a different state even if the find action is abandoned. It could be improved taking inspiration from the Ziplinks. For instance selecting a note opens a temporary window and displays the content of the note for the user to decide what to do with it (go to this note, take note of its contents, open in a new tab etc…)
In short there is room for the 3 find versions. The first two are very well defined and a user will understand the functionality based on experience in other apps - the 3rd which I believe is the older kid on the block would benefit from some rethinking e.g. hover windows and perhaps some thinking about the functionality (how about related notes for instance ?).
Interesting. #2 is something I’d not seen before it arrived in TB so I guess familiarity, like intuition, is quite subjective based on experience. That’s not push back - just wry amusement: I’ve used a computer all my working day for 25+ years so have seen a fair about of apps along the way. Admittedly, I’m not a big user of mind-maps and to-do outliners (they’re fine, just not a category I know).
Likewise, I had no idea DEVONthink and OmniOutliner had blind-type as I’d not seen it documented. By comparison, Find does make sense, being closer to long standing apps like email clients.
This has me confused. ‘Ziplinks’ describes the [[ method of creating text links. The window that pops-up when using the ziplink method is an autocomplete. Are you perhaps referring to the window shown when selecting an item in the text pane Links panel if it is open in v8.7.0+?
I would not consider what Finder does as anything more than using the first character typed (ignoring the rest) to the first file found in a view window that begins with that character. And there is no visual feedback showing what you’re typing.
DEVONthink has a search box (disarmingly simple but rather sophisticated in DEVONthink 3). I don’t think that would qualify as blind typing.
To clarify the ziplink reference… you are correct I’m referring to the window shown once the item is selected. The window when applying Find is a list of matching Notes which has some similarities to the list items in a Link Panel. Adding a pop-window would allow the user to see the full contents of the notes before deciding whether to select or not.
Familiarity depends on the user… no argument there. My point is that Outliner and/or MindMapping users will be in general be familiar with Filtering and displaying the matching notes/records within an overall structure containing these notes/records. As such the results of Filter should be familiar. In the case of MindMaps I have the impression that the user community is fairly large.
There is likely a misunderstanding in the case of DevonThink. I was not referring to the search box (which is closer in functionality to Find) but to the interaction with the list of files which is similar to the case of Blind Typing we are discussing.
As an example consider the following constructed list of files in my Test Devonthink Database.
You’ll see that the starting point is the Group PDFs. Now I want to select the file T2. I type (blindly) T2 and the selected file bar moves quickly to the file T2
Now I decide I want file T33 instead. Typing T33 in the same window does the trick.
It’s a similar behaviour for the Finder (again with respect to the file listing not the search box). Same example this time in the Finder
I quickly type T2 and the Blind Typing matches the file, skipping over T1
Etc… Users who are familiar with this blind typing matching in both these applications should readily understand how the augmented Blind Typing in TB we are discussing can be used (and the Finder user community is huge )
Yes it does that in Finder and DEVONthink. IMO and experience the feature is clunky, kludgey and a mess because the typing quickly spills over into unwanted opening of documents and windows.
Horses for courses. You like what it does in DEVONthink, I avoid it like the plague.
In any event, the point here is what Tinderbox can and could do.
One welcome difference with Tinderbox for the Blind Typing functionality is the display of the search string during typing. This provides the user with useful feedback on what the search scope is. Up to @eastgate what the options are for improved search.
Now for ideas to improve the general Find function building on some of the first exchanges. As as user I would like more feedback on the notes matching the query before clicking on the note and displaying the full note in TB. I find the pop-up display in the Links Panel very useful in this sense as it provides a preview of the note that is linked. Perhaps something similar is possible for the Find. Below a visual example of what I’m looking for.
Here is another idea for improving Find that I put up for discussion. Consider the following test case
Note 3 and Note 7 are located inside the (unexpanded) containers Note 2 and Note 6 respectively. I now search for Note 3 using Find and “3” as the search term. Works as it should - both Note 3 and Note 13 are listed. The Outline structure on the left has not changed. The Containers of Note 2 and Note 6 are still not expanded.
I now click on Note 3 in the Find pop-up listing. Note 2 is expanded to reveal Note 3 and Note 3 is selected.
Fine. I decide I don’t need Note 3 anymore. However, now the Outline structure in the left window has changed as a result of the Find action. I cannot go back to the Outline structure as it existed before the search once I’ve found and consulted Note 3.
For this simple example case this is not a big deal. For larger TB documents with containers nested several levels deep this expansion and completely new outline structure on the left feels quite jarring and (for me) interrupts my thinking context at that moment. In this “let me consult another note and get back to my previous writing” mode of mine, a pop-up or other way of communicating the contents of the Find notes would help a lot.
So you want the action of “Find” to at some point snap the outline back to the expansion level that is was before you used “Find”? Does your example suggest that the snap-back should occur when you select another note in “Find”? Or does the snap-back occur when the “Find” pop-over is closed? Or with some other event?
I know you said the current behavior is jarring – I assume because you are using “Find” to locate a note to look at momentarily and then return to the prior focus and expansion state.
But that’s not the only case. I generally use “Find” to move some place else in a document and continue from there – or to use the other features of the “Find” popover. I would find it equally jarring to have everything in the Outline view snap back to where it was when “Find” was closed.
@PaulWalters thanks for your perspective. I also use of “Find” to move to different parts of the document so I can relate to your use as well. My proposal is to augment the current functionality so that “Find” can accommodate other use cases.
Taking it a little further and focusing on the functionality I see at least three use cases for “Find”:
To move to a new note discovered in the list retrieved from “Find”. In this case the user simply wants to move from the current note and immerse him/herself in the new note with full hierarchical context available in Outline view. This functionality already implemented in “Find”.
To assess the notes retrieved from “Find” and decide whether to move to this note (or not) based on its contents. This is partially implemented in “Find” as the Pop-up list provides the $Name, first line of $Text for the user to decide on which note to click. If you decide to go ahead then you are back to the use case 1 above. However, as soon as you click on one of the notes in the list going back to the previous outline, even if you push “Esc” afterwards to dismiss the “Find” pop-up. NB: The zip-link pop-up window provides a full text view of the note text compared to one line for the “Find”
The use of “Find” to consult notes matching a query and return to the original context and note
I would argue “Find” function 1 is covered, function 2 could be improved by providing more information about the note before selecting and the option to return to the previous state of things and functionality 3 is not (yet) available.
)
