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

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

Multiple trees using tabs
 

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

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.

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?

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.

Agreement
 

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.

How many is many?
 

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.

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.

I welcome this thread.
 

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

Vote for tabbed interface
 

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.

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.

Hoisting, multiple trees etc.
 

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.

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

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.

Re: Hoisting, multiple trees etc.
 

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.

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.

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.

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.

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

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.

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.

Distinctions
 

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.

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:

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

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.

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.

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.

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.

I agree with you 100% about the 2 types of databases. But people don't use 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.


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

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.

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.

hoisting etc
 

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.

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.

Re: hoisting etc
 

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/showthre...?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

off the wall idea relative to this thread
 

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!

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.

another solution?
 

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

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?

+100 for tree filtering (and tree columns)
 

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

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

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

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.