Hoisting, multiple trees, tree clutter - User feedback welcome...

[pawe]

This thread is getting calm, so I just wonder if the idea of filtered trees is still somewhere on the roadmap?

[kinook]

It's on the list, but no ETA for when it might be implemented.

[Daly de Gagne]

Originally posted by kinook
It's on the list, but no ETA for when it might be implemented.

Of the various requests that have been made for changes to UR, the request for hoisting and/or other mechanisms to deal with tree clutter have been among the most consistent. It seems that almost everyone who has written agrees on the need for this kind of capability.

I wonder why it is, given how responsive Kinook has been to other suggestions, that there is still no firm commitment on hoisting, etc.? It has been identified as something that is seen as important to more effective use of UR, and it is a feature on other programs.

Is there any possibility we could see it on version 3?

Thanks.

Daly

[kinook]

Not in v3.0. There doesn't actually seem to be a lot of consensus on the best way to implement it. And implementing it in a fashion that accommodates the various needs and doesn't hinder overall performance will not be trivial.

Multiple tabs, favorites, and auto-collapse of siblings/auto-scroll to top allow you to approximate this feature already. Yes, this isn't true hoisting, but we have to balance the level of effort for this enhancement with many other requested features that can't even be approximated.

[xja]

Filtering the tree is my most critical need and cannot be approximated in any useful way. At the VERY least, let us hide items marked Completed! If you are going to claim to have Task related functionality, that is one of the most basic features.

[pawe]

Well, this is not really about filtering items in the data explorer window, but about showing "filtered child items" while browsing the tree:

If we could "stick to a search" while browsing the dataexplorer window (browsing the tree - but the search results window remains open instead of the child item window), this would not filter the tree, but be an equivalent of filtering the child items, given that the search is "restricted to the bold item" in the dateexplorer window.

An example: a software-database with a categorizing tree, each item has different attributes like "freeware/shareware", "X64-compatibility" etc. With the given feature above, it is easy to define a search and browse through all "x64 compatible freeware", without having to click forth and back in nested trees and searches.

[Daly de Gagne]

Originally posted by kinook
Not in v3.0. There doesn't actually seem to be a lot of consensus on the best way to implement it. And implementing it in a fashion that accommodates the various needs and doesn't hinder overall performance will not be trivial.

Multiple tabs, favorites, and auto-collapse of siblings/auto-scroll to top allow you to approximate this feature already. Yes, this isn't true hoisting, but we have to balance the level of effort for this enhancement with many other requested features that can't even be approximated.

Do you mean there doesn't seem to be much consensus at your end, among the programmers, for how to implement it?

Among the users there is as much consensus as one is likely to see on the need for a new feature -- and the consensus seems to be that hoisting is the way to solve the problems of a list getting too long and a PITA to work with.

I understand the need to balance requests, and time benefit ratios in terms of implementing them. However, if you were to take a poll on the weight of each requesst among users, I suspect hoisting would be close to the top.

Approximations are work-arounds by another name -- and in this case for many of us, who have been working with hoisting since the days of DOS, the work-arounds are not very satisfactory.

Hoisting is the best way to get a clear focus on a very specific part of the outline in a hurry.

I do not understand how a hoisting feature would interfere wtih program performance. Hoisting is lightening fast in programs that offer it, and other aspects of those programs seem to be fast as well.

Please, please seriously reconsider your position on hoisting. I was seriously hoping that after the lengthy discussion here that hoisting would be offered in the next major upgrade.

Thank you.

Daly

[kinook]

What I meant is that there are varying ideas/preferences for what hoisting would actually provide and how it would be implemented.

Some actually want a filtered tree (where hoisting could be considered one type of a filtered tree); others want or independent trees in tabs; etc.

Even in the case of "simple" hoisting, there are many questions about implementation: should logically linked items not in the hoisted tree be included or excluded? Should searches be restricted to the hoisted data? Should favorites also be filtered to show only hoisted items? When/how to hoist/de-hoist? Should hoisting automatic (ala auto scroll/collapse) or manual? Should multiple hoist levels be supported? How does multiple tabs play into hoisting? Etc.

To implement in a way that accommodates even half of users' preferences and doesn't sacrifice performance would take several months of effort (at least), so it just can't be done for v3.0 (one of the drivers for v3 is Vista support and Vista is now available to consumers).

[igoldsmid]

UR V3 (in beta) has several VERY powerful new functions.. One of them is the ability to copy links/uri's to Items in the Tree, using the new UR:// protocol.

Given this, and given that any tree structure after a while is going to be "cluttered", and not only that, a tree structure is not at all good at enabling you to see very many of its Item's relationships (and especially not the distant ones) - I am using a graphical mapping application as a front end to UR V3. I am using Personal Brain (V4 beta) - although its possible to add any front end like this to UR now (e.g. some other mind mapping program) - which enables at least two very powerful "extensions" to UR:

1) - I am using a Personal Brain map as a graphical navigator for UR's Tree - which enables me to more easily see/locate, and navigate to any number of specific locations in the UR tree.

2) I can create many further relationships, AND Relationship Types between (virtual UR) Items in Personal Brain - that wouldn't be easy or even possible to represent in a useful way in UR.

IJG

[Daly de Gagne]

Originally posted by kinook
What I meant is that there are varying ideas/preferences for what hoisting would actually provide and how it would be implemented.

Some actually want a filtered tree (where hoisting could be considered one type of a filtered tree); others want or independent trees in tabs; etc.

