#1
|
|||
|
|||
Relationships
Are there any plans in the works to implement any sort of hyperlinking system between nodes and/or note text in UR? I have loaded the trial version and this is the one lack that is keeping me from purchasing and migrating from Personal Brain.
Take this example: I have a new web project, say "ProjectX." In Personal Brain (PB), I add a new child node under "Web Development" and also link "Asp Applications" as a parent. OK so far, I can do this in UR. Now, in PB, I add children for all the things that are exclusively children of ProjectX, like the share for the scripts, the URL to launch the web app, etc. Again, no problem in UR. Lastly, I add links to all the other items in my PB database that are related, or associated, but are not parents or children. Links to batch files that define shares, contacts that may be associated with the app, but are neither own (parent) or owned by (children) of ProjectX. Shortcuts to software frequently used while working on the app (source control, etc). What I have at this point is a focused work-space. While "ProjectX" has the focus in the viewer, I can single-click (without losing focus on ProjectX) and launch all the programs, files, web pages and email templates I will need to use, update and manage the application. This is where UR falls down, badly. Instead of just relating items (associates), I have to promote one to be the parent, and demote the other to be the child. For instance, take the link to launch my source-control software..... Should ProjectX "own" the software (project is parent) or should the software "own" the project (software is parent)? And how can I launch all 5-10 items used to manage the project without going back-and-forth between nodes in the tree? See my dilemma? Hopefully, I've made some sense here. Thanks, and congrats on a great looking product. |
#2
|
|||
|
|||
Re: Relationships
Quote:
I don't see, however, where there is a problem in launching all the items without going back and forth. The UR interface allows multiple selection of items, so you can select what you need and then launch in one stroke. As to which is parent and which is child, it's your choice how you define parent and child, beyond their purely formal properties. I think the best practice is to try to articulate a concept of how you will apply hierarchy and then apply that concept consistently. That two people using the same program will define subordination differently when mapping it on to the world means hierarchical concepts are flexible, not that either makes an error. But if the user can't fix on a concept and apply it consistently within his model, he will have problems. FWIW, I think users of outline-based programs and other organizers give insufficient thought as a rule to their organizational scheme, expecting the mapping from formalism to data to be more transparent and unequivocal than it can ever be. Stephen Diamond |
#3
|
|||
|
|||
Re: Re: Relationships
Quote:
Vincent Peppe |
#4
|
|||
|
|||
Re: Re: Re: Relationships
Quote:
There's a public forum where questions like this are discussed and debated, http://www.outliners.com, where I'm sure your participation would be welcome. That forum is also a could place to find information through a google search, by restricting the domain to outliners.com. Stephen Diamond |
#5
|
|||
|
|||
Re: Relationships
Quote:
My approach in building relationships that aren't technically parent-child is simply to paste linked items beneath whatever item was there first in the tree. Since there are several ways to get around to different related items, it doesn't seem to matter in practice whether something is a parent or a child - when I am thinking of relationships over hierarchy. |
|
|