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.

[srdiamond]

Tastes will vary, and ultimately Kinook may have to choose. But it's important to be clear on what is being sacrificed for a benefit that perhaps no one has yet articulated. Are you willing to give up a future of a multi-infoitem tabbed interface, for the sake of tabs fixed at the second level? To me this is too primitive as a solution for an organizer at Ultra Recall's level. Possibly commercially significant, two existing programs, one free, have a tabbed multi-tree interface, but no organizer, save a much more expensive product, has hoisting.

[srdiamond]

Originally posted by xja
Kinook,

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.

I think hoisting can be conceptualized as a special case of filtering, and the filtering you propose would yield hoisting as a particular case. Your filtering allows the display of branches and their descendents. The filter excludes everything but certain branches, whose descendents are also displayed. If you filter so that either only a unique branch is selected or no branch is selected outside a unique branch and its descendents, you have a hoist.

[kevina]

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.

Our testing of this Windows Explorer behaviour on multiple systems shows this to work (sort of, but not consistently or as expected) but is somewhat different than you describe. Our research indicates that the behaviour is opposite from what you mentioned, it does whatever auto-collapsing it does when double-clicking and NOT when using the +/- buttons.

We do believe that you make a good suggestion and also believe that in our own usage it is most intuitive and useful to only honor the UR auto-collapse setting when dbl-clicking (or single clicking if configured so) or using Enter to expand and to never auto-collapse when using the +/- keys or expanding with the right arrow.

To summarize, we intend to make v. 1.4 keep the auto-collapse siblings feature, but only have it function when expanding via dbl-click (or single-click if configured), or by hitting Enter (via the keyboard) but not for the + symbol or the right arrow (keyboard).

We will try to include this additional functionality (and documentation, etc) in v. 1.4 final.

[xja]

Originally posted by srdiamond
I think hoisting can be conceptualized as a special case of filtering, and the filtering you propose would yield hoisting as a particular case.

Yes, a hoist is like a filter with one matching item, however, a filter would display all the ancestors of the matched item, up to the root, while hoist would show the matched item as the root, yes? If you made a filter option to not show ancestors when there is only 1 matched item, it would be a hoist.

I do think there is some value to having them as separate concepts... eg, say I'm browsing through a filtered tree, I may want to hoist an item, but maintaining the existing filter in place for all descendants of the hoisted item. In some ways, it is a a filter applied to another filter, but that may start to get confusing to think of it that way, even though that may be the way it is executed in the code..

[xja]

Kevin,