Even in the case of "simple" hoisting, there are many questions about implementation: should logically linked items not in the hoisted tree be included or excluded? Should searches be restricted to the hoisted data? Should favorites also be filtered to show only hoisted items? When/how to hoist/de-hoist? Should hoisting automatic (ala auto scroll/collapse) or manual? Should multiple hoist levels be supported? How does multiple tabs play into hoisting? Etc.

To implement in a way that accommodates even half of users' preferences and doesn't sacrifice performance would take several months of effort (at least), so it just can't be done for v3.0 (one of the drivers for v3 is Vista support and Vista is now available to consumers).

Kevin, I may be missing something here when you are asking the questions about what is included with the hoist.

It seems simpler to me. It may help to keep in mind the main reason for hoisting -- to isolate a particular part of the outline, so it can be worked with, without having the visual interference/distraction of the rest of the outline.

A hoist pulls out the part of the outline selected. It is limited to the selected portion. If there is a logically linked item in the hoisted portion, then it should show.

Most hoists work as a toggle hoist/dehoist. That means there is only one hoist at a time, so multiple hoists, at least in the initial stage, shouldn't be a question.

Keep hoisting manual, at least in the beginning.

I wouldn't worry about filtering favourites in the beginning. I suspect one would be less likely to have need to view the favourites list when in hoisted -- as a feature of hoisting a hoist related filtered view of favourites can always come later.

Yes, it would be helpful to be able to save a hoist to a separate tab or a views menu.

Thanks, Kevin, for your patience in pursuing this discussion.

Daly

[wordmuse]

hoisting in the old days (and maybe in other programs today) meant simply this: I take a part of the outline and temporarily call the node I'm on "root." Nothing else. Search doesn't matter. Filters don't matter. All I want is to visually see from my new "root" down.

In fact I really don't want other stuff. I just want an uncluttered, manually toggleable ability to temporarily specify a soft root, and then to release it and go back to the original root.

I'd like to be able to do that in whatever tab I happen to be in.

If there's no other way, you can even de-activate all the related panes while I'm in "hoist mode." I dont' need to see children, parents, or search. I wouldn't mind being able to, but the main thing is to be able to focus from the soft-root down.

Nothing more.

I don't know about anyone else, but this would be a wonderful beginning of this capability.

I guess this is tough to wrap your arms around, but for me, it's really that simple.

Hope this helps a little bit.

Regards,
Bal

[Daly de Gagne]

Bal, I agree with you completely.

Isolating one specific node so it is like the root node, and all the subtopics that fall under it, is really what I mean when I talk about a simple toggle hoist/dehoist.

Some of the other suff Kevin mentions would be nice -- but it is not essential to hoisting.

In other programs, links in the hoisted material still work, so that shouldn't be an issue.

And as you say "this would be a wonderful beginning of this capability."

Am I right in assuming that most users wanting a hoist mechanism would be happy with the above as a start?

Daly

Originally posted by wordmuse
hoisting in the old days (and maybe in other programs today) meant simply this: I take a part of the outline and temporarily call the node I'm on "root." Nothing else. Search doesn't matter. Filters don't matter. All I want is to visually see from my new "root" down.

In fact I really don't want other stuff. I just want an uncluttered, manually toggleable ability to temporarily specify a soft root, and then to release it and go back to the original root.

I'd like to be able to do that in whatever tab I happen to be in.

If there's no other way, you can even de-activate all the related panes while I'm in "hoist mode." I dont' need to see children, parents, or search. I wouldn't mind being able to, but the main thing is to be able to focus from the soft-root down.

Nothing more.

I don't know about anyone else, but this would be a wonderful beginning of this capability.

I guess this is tough to wrap your arms around, but for me, it's really that simple.

Hope this helps a little bit.

Regards,
Bal

[quant]

Originally posted by igoldsmid
I am using a graphical mapping application as a front end to UR V3. I am using Personal Brain (V4 beta) - although its possible to add any front end like this to UR now (e.g. some other mind mapping program) - which enables at least two very powerful "extensions" to UR:

1) - I am using a Personal Brain map as a graphical navigator for UR's Tree - which enables me to more easily see/locate, and navigate to any number of specific locations in the UR tree.

2) I can create many further relationships, AND Relationship Types between (virtual UR) Items in Personal Brain - that wouldn't be easy or even possible to represent in a useful way in UR.

IJG

igoldsmid,

how do you use PB as a frontend to UR? Thanks

[igoldsmid]

Originally posted by quant
igoldsmid,

how do you use PB as a frontend to UR? Thanks

Hi 'quant'

First of all ensure that - (available in UR V3 beta only) in Options\Miscellaneous, Item Command-Line Format is set like this: ur://%DB_URL%?item=%ITEM%

Then you can copy to the windows clipboard the uri (URL) to any tree item, by either Cntrl-Shift I, or Menu\Item, Copy Item Command-Line.

Then in Personal Brain, double click on any Thought - then click on Link to URL - then paste your clipboard contents (the previously copied UltraRecall uri) there (overwriting the 'http://' string if that has automatically been placed there by default).

Then when you double click on the Thought with that link attached, you will navigate to the referred to link in UR - and if UR is currently closed, it will automatically open. So its really similar to a web link, which opens a browser for you if it needs to.

Make sense?

[kinook]

Ok, ok. We'll investigate providing a basic hoisting feature in v3.0.