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

[kevina]

Several forum posts and emails we have received contain thoughts and general concepts on how to better manage large amounts of data in Ultra Recall. Some users have indicated that navigating in the Data Explorer pane of Ultra Recall becomes more difficult as the amount of information grows.

Some suggestions received to address this issue include:
- Hoisting - this seems to be generally understood as (temporarily) re-rooting the Data Explorer pane to a child/grandchild Info Item of the actual root Info Item.

- Auto-collapse of all Info Items but the current one, with a way to prevent certain Info Items from ever auto-collapsing.

- multiple, independent trees - user can create additional equivalents to the Data Explorer Pane/My Data in the same Info Database?

- multiple tabbed views - the equivalent of having simultaneous multiple UR applications for the same Info Database, providing multiple "views" into the same .urd file (implemented as a tabbed interface within one UR "instance" somewhat similar to Firefox but including the additional panes of UR).

- other suggestions or combinations?

We use Ultra Recall internally with 1000's of items and have not personally had difficulty navigating through the data. Utilizing the various panes to facilitate navigation, searches, and a quick "collapse all" if the Data Explorer gets too "cluttered" has been very effective for us. However we do recognize that these suggestions have merit and could prove to be very useful.

Here are our current thoughts on the above suggestions, please feel free to post comments in reply. We are hoping to condense the various suggestions and thoughts into a workable, "implementable" enhancement for a post 1.4 version of Ultra Recall (which is currently in internal beta for release by the end of the month).

- Hoisting - this could be useful and should be relatively easy to implement, the main issue is how to actually implement the hoisting/unhoisting graphical interface.

- Auto-collapse - this could also be useful and should be "implementable", the main issue with this idea is when/what would auto-collapse?

- multiple trees - unless we are misunderstanding, we take this to mean that multiple root Info Items (each in a separate visible tree) could be created, essentially creating separate hierarchies within a single Info Database. If this is what is being suggested, wouldn't be the equivalent of multiple Info Databases (which we believe would be better)?. Right now this concept actually is implemented by the Search Pane, which is an independent tree (with a separate root Info Item).

- Multiple tabbed views - this would essentially work like tabs in Firefox, however, each tab would represent a complete view of the data (all the panes would essentially be part of each tab, including a separate history). This seems to be more generically useful than the multiple tree suggestion above, but would be somewhat more complicated to implement. A combination of hoisting and this feature would essentially provide the same capability as providing multiple trees.

Any additional comments, thoughts, ideas on the topic? Please try to stay on topic, we are certainly planning other enhancements as well, however this forum post is intended to distill your ideas on this particular topic into something "implementable"...

[Zula]

I would like to see multiple trees accessed via tabs as implemented in TreeDBNotes, Keynote, and MyInfo 3.


TreeDBNotes (freeware and pay versions)
http://www.softviewer.com/treedbnotes/

Keynote (freeware)
http://www.tranglos.com/free/keynote.html

MyInfo 3
http://www.milenix.com/index.php

[xja]

Good idea to consolidate these discussions.

I would like to add to this list the concept of a filtered Data Explorer. It was discussed in this thread:

http://www.kinook.com/Forum/showthread.php?threadid=721

In a nutshell, allow user to define a DE filter. Only items that match the filter and all of their ancestors (parents, grandparents, etc.) and descendants (children, grandchildren etc) are included in the tree. All other branches are hidden. Optionally, when the filter is applied, auto-expand the tree to show the matched items, auto-collapse all descendants of matched items. When an item is selected, you would still show all children in the Child Items pane.

If you added tabbed functionality, you could assign a DE filter to a tab.

This would allow you to see a subset of your tree within its hierarchical context (which a Search cannot do). So you could do things like hide all completed tasks, show only urgent tasks, view all flagged email by project, and many other useful views.

IMHO, this feature is crucial. I almost bailed out of UR several times because of the lack of this feature... right now, I'm getting by using clunky workarounds as an alternative.

[kevina]

One issue that I see with hoisted and filtered trees, when all children are displayed in the Related Items Pane - what should happen when the user navigates to a child Info Item that isn't currently displayed in the hoisted/filtered tree?

[xja]

If I understand you correctly, I can think of 3 options when a user double clicks/presses enter on an item in the Child Items pane which is not in the filtered tree:

1) do nothing

2) add the selected item in the filtered tree and navigate to it

3) switch tree view to unfiltered (ie, show all) and navigate to selected item

Option 1 and 3 would probably be the easiest to implement and either would be OK with me. Option 2 would be nice but might be confusing and harder to implement.

