[Logo] VUE Users Forum
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
[Login] Login 
If this is your first visit to the new VUE forums, you can login using the same username and password you currently use on VUE's website. If you need an account, please create one through VUE's website. If you have problems, please contact us via the contact form on http://vue.tufts.edu
List, Tree/Hierarchy, Table/Grid background containers  XML
Forum Index » Wish List
Author Message
Philipp Jurewicz

Joined: 08/08/2008 11:36:13
Messages: 35

Dear VUE Team

In anticipation of VUE 3, I spend some time to mockup in Illustrator what would be for me the next step after this mayor release:

Objective: "Convince more people to switch to a node-edge thinking, without alianating them by giving them a little bit of the structure they are so used to from Excel, the most abused Spreadsheet-Mathematical-Calculation program, and Powerpoint madness"

I personally believe that most unsolved problems (especially in enterprises) are network-problems nowadays. People think of Excel as squared paper and try to abuse it. They create lists, hierarchies (without any semantic) and get lost by adding cross links. Still no other application was able to successed Excel in these needs.

To give VUE a shot one would need to ease the threshold: Give the people structures. And especially make these structures/containers "communicable".

The little things like:
* this *is* a list (even though the backend might store nodes inside nodes in a very flexible way)
* communicable in a consersation: "Hey look at the list item number 3", "look at table cell B2", "look at branch 1.2.2 of the tree"
* the structure should be in the background, the colorful nodes in the foreground
* container structures are impliced edges (for Exploration tools)
* drag and drop like in the Photoshops' Layer palette, but also help people by telling them "drop node here"
* I can move a container as a whole
* the container expand correctly and "clean" when I drop or drag-out nodes

As far as I see the implementation of VUE you've done most of the work already it's just visuals and semantics that I image differently. I can drop nodes into other nodes, I have pleanty of arrangement commands, etc. These containers are maybe just nodes with a little bit of different visual appearance. I assume that I'm over simplyfing, and there a heaps of implementation traps, but it's just an idea I painted up in Illustrator, so don't take it to serious if it doesn't fit your roadmap.

To stress out, I believe that drawing (beautiful) connection lines between VUE nodes is still the main value that this application brings. So plese see the second attachment of a mockup where a map could contain the new containers together with all the existing capabilities. Having such a tool in secnarios where I have a group of business people try to figure out how to map two enterprise hierarchies (bottom part) and have them add todo lists, scanned photos of whiteboards, connection lines. etc.

[Thumb - VUE_containers_02.png]
 Filename VUE_containers_02.png [Disk] Download
 Filesize 86 Kbytes
 Downloaded:  15 time(s)

[Thumb - VUE_containers_01.png]
 Filename VUE_containers_01.png [Disk] Download
 Filesize 87 Kbytes
 Downloaded:  14 time(s)

Scott Fraize

Joined: 08/08/2008 11:36:13
Messages: 46

Thanks much Philipp, these are some great ideas.
-- Scott
Philipp Jurewicz

Joined: 08/08/2008 11:36:13
Messages: 35

related forum post

Grant Robertson

Joined: 07/23/2009 00:23:04
Messages: 4

I just want to put in my vote for this feature. I had logged on the forum to see if VUE had any means of constructing a real table, rather than just arranging nodes as a one-time action. However, this idea is much better than a simple table type node. Not only can it hold existing nodes, but those nodes could then be manipulated just as any other node. Because nodes are already able to hold other nodes, perhaps the best way to approach this, development-wise, is to create special types of nodes. Essentially, these special "table" and "tree" nodes would function just like existing nodes except that they would also have special controls for adjusting the layout of the internally stored nodes. It would be beneficial if the position information - as to where the node is located within the tree or table - is stored in the metadata of that node. This tree/table position information would naturally need to be updated as the node is moved around within the tree or table. Storing the location in this manner would allow other plugins, applications, or scripts to make use of the location of the node when processing information about that node without needing to go through a complicated process of querying the container as is necessary with JTree.

(Of course this brings up the question: What does "child node" mean, exactly, within VUE? Does it mean nodes that are pointed to by some other node, as in classic tree data structures? Or does it mean nodes that have been placed inside other nodes?)
Forum Index » Wish List
Go to:   
Powered by JForum 2.1.8 © JForum Team