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

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