Historically speaking, I have the impression (only an impression, though) that since tags weren't properly developed features until 5.0, users would try using supertypes, which have been around longer, to do things that tags would be used for today. Correct me if I'm wrong here.
Quote: So my question is, how do you plan to use filtering? The paradox is that, the more features PB contains, the harder it makes sitting down and designing a Brain that optimizes the use of these features. It's like being spoiled for choice. That doesn't mean we should have fewer features, but that we need more examples of Brains using these new features so we can start generalizing and laying down design guidelines where possible. One place to start with filtering is to consider temporary vs permanent filtering. I agree that adding a temporary thought type to solve a temporary problem is not the way to do it. Filtering on tags, rather than types, is how I'd prefer do it. As you say, assigning types needs a lot more planning. Adding and removing Tags can be done on the fly. Luckily we can assign, remove and change thought types and tags en masse. Links - don't even think about them. This gives us not fewer than six potential ways of filtering Thoughts: Now with the Report filtering toggle it suddenly becomes easy to select the by type; by tag; by date; by name (Extended/Advanced Search, Instant Search, Crawl Plex); by content (Extended/Advanced Search - Label, Notes, Files) (by link type - visually only).
Although we can't add Instant Search results to selection (pity!), I included it here because we
link a key (parent/jump) thought as a kind of tag/alias/keyword thought, and find it if we need by Instant Search, even assigning all instances of this its own type, tag or in-name label to facilitate searching.
intersection of two tags, as shown here. Either of these tags could have been pre-filtered by type. The intersection result can be added to selection (via the Edit menu) then used as a filter for Advanced Search Results, if need be (when they get around to fixing that #$%^&* bug). Considering that Advanced Search can perform Boolean search on multiple tags and be limited to a specific Thought type, that's not bad! Inverse filtering is the dark horse and should open up all manner of extra possibilities. Substitute Crawl results for Advanced Search, and we should have sophisticated ways of delineating Thought trees.
Quote: Another possible solution is to use a tag for connecting thoughts. This has a similar disadvantage to the "Connect" type, but doesn't consume a Type for that thought. I'm just wondering why you need separate connecting Thoughts at all. If you could get by without them, you wouldn't need to worry about consuming another type or assign a separate tag. One solution I've started using lately is applying . In set theory terms, Thoughts common to two branches would be termed the intersection of the two branches. Venn diagrams can be helpful here. If each of these has two tags (i.e. each branch has its own tag, and the common Thought is tagged with one for each), this does away with the need for a separate connecting Thought with its own type or tag. This cannot be done by types as a Thought can have only one type. However, there's nothing to stop you from creating a third tag to apply only to such connecting Thoughts, to help you define the boundaries between trees more clearly
Quote: Will you just work from the report output, or do you plan to work in the plex while filtered also? If so, do you have any other ideas on how to deal with connecting thoughts? Finally, can you think of a way to overcome this programatically (ie a feature request)? I don't think one can actually work from Reports results until they have been added to selection, then maybe assigned a temporary tag. We can't change tags or types directly in Reports without doing it via Selection. After all, Reports is just that - a static report. I certainly plan to work in a filtered plex, and as I expressed to Harlan here, I think inverse filtering will prove more useful to me than direct filtering, for the following reason. When we select a Thought in the Plex, it's commonly because we are interested in one or a subset of its child Thoughts. Now if the Thoughts we don't want to work with can be filtered out using a particular tag or type, they can then be masked in the Plex so that what we are left with is the complement (set difference) of these child Thoughts. Another way to achieve this is to use Advanced Search to find all child Thoughts in this set that fit a certain criterion, Add these search results to selection, tag them with a temporary holding tag, inverse filter by this tag, then they are excluded from the Plex. If it were simply possible to move focus from Plex to Reports with one keystroke, analogous to F5, it would be a simple matter to create a macro to do all this in step. one
PB 220.127.116.11 on Windows XP, J-1.6.0_17