I’m using TB also as an outliner for a large document of mine and face the following usage case which I illustrate below in simplified form. My aim is to keep very close the ideas, draft text and finally the good quality (e.g.) reviewed text so that I can quickly go back and forth and update accordingly while keeping in mind the structure of the document.
In the general the hierarchy will be complicated with various subheadings going to a depth of up to 4 levels. My question is how best to for instance only part of the hierarchical tree (e.g. only the ideas for each chapter, subchapter etc… or only the draft text + good text to check whether I captured everything) ? NB that the illustration is a visual representation of a very simple outline. I mainly need this capability in outline mode.
Can you tell us more about the big document, and about your concerns for this project? This seems straightforward, but of course one can imagine lots of approaches!
Here a simplified concocted example which I hope helps. You’ll see that the agent retrieves a “flat” view of the notes matching the query. I’m looking to preserve the same hierarchy with various prototypes turned on or off in the display. This allows me to compare for instance my ideas with the draft text all with an outline structure of the document. ExampleHierarchy.tbx (77.3 KB)
As far as I know there’s no a way of doing exactly what you want, because aliases can’t have children and there’s no way to create new notes with action code. So you can’t automatically create a hierarchical structure that mirrors another hierarchical structure.
However, you might try @prenez’s approach here. This would not change the hierarchy itself, but would allow you to display any combination of idea, draft, and final text in the preview window, and switch between them very quickly.
Thanks - the `@prenez approach certainly captures the idea of displaying notes of a certain type while maintaining the outline/hierarchy context information. I’ll give it a try.
To me the ability to turn on or off elements of the note structure is of general utility for tasks such as writing, outlining and general information management as it combines essentially the output of a query (e.g. similar to agents) to filter the notes with indications of context for each note based on it’s relative position in the outline tree. This would complement other visualisations of information provided by TB including Maps, Trees, Outlines and Attribute Browser.
Are you taking about something akin to org-mode’s sparse-trees? As in, you issue a query of some kind, and the notes that match that query are displayed while the other notes are hidden?
Sounds potentially interesting, but I don’t know how well it would mesh with Tinderbox’s existing “visual semantics”.
Thanks Galen. Not sure about org-mode’s sparse trees as I’ve never used it. However the way you describe is what I’m looking for with the addition that the hierarchical structure should be visible e.g. you prune the outline based on the query.
For those of you who know in OmniOutliner this feature is called a “filter”. Let me illustrate. Here an example of an unfiltered test outline
After creating a filter that looks for a string called “Wah” I get the following with the notes containing this string and the outline structure still visible for context.
How to translate this into TinderBox semantics and context is an important question. My preference would be to create a new visualisation or an addition to the outline mode that has this functionality. The data and notes are still there - they are just displayed or not displayed depending on the filter. This could be implemented for instance via a Boolean attribute for each note whether to display (or not) in the outline. The attribute can be set or not using the usual Agents, Rules etc…in the spirit of TB and building on the TB code base. Another approach could be to allow Agents to collect aliases also with hierarchy and display them.
I was thinking mostly of this option in the outline view and that is where I see a more ugent need. However, thinking about it a bit longer it could work for most of the other views as well (Map, Chart and Treemap). Especially for Treemap it recall a request some time ago in this forum to exclude certain levels. By setting the $HideMe boolean you could address all of these elegantly.
Remains the problem of unhiding and also of the user knowing that he or she is looking at a subset of the whole hierarchy. To me the setting or unsetting of the $HideMe boolean would be done by an agent, stamps or editing the attribute by hand. However, the act of actually hiding notes from view should be done by the software itself (e.g. a menu command such as filter notes) which applies the filter and provides a visual clue that you are looking at a filtered subset. You then just turn off the filter once finished and all notes (including those with $HideMe on) are redisplayed again. You could also imagine at the TB software or menu level predefined filters (e.g. up to certain depth, a particular setting of a given attribute etc…). An example is given below of the filters of OO.
Some ideas you can see in the OO illustrations in my original post. Notice the stored filter (called wah) in the orange-brown box to the mid-upper left. You can store multiple filters with different criteria there. The white bar above the result with the name of the filter indicating that this filter is being applied and provides a visual clue that we are looking at a subset. You can cancel the filter simply through a click and all notes are instantaneously displayed again.
Yes, outline filtering would be great. This is a core feature of org-mode and Taskpaper. OmniOutliner only added it in version 5, and I recall reading something from Omni that said it was by far their most requested feature.
Outline filtering is less necessary in Tinderbox than in those tools because Tinderbox agents cover many of the use cases that those other tools use filters for (e.g., creating a view that shows all unfinished tasks grouped together). However, as you point out, adding filters to Tinderbox would genuinely add functionality — specifically where a hierarchy and/or note order should be preserved in the filtered view.
Concerning implementation, I don’t think that handling this via an attribute is the right way to go. Placing visibility at the attribute level eliminates the possibility of maintaining different filtered views concurrently in different tabs. I could easily imagine that you would want to have one tab open with the “ideas” filter active, with the tab next to it having the “draft text” filter active. So in my view this should be a tab-specific view option, in exactly the way that outline columns are.
We all agree so far that filtering outlines would add useful functionality - that’s the most important conclusion. Again the reasons are to use hierarchy and the selection of notes within the hierarchy/outline as an additional tool to support writing and information management.
After thinking it through I agree that Agents themselves are not the best approach mainly because of the need for different filters for different purposes and there is no need to create aliases. Instead why not use something like the query syntax of Agents in a window similar to Explode to set up the conditions for a match (hide, don’t hide) and create a new Tab view with the Filtered view. Storing the different Filtered Views in a similar way to Stamps would also be extremely useful.
The eventual implementation of this feature of course depend’s in the end on Eastgate's willingness and vision on the subject. I have the impression that the code base with Queries etc…is already fairly advanced to support such functions but who am I to say this:slight_smile:
To me, this feels more like a separate view type than something extra to load onto the Existing Outline/Column view. I’d suggest that regardless of wherever the posited feature might be added that there’s an easy ‘off’ button so new users don’t end up hitting here or support because their documents content has disappeared. I’m unclear as to how well this scales. How big an outline? How deep into the outline?
Visual styling is more easily done with prototypes. In Tinderbox, italics imply an object is an alias and so is unsuitable as a style for an outline title. The app offers loads of ways to indicate state/style so adding text styling of titles seems to offer little for the engineering doubtless involved.
Could you provide an simple example/test TB document to illustrate ? I haven’t worked much with HTML export so far to be honest. My impression based on the @prenez example is that the export HTML is a powerful way of visualising the text and will allow filtering but doesn’t allow me to edit the individual notes in the filtered output.
General thought on this. It’s a bit of a drag to have to hunting for the base prototype just to turn its boolean attribute on or off.
A “button note” would be a solution, if you make a button bar in the outliner ui that would give easy on/off two state buttons. The buttons would point
at a particular notr and attribute. This would be a UX improvement. The notes contain, after all, information that the UI could use.
This would be a powerful feature and not difficult to create. The hardest part would be getting the UI design just right. Anyone want to help out with this?
Remember the old sliding drawer in OSX? This might a great use for it, rather than a complicated rejigger, even though its generall discouraged these days.
Why not open the prototype as a stand-alone window and use it’s KAs to access the toggle. Saves loading more UI?
I still think this use case, of filtered outlines, deserves a tab type of it’s own if taken ahead. I say this because if the functionality is edited, other filter-related feature requests will follow making the Outline over-copmlicated in terms of possible/forgotten settings. Even if both outline-based, the existing outline (the canonical view) and the filtered outline are leaning towards different tasks. That’s not arguing against the new use case but rather that implementing it as a new view type would avoid legacy/complexity issues.
Possible slippery slope. If we had a “normal Outline” and a “filtered Outline” as two distinct tab types, then someone will want a “normal Map” and “filtered Map” … and so on.
So maybe any tab should optionally be filterable with a smart-search-like dialog like the one @mdavidson posted above?
Possibly for a doc with 20-30 notes. But take a real-world doc with 000s or 0,000s of notes and deep nesting and I don’t think ‘just’ filtering will scale well.
I’m not suggesting a filtered outline be called that would be confusing. However, my viewpoint is shaped by a lot of time helping new users. I think this filtering is actually not starter stuff and more than the wonderful Attribute Browser even if the filter concept, in isolation, is simple. In the past I’d have agreed with wanting these extra controls font and centre, especially if for a feature I would use. Over time, and watching the wide range of style of use and degree of app experience, I’m minded to adopt a more complex strategy so as not to overload the new starter. Still, I’m happy to be wrong and what ever comes to pass, i’ll still be testing and documenting it.
I don’t understand this — a document with 20 or 30 notes wouldn’t really need much filtering, since you can see the whole document on one screen. Filtering is a core feature of many outliners. What do you feel wouldn’t scale well?
