Just plain links, no parents or children?

[xja]

Why distinguish between parent links and child links? Why not just have "links"? It seems to me that parent-child relationship is a by-product limitation of the tree interface.

Just have "links" and then let the user decide what item(s) to use as the root of the tree and call that a "view" (let the user store different "views"). Then in the tree, for any item, show as children all linked items EXCLUDING the current parent item. So the "parent/child" status is not inherent in the link definition, but just determined by what you decide to have as the root.

So if I have a contact linked to several projects, I could have the contact displayed as a child for each project and I could have each project displayed as a child for the contact.

This is as opposed to how it works now where, if I make a contact a child of a project, then I can't see the project as a child of the contact in the tree. Rather I have to look at the Parent Items pane to find those relationships and then follow them by double-clicking.

This would also be useful down the road if you ever implement different display structures, like Mind Maps.

[kevina]

In your scenario, the entire concept of "logical links" would vanish (no item has a true parent, therefore having two "children", two "parents", a single "parent" and a "child" are all situations where an item has at least 2 links...

I simply do not see how you can have both relational models (the hierarchical model that Ultra Recall currently uses, and the all-links-are-equal model used by "Mind Map") in the same application...

One idea that has been mentioned before is to allow existing (or perhaps even new) Info Items as values of Attributes. Maybe this could be extended to show the owner of an Info Item (as an attribute) as a "virtual child" of the owned Info Item.

Something like:

+ My Data
--+ Contacts
----+ John Doe
-------* //somehow indicate the "owning" Project1 Info Item here
--+ Projects
----+ Project1 (with a Manager attribute of <John Doe>)

At this point this is simply a theoretical discussion (no promises are being made about feasibility or implementation) but we are interested in user opinions and ideas. If this concept (or others) can be honed into something practical, generally useful, and intuitive we are certainly interested in implementing them... Feel free to post additional comments or email them to support@kinook.com.

[xja]

Since we are talking theoretically, I'll try to describe my "ideal" on how this should work, without regard as to how much you'd have to change the current code :).

A picture's worth 1000 words. The attached pic shows how this might work. And here are 1000 words. This combines 3 ideas:

1. the concept mentioned here about having just links, no parent/child relationship (I still think they are "logical links")

and then 2 ideas similar to those mentioned by others and by me in previous posts:

2. links can have a "type" associated with them (eg, manager, spouse)

3. user can create "smart" items or "group by" items (choose your term) that have as their children those sibling items whose attributes match a user-specified criteria (in many cases, this is better than trying to use Info Items and manual links to group things by a common attribute)

So, in the attached example, a user creates the following:
- Linked to MyData: create Project1, John Doe, Jane Doe
- Linked to Project1: create Task
- Linked to John Doe: create Note about John

User then creates link between Project1 and John Doe and defines its type as "manager". User creates link between John Doe and Jane Doe and defines its type as "spouse".

User creates 2 smart items under My Data, called Projects and Contacts, where they are respectively defined as "Template Item = Project" and "Template Item = Contact".

Under Contacts, user creates 2 smart items called Business and Personal, respectively defined as "Category = Business" and "Category = Personal".

All items linked to My Data (Project1, John Doe, Jane Doe) are grouped accordingly. Any item created under a smart item(s) has its corresponding attribute(s) set to match the definition of that smart item(s).

The user sets the Data Explorer such that My Data is the root. Then all items linked to My Data are displayed as children, but grouped by the smart items. All of those children then show as their children those items to which they are linked (except the item that is currently its parent in the tree, ie, My Data... this avoids the circular link issue... in other words, circular links are not shown). This continues down the tree. In this way, the parent-child relationships are determined by the item selected to be the root (ie, you could create another view that had Project1 as the root, or John Doe as the root) and is not inherent in the data itself.

Note that all items with the same title (excluding the parentheses) would be multi-linked, not duplicates. Couldn't create it in UR as it is since UR won't let you create "recursive" links.

This may look complicated when fully expanded, but you would only expand those items when you needed to drill down further.

If you got this far, thanks for reading this diatribe.

[pmuckle]

I reallly like this idea - it is similar to how InfoCentral used to link data items.

I would like to see the link before the item though...

Project1
|_manager _ J Smith

J Smith
|_ Manager _ Project1
|_ Husband of _ M Smith

M Smith
|_ Wife of _ J Smith
|_manager _ Project1

Each link has a 2-way reciprocal description (husband of... wife of..) and a plural form if needed, so links can be grouped.

Just my 2 cents

Pete