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

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

[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