Doesn't UR already have columns? The attributes can be displayed as columns in the related items pane.

I know that most people are talking about columns displayed alongside the outline, but the current UR approach actually diminishes the drawbacks of columns with deep outlines Stephen mentions.

The best part is that each item is essentially its own column view since the columns displayed can be arbitrarily modified for every item in the data explorer pane. This, combined with the ability to build any type of search as an item, means that the grid/column view is pretty powerful. The fact that it isn't displayed beside the data explorer outline seems to me just to keep things from becoming cluttered. It also means you come up with the column display that makes sense for each item/search and don't have to try to decide which database-wide columns are really important for display alongside the main outline. And, to top it all off, you can easily export the grid view to Excel.

It's true that the current UR grid view is display only - but the roadmap indicates that the next version will allow editing in the related items pane.

Re: +100 for tree filtering (and tree columns)
 

One test for needing a certain new feature is how easily can the operation be accomplished using the existing features.

With tree columns you can expose all the values you need at the same time, without needing to manipulate anything. But mere exposure doesn't usually get you passed the jumble, so you would also need to filter on the columns. Thus the two suggestions complement and promote each other.

With columns in the child pane, you can see all the values you want, neatly lined up, by selecting the relevant infoitems, copying them, creating a new empty topic, and then pasting the items, thereby creating clones of those and only those you need under a given topic. Select the new parent topic, and you have your metadata columns in the Child pane, for those infoitems of interest and only those.

'Tree columns and filtering' comprise a messy and inefficient procedure when compared to 'cloning and displaying.' Best of all, the feature is available now.

One question: Why do some people want to insert their pet feature into every program they encounter?

the Way WJJSOFT Mybase Handles Links
 

In Mybase, (wjjsoft.com) - when a Tree Item/Topic, has linked Items/Topics - instead of showing indented under the Topic/Item - a separate window appears at the bottom half of the Tree Panel, within which the linked Items appear and can be navigated to - then if you navigate to any linked item, when you get to that linked item, the Item you just came from is of course also shown in the Links Pane (which can, in effect, also be used as a quick 'back link')...

The elegance of this is that its impossible to 'confuse' linked items with regular child items - and logically - links have potentially many different types of associations - not merely child relations... and also a significant element of "Tree Clutter" is removed...

Going on from this - there could be user configurable association types in UltraRecall - to give a few examples: "Is_A", Has_A, "Is_Type_Of" etc etc...

Taking a bit of a leap on from this - if anyone knows of RDF (Resource Description Framework) - this enables two Objects (AKA Items in UR) to be joined via a relationship or association to create RDF Triples... One can then create a fundamental collection of linked concepts as Triples - this can provide a more fundamental or rigorous basis for building more complex interelationships among the data in the UR Database...

Food for thought & Comment?

Re: Re: +100 for tree filtering (and tree columns)
 

Sorry, that isn't the same thing as seeing the items in their tree structure with the columns. You are still creating a flat view and therefore losing the containment information - which is often (but not always) a critical part of what the user wants.

And personally I think a clean, consistent model for describing how to filter/show the data (tree or no tree, which columns) regardless of display location (left pane, detail pane) is a much cleaner, usable model than specialized panes that act different from each other.

Bonsai supports both filtering to a tree or to flat list. I often use both for different views of the same data. In fact, the lack of a filtered tree view is why I have moved to Bonsai (even though it is missing other things) from UR and from MyLifeOrganized (another place you and I have spent time). And I am very happy I spent the time, because I have confirmed my belief that filtering and multi-column tree views are critical to most of my use cases.

I don't know. Why do people assume their own use case is somehow representative of the the entire user base while assuming at the same time that other's are not ;)?

It's not that we think our use cases are general enough to be implemented, of course. :)

It's that this is the "Suggestions" box. So if you don't ask...

Regards,
Bal

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

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

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.

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.

An easy(?!) approach to "browsing filtered trees" (or at least similar...)
 

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.

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

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).

pseudo hoisting using V3 url's
 

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

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

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

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

Re: pseudo hoisting using V3 url's
 

igoldsmid,

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

Re: Re: pseudo hoisting using V3 url's
 

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?

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

Thanks Kinook!!! It would be fine the basic will be open enough to allow the way to the integration of a further true hoisting a la UltraRacall. Anyway, it's nice to have a basic one for 3.0.

Many thanks! That's good news!

Daly

Three cheers for Kinook!

Yippee!

:)

Kind Regards,
Bal

Hoisting
 

Kudos!

Version 3 just got even better!

Hoisting is here (in beta)! And it works beautifully! You've made a wonderful product far more usable than you probably realize.

Thank you thank you thank you Kinook! What a way to listen to your loyal customers! Three cheers and all that. Well deserved.

Bestest Regards, :)
Bal

Hi - also very much appreciate hoisting availability.

Kinook - do you have plans then to provide tabbed hoisting, so multiple hoists can persist at the same time - and then you can tab around multiple concurrent hoists? Just like in the example I sent you by email?

Anyone else interested in having multiple concurrent hoists in tabs?

There's no end to it is there - sorry Kinook!

If I take your meaning correctly, it's already provided. I have a tab that contains reference material - hoisted. And another tab which contains my work product - also hoisted.

As soon as I have the tab configuration that I want, I exit the program to make sure that the settings are saved and then reload. Voila - the tabs are saved in their hoisted configuration.

This goes considerably beyond what I had anticipated on the initial iteration of this capability. All I can say is WOW!

Thank you again. I bow in your general direction as I withdraw. :)

Kind Regards,
Bal

wordmuse you are right... it is already provided - I just hadn't tested it!

Bravo Kinook!