Yes, I would like auto-collapse to work as you are proposing. That behavior was what I was trying to describe and is the way Windows Explorer works (on my PC) for the most part (I think Windows Explorer has a slightly more complicated algorithm but I haven't totally figured that out... the way you propose is easy to understand and most useful). Thanks.

[srdiamond]

Originally posted by xja
Yes, a hoist is like a filter with one matching item, however, a filter would display all the ancestors of the matched item, up to the root, while hoist would show the matched item as the root, yes? If you made a filter option to not show ancestors when there is only 1 matched item, it would be a hoist.

I do think there is some value to having them as separate concepts... eg, say I'm browsing through a filtered tree, I may want to hoist an item, but maintaining the existing filter in place for all descendants of the hoisted item. In some ways, it is a a filter applied to another filter, but that may start to get confusing to think of it that way, even though that may be the way it is executed in the code..

I think it would be desirable to be able to apply filters to filtered data, whether either filter takes the form of a hoist or not. And it would also be desirable to hoist within a hoist. Barring a complete implementation, yes, I'd still like to be able to hoist, even though I've applied a filter.

[srdiamond]

Originally posted by xja
I do think there is some value to having them as separate concepts

OK, here's a way I do think hoisting and filtering merit somewhat separate treatment. If you have certain parts of the tree you routinely want to filter, you could store that filter. Otherwise, you have to compose the filter before you can execute it. You want a hoist to be routinely available without forethought, but there wouldn't be any filter you could store for performing a hoist. As a category of filters, hoisting is rather abstract. What it does depends on the focus at the moment. Yet it is implemented so as to be mechanical in its application.

[alx]

Kevin, I'd like to propose an additional feature that I believe will complement large UR database management whichever of the above approaches is selected.

My suggestion is to provide the ability to export a part of the tree, be it a specific branch or a filtered view, as a separate UR database. In addition, there should be the possibility to "merge" another UR database into the one currently open, as a branch of the current tree. Personal Brain provides a similar functionality.

This way, a branch or category that grows out of proportion for practical navigation, can become a database of its own. Inversely, one can join several independent databases into a larger one if required.

I believe this will greatly enhance the program's versatility and potential for handling large databases.

Last but not least, you may want to take a look at how Sycon's IDEA!, which is also a one-document program, provides the ability to work with multiple databases:

[alx]

...and here's the actual Sycon link (I pressed Submit rather too soon!)

http://sycon.de/eng/res/overview_idea_features_full_version.html

See IDEA! Team Edition "Multi Database / Multi Tree" near the end of the page.

alx

[srdiamond]

I think I see what UR is missing that would be very easy to implement and make it vastly easier to use for most people. On the other hand, the feature I envision could be one I've simply missed.

Let me give just a little bit of analysis. If people have a database of thousands of infoitems, and they say they are finding the hierarchy cumbersome, are they talking about navigating to any of thousands of points in data space? I don't think so. If anyone really had the need to access points at random, so that each one had an equal likelihood of being accessed at any time, they are going to have navigational pains no matter what they use, short of artificial intelligence. Most of the time, at any one time, most people are navigating to one of a fairly small number of items.

Which items are those? They fall into two different groups. There's a number of "favorites," items the user will continue to consult, at least in the intermediate term.

The other group are those infoitems the user has recently consulted. A recently consulted item will generally have an elevated probability of being consulted again. Taking account of this, browsers have 'history,' not just favorites. History is different from 'go back.' History is preserved over restarts. And it's what it seems to me UR needs and doesn't have, and it would solve a large percentage of presently reported "navigational" problems.

Basically, UR does NOT have a usability problem. It is the most usable product in the field. With this simple addition, it seems to me usability for this kind of product will pretty much asymptote. At this point, imho, UR development should focus in incrementing its power, not its usability, which is or will be as good as it gets.

[sobko]

over the last month, I have tried every possible outlining package. for now at least, I have settled on mindmanager. I really liked many aspects of ultrarecall, and will likely try it again in the future.

I've been a user interface / human factors engineer for about 6 years for financial companies, so I am always trying to figure out the best way to solve these types of problems.

my personal opinion is that UltraRecall is *too* freeform -- instead of trying to solve specific task problems, you provide a very flexible method for solving any problem, but in a suboptimal way.

All of the programs i've tried have this problem. I think that's why people love to play with these outlining programs, but noone seems to consistently use one to run there lives.

Ultrarecall could solve this by having template modules that provide functionality rather than providing simply a list of attributes. As an example, lets say you had a "Project" module, which automatically has "tasks", "contacts", and "documents" subnodes. these subnodes wouldn't have tree nodes as children. Instead, they would have outline lists that appear on the right-hand details screen.

Tasks might let you make a heirarchical list of tasks, but would not allow you to attach subnodes. the same with documents. contacts would allow you make a non-hierarchical list of contacts, and might have links to


your product has some really great concepts, and I expect it to be the best in class in the near future, especially because of the time you take to gather feedback from your users.

[srdiamond]

Originally posted by sobko


my personal opinion is that UltraRecall is *too* freeform -- instead of trying to solve specific task problems, you provide a very flexible method for solving any problem, but in a suboptimal way.

I think you are saying two somewhat separate things here. Both have merit, but imo, one has more than the other.

It is true that where specialized database programs are available for professional use, they are often better than the jack of all trades products. But isn't there a need for the latter too?

But UR is in some small ways excessively free form, imo. Is there a need to allow an infoitem to contain a clone of itself? Too often i inadvertently create these, only to discover these nuisances later.

Originally posted by sobko


All of the programs i've tried have this problem. I think that's why people love to play with these outlining programs, but noone seems to consistently use one to run there lives.

A most interesting observation. "Flexibility" has become a catechism. For better and to a slight extent for worse, UR--unlike many--actually delivers on this promise.

It seems to me, though, that UR and Mind Manager are so different it almost misleads to call them each 'outlining' programs. Outliners so-called fall in two broad classes, more fundamental than the graphical/textual distinction--thought processing programs for organizing one's ideas from a perspective; and information organizing programs, for retrieving data. Mind Manager--so it at least seems to me--is primarily the first and UR the second. UR, though, at least doesn't try too hard to be an outliner in the first sense. Whereas Mind Manager, despite being essentially an outliner in the first sense, tries very hard to cover the second function too. So it seems to me, Mind Manager is perhaps one of the worst offenders when it comes to being excessively flexible. (I think the best dedicated outliners in the first class are actually Brainstorm and NoteMap. Of the graphical outliners, Visual Mind seems to do best at maintaining its focus as a thought processor. An information organizer that is by design slightly less flexible than UR is Idea!) At least that's how the terrain looks to me.

[sobko]

It is true that where specialized database programs are available for professional use, they are often better than the jack of all trades products. But isn't there a need for the latter too?


I agree with you 100% about the 2 types of databases. But people don't <b>use</b> a database. First they create a database structure, then they create some type of interface to input and extract the data they need: they take Type2 and create Type1 for their specialized use.

In the freeform database programs I have been testing, there is no distintion between structuring the database and entering data. You can't make a specialized application out of it. Or rather, you are perpetually making a specialized application out of it.


A most interesting observation. "Flexibility" has become a catechism. For better and to a slight extent for worse, UR--unlike many--actually delivers on this promise.

I agree again, and for applications like collecting webpages or cataloging documents with complex metadata, UR beats other outliners hands down.

[srdiamond]

I still tend to think this discussion has taken place at so abstract a level that it's hard to know whether we're talking about the same problem. And there's also the question of whether existing features might not have already solved some of the problems. This has certainly been true for me. Every week or so I discover a new feature and wonder how I missed it. Or more frequently, something takes way too long, but I just fail to think of the easy solution at the time. These possibilies don't completely answer the critique, because it may be the case that some aspect of design could be improved so the right move is more compelling at the moment. But it suggests a different kind of problem than the one being discussed.

So allow me to follow my own advice and state clearly where I find using UR with a complex database somehow seems like its harder than it ought to be.

Here's my standard scenario. I import various things into UR over a few days. Then I see my imported folder is getting large, maybe 20 items. So I decide to organize them, so it doesn't get so large that I am tempted to simply trash all of them.

The problem is how to get the items into the right folders. How do I efficiently get each of these imports into the proper folder? I can think of the obvious shortcuts--finding all of them that belong somewhere, copying all, and then pasting into the destination, for example. But in practice I end up just taking each, surveying my hierarchy, and then dragging to or pasting into the location.

Why is this a "clutter" issue. Well, obviously the tree's expanse, absent hoist, makes these efforts a little harder. But even though impressionistically it feels like a clutter issue, that's probably not what it is in the main. The main bottleneck isn't navigation. Rather, it is in the number of separate operations required.

What would solve this? Ideally, I think of this feature. The hierarchy is automatically numbered, maybe legal outline numbering would work best here: 1.2.1.5--that sort of numbering, so the first digit designates a folder at root level, the second at second level... I see my list of items to file and in a separate pane the folders in which it can be filed. When I find the one I want, I simply type the folder's number beside the item. When I'm done, I press a button, and they all go where they belong. The indexing may make my computer unavailable for a few minutes, but at least it is all happening in one block and not interrupting anything.

[xja]

Originally posted by srdiamond
The problem is how to get the items into the right folders. How do I efficiently get each of these imports into the proper folder?

It should work like ebay. When you post an item to sell on ebay, you are asked to specify under what "sub-sub-sub-category" to file it. However, ebay searches the text of your description and suggests a list of sub-sub-sub-categories which contain items with most similar descriptions, ranked by similarity. It is almost always right. It makes "filing" really easy and consistent. So in UR you could have a hotkey to show a list of suggested links.

One step further... if you are filing an email, UR should include the Contact of the sender on the list of suggested links, and maybe also other emails which have Message ID headers that match the In-Reply-To header of the email to be filed... or the parents of emails that have the same Thread-Index headers.... maybe include the list of recently viewed items in the suggestion window (by the way, Stephen, you can list these with the Recently Viewed search, or by creating your own search and sorting by Date Accessed in descending order).

The point is, a little more intelligence and automation could dramatically decrease the need to manually navigate the tree.

[lsebba]

I have two thoughts on this topic:

The first is that the issue is not really navigating through a large tree, as much as it is moving items around in a large tree. I do not find it that difficult to naviagte the tree. I find it very cumbersome to try to move, copy or logically link an item over a large distance. This would most easily be solved for me by having the ability to have two Data Explorere panes, that one could drag and drop across.

The second is that I frequently find myself trying to logically link an item across a distance, and then find that I do not have the appropriate parent to link it to. The ability to create a folder on the fly in the data explorer pane would be great.

[kevina]

You CAN create Info Items on the fly in the Data Explorer, using Edit | Insert (Ins keyboard shortcut), Tree | Insert Child (Alt+Ins), or Tree | Insert Sibling (Alt+Shift+Ins). Corresponding Toolbar buttons also exist.

If you use copy/cut & paste to move/link/copy Info Items in the Data Explorer, then the operation is simply a navigation exercise (creating new parents as necessary as described above). Just Copy or Cut the Info Item(s) to operate on, then navigate to the destination and Paste | Paste Special as desired.

[Leoram]

Originally posted by lsebba
I have two thoughts on this topic:

The first is that the issue is not really navigating through a large tree, as much as it is moving items around in a large tree. I do not find it that difficult to naviagte the tree. I find it very cumbersome to try to move, copy or logically link an item over a large distance.
As in some way they seem to be related, the matter discussed here (as I see it) lifts up to a higher level of relevance the feature requested in the following thread:

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

This makes me think that many users have found the cumbersomeness when trying to organize/re-organize their Infoitems or thoughts throughout a complex tree in UR. In my opinion Ultra Recall needs to fast track the process of moving, copying, linking because very frequently this is what you try to do when you feel the need for hoisting, multiple trees, tabs, etc. Fast track is what our brains use when trying to come up with an idea or remember something.

Leoram

[igoldsmid]

if only UltraRecall could have the possibility to provide a dynamic mind map view of the tree - and the ability to view, organize, reorganize, navigate via the map view - for me that would be nirvana...

if you follow the plans of http://connectedtext.com/news.html, you will see they are creating a wiki style info manager with a dynamic map view of all topics (tree items)

but even the now out-of-date personalbrain makes it much much easier to work with huge numbers of topics/nodes - though they have a new java based version coming out mid year...

Mindjet Mindmanager is the best conventional mind mapper, but its way behind in performance and many other areas.

for a me a map type function for organizing and navigating through very large numbers of nodes is the way to go ---- but at this time there are no mind mapping products that even come close to the industrial strength data management, and wealth of other info management features that UR has...

if UR implemented dynamic mind maps to view, organize, reorganze and navigate the ifo items, I think I might not look at another product seriously ever again!

[lsebba]

I think the bottom line is that the consensus of the responses to this thread is that the navigation through the data explorer seems to be the weak link in the usability of the program. I think it is a great program, but do find it takes that slight extra bit of mental effort to navigate around the DE window compared to other programs. I am not sure what the optimal answer is, but it clearly would make a big difference to the usability for a lot of folks.

[Rbrux]

I am a new convert to UR (three weeks of intensive and enthusiastic use) but have used various outliners and other data managers for years.

I wonder whether the clutter problems described in these forums might be alleviated by the intoduction of greater flexibility/automation in the NAMING of items.

I notice that I find naming items a bit of a bore. Once attributes and text and/or notes have been assigned to an item, it all seems a little repetitive to then give the item a name that is useful, as well as succinct enough not to overtake the data tree.

The consequence I find is that many items under a particular heading will be similarly (and unhelpfully) named.

This is especially the case when I am using UR to make quick notes (eg of a phone conversation).

In the case of emails, which are automatically titled according to their "subject" field, the result is a whole list of messages (alphabetically sorted) which gives no clue as to their sender or chronological sequence.

An obvious way to deal with this is to use UR's views (in particular the child view) and to take advantage of the many sorting options.

This is what I tend to do; however, even in the child view I am faced with a column (the only un-removable one) in which the item title is displayed. And if I have highlighted an item in the child view pane I often have no way of identifying the corresponding item in the data tree.

I wonder whether the "item title" attribute could expanded to give users the option of automatically naming items by reference to (say) three of the attributes attached to the item. This would simply generate a text string that would automatically appear as the item title. Another approach (not necessarily an alternative) would be to have another naming option by which UR automatically assigns the first 3 or 4 words of item text (if any) as the item titlle.

These would simply be options - allowing the user to manually assign an item title if they wish.

I might, for example have a document template that allows me to assign the attributes: date-doc type-addressee. If the template also allowed me to automatically assign the values of those attributes as the item title, the documents in a folder with that template as the default child would appear neatly sorted. (I recall seeing somewhere in the forums that one user uses a the convention yymmdd to deal with dates in item titles - so as to ensure correct sorting. That's a good idea, but is a bit laborious if done manually. Could UR be configured so that when the automatic item title includes a date it is is represented in that format in the item title?)

Having this naming option would mean that items under a parent would appear in a way that lets the user know whether a new subheading might be in order. For instance, in the letter example above the letters for a particular month could easily be moved into a folder for that month.

Again, all of this sort of stuff could be done via the other views, but it seems to me that underlying much of what other users have said about "clutter" is a concern that the data tree in its present form is cumbersome and as a result has limited outliner utility. I have to agree - especially when the rest of the programme (excuse my non US spelling!) is so elegantly implemented.

Even the child view would be enhanced by the presence of (automatically) useful item names.

The approach I suggest, if it is achievable, would not (of itself) reduce the size of the data tree, but it would make getting around it (and refining/adjusting it) far easier.

Could this be done.

And does anyone agree that it might help?

Richard Bruxner
Darwin Australia

[xja]

ok, since the tree filtering doesn't seem to be in the roadmap, can you PLEASE at least add an option to hide "completed items" and their children?

[reesd]

Originally posted by xja
ok, since the tree filtering doesn't seem to be in the roadmap, can you PLEASE at least add an option to hide "completed items" and their children?

I'm sorry, was actually stated somewhere that tree filtering isn't in the roadmap? Like you (and many others), I think this is a critical missing feature from UR. It's the reason I still spend most of my time in other tools (and why many of us miss Ecco so much ;).

I'll add that the other related missing feature is columns in the tree view. Otherwise the user is forced to click on each item (or each of their parents) to see their fields rather than seeing them all together.

So essentially what I am suggesting is we need the features of the "child items" window (filtering and columns) in the tree view. UR's semi-unique alternative for this is the Child Items window. Child Items is an interesting approach that avoids the programming difficulties of a multi-column, tree widget, but (IMHO) its just not intuitive to users and also is not as powerful as true columns and filtering in the tree view.

I'll add one of the key potential values I see in UR is the ability to add custom fields which is one of key values Ecco has/has as well. However, without tree view columns (which Ecco clearly has) their value is much less visible in UR.

Note that both of these features hide easily from new users (they don't see columns or do filtering into they learn and request it).

Finally I'll add that filtered tabs makes more sense and seems to have much more value to me than hoisted tabs (e.g. urgent items, items added in the last week).

Thanks,

d

[Daly de Gagne]

The lack of tree columns as described below is one main reason why I do not use UR to a great extent. ADM and My Infor both offer tree columns. ADM also offers both hoisting and the option of having the metadata in card form with each document. Zoot has a very sophisticated system of metadata columns and folders, the latter being able to be programmed to take certain automatic actions on data through the setting of rules.

I would also add that Ariadne offers a column capability. While technically you cannot have an Ariadne document attached to a column item, you can use the comment feature as a workaround, and it works just fine.

I think that it is admirable that UR has recognized the value of metadata and moved as far as it has, clearly leaving such outline-based programs as Treepad, MyBase, Maple, MyNotesCentre, etc. behind. However, UR has a ways to go to be fully competitive.

Daly


Originally posted by reesd
I'm sorry, was actually stated somewhere that tree filtering isn't in the roadmap? Like you (and many others), I think this is a critical missing feature from UR. It's the reason I still spend most of my time in other tools (and why many of us miss Ecco so much ;).

I'll add that the other related missing feature is columns in the tree view. Otherwise the user is forced to click on each item (or each of their parents) to see their fields rather than seeing them all together.

So essentially what I am suggesting is we need the features of the "child items" window (filtering and columns) in the tree view. UR's semi-unique alternative for this is the Child Items window. Child Items is an interesting approach that avoids the programming difficulties of a multi-column, tree widget, but (IMHO) its just not intuitive to users and also is not as powerful as true columns and filtering in the tree view.

I'll add one of the key potential values I see in UR is the ability to add custom fields which is one of key values Ecco has/has as well. However, without tree view columns (which Ecco clearly has) their value is much less visible in UR.

Note that both of these features hide easily from new users (they don't see columns or do filtering into they learn and request it).

Finally I'll add that filtered tabs makes more sense and seems to have much more value to me than hoisted tabs (e.g. urgent items, items added in the last week).

Thanks,

d

[srdiamond]

Introducing columns cannot require great programming feats, because when ADM acquired columns, it weighed in at less than a megabyte. There's no where you could stuff all the programming people are imagining columns require into less than a megabyte. Columns cannot be all that hard to do.

But columns may be incompatible with deep outline structures. It seems just too much to manipulate, topics at deep levels, each tied to a bevy of columns. Attempting to put columns in a program that encourages taking outlining to some depth might, it seems to me, really tend to destabiliize the application. Thus when columns were added to ADM, a program that had enjoyed a short-lived reputation as super-stable became utterly flaky. It is now so unstable that even Daley won't actually use it.

Anyway, I'm guessing about the resource demands of columns. I really don't know. But what is clear to me is that the value of columns diminishes in a deep outline. The confusion increases exponentially. Columns after all represent a hybrid between an outliner/database and a spreadsheet. A spreadsheet will only take so many levels before the point of columns is lost. The only program I've seen that is really successful in combining columns with an outline is a professional product called CaseMap. The outline, however, is only intended to be two or at most three levels deep.

It's absurd to take one pet feature like columns and build a scale of technological advancedness around it. You have to at least take account of facts like Zoot being stuck in the 8-bit world; Ariadne being unable to maintain a continuous development path, ADM producing more errors than desired outcomes, and MyInfo being in many respects a minimalist program.

[PureMoxie]

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.

[srdiamond]

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?


Originally posted by reesd
I'll add that the other related missing feature is columns in the tree view. Otherwise the user is forced to click on each item (or each of their parents) to see their fields rather than seeing them all together.

So essentially what I am suggesting is we need the features of the "child items" window (filtering and columns) in the tree view. UR's semi-unique alternative for this is the Child Items window. Child Items is an interesting approach that avoids the programming difficulties of a multi-column, tree widget, but (IMHO) its just not intuitive to users and also is not as powerful as true columns and filtering in the tree view.

[igoldsmid]

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?

[reesd]

Originally posted by srdiamond
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.

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.

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

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 ;)?

[wordmuse]

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

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

[Leoram]

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.

[Daly de Gagne]

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

Many thanks! That's good news!

Daly

[wordmuse]

Three cheers for Kinook!

Yippee!

:)

Kind Regards,
Bal

[ksrhee]

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

Kudos!

Version 3 just got even better!

[wordmuse]

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

[igoldsmid]

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!

[wordmuse]

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

[igoldsmid]

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

Bravo Kinook!