Probably Option 3 is the best. It would be nice if clicking the Back button would then revert back to the filtered/hoisted tree view.

[srdiamond]

My immediate reaction is that this is a far more important feature than standard hoisting. In essence, it seems to me just the right adaptation of standard hoisting to the different demands of information retrieval.

[srdiamond]

We all speak of clutter in the tree existing or not existing, but do we know we are actually talking about the same phenomenon. Only kevin has actually supplied any information about how many nodes he finds manageable.

To try to remedy this vagueness: I counted up the nodes. (UR doesn't seem to have a way of having the program do it. ) I had at the time of counting 1,206. My experience is that manageability problems set in at about the 1,000 mark, although I think probably a few thousand more would still be tolerable. But not more than that.

[kevina]

You can view several properties and statistics of an Info Database at File | Properties, including the number of Info Items (or nodes) and other statistics.

[Leoram]

The problem is that the rate at which Ultra Recall Data Explorer pane grows (caused by characteristics inherent to UR) has turned against UR itself considering its current set of limited features to deal with cluttering and complex document/idea organization.

I thank Kevin for this valuable and sincere gesture at posting this theme.

I think that this is an urgent case. It is clear that something should be done and the sooner the better (-reason?) -Several powerful PIMs are being developed out there, and although I think to stick to UR, it is better to be sure UR will remain unmatched.

Leoram

[avenger107]

If I had the combination of the tabbed separate trees such as in TreeDBNotes with the rest of the features that Ultra Recall has I would probably quit re-evaluating PIMS every 6 months.

It's not only the number of nodes. It actually adds another level of organization. I find that my mind performs better when focusing on subject related chunks. The tabbed interface allows me to concentrate on the subject at hand without distraction. TreeDBnotes has this one feature down pat. It is kinda like having several separate databases except for the speed of switching and the fact there is only one file to manage.

[srdiamond]

One caveat about adding tabs to represent top-level divisions--Would it stand in the way of eventually devoting tabs to open infoitems?

It seems to me filtered hoisting would encompass the functionality of tabs for top-level categories. The user would simply hoist on the category the user wants to isolate.

[avenger107]

This is an interesting discussion. Thanks for asking.

The problem I see with filtered hoisting is that it appears to be an “ad hoc” function that needs to be repeated each time. Not much different than searching, really. It would seem that you would have to navigate the tree or otherwise find the correct node each time to hoist. This sounds like a great idea for tree navigation, but does not add anything to the organizational capabilities of the product.

Having tabs that open separate, independent trees, (not just a subset of the existing master tree) adds a level of organization that can be useful for logically ordering information. This can be accomplished somewhat today with separate files and hyperlinks, but it is a lot to maintain.

[srdiamond]

I'm not sure I understand "separate, independent, trees." Let's say there's a tree T1 with immediate children A, B, and C.

How would this differ from having three separate trees, Ta, Tb, and Tc, where Ta contains all and only the infoitems and their relationship in subtree A, etc?

It seems to be a hoist on subtree A is exactly equivalent in substance to opening as a tab the tree Ta. The approaches are exactly the same, just as long as the separate tree approach allows you to have more than a single tree open at a time.

But the hoisting approach has the interface advantage of being implemented from the menu and/or right-click, leaving tabs available for a multi-page interface, where several infoitems can be open at the same time. (Not sure if that's "on the list.")

[xja]

Kinook,

Regarding the Collapse Siblings feature in 1.4 (since it is related to this):

Can you PLEASE make it work like Windows Explorer, where if you expand the item by double-clicking (or single-clicking, depending on how you have that option set), then siblings are collapsed, BUT if you expand an item by clicking the "+" next to it, then siblings are NOT collapsed... This would be MUCH more useful.


Separately, regarding this discussion, I see a mention of "filtered hoisting"... filtering and hoisting are two different things... although both show a subset of the tree, they serve two very different purposes. Filtering shows the whole tree with some branches hidden. Hoisting takes one branch (and all its sub-branches) and makes it the root of the tree. I guess you could have a hoisted branch that also has its sub-branches filtered, but they are two distinct things.

[Zula]

Originally posted by avenger107

Having tabs that open separate, independent trees, (not just a subset of the existing master tree) adds a level of organization that can be useful for logically ordering information.

I completely agree with this. Hoisting may be equivalent to using the tabs with separate trees, but I like using the tabs better. For those who can't visualize how this would work and would like to try it, download TreeDBNotes free version.