Node Overlap Problem

A recent problem that has come to light involves the overlap of nodes in maps with a large number of nodes.

The problem was not immediately obvious when I was developing the node positioning function as I was testing it with chains of nodes which are relatively distributed.
But it can be clearly seen when you look at a purely heirachal map with no node chains for exampl: [Working with HTML in dreamweaver].

I considered the problem of overlap when i designed the positioning function. The possibility of overlap was the initial motivation behind succesively scaling child nodes and connecting lines. Scaling nodes in this way naturally leads to an efficient node packing in 2d space as it follows a self similar fractal pattern. +The root of the issue comes from the fact that the best solution for packing nodes mathematicaly does not result in the most readable nodes or the best user experience.

Essentially solving the problem by adjusting the scaling constant results in faster exponential scaling of child nodes, shrinkling branches and nodes. However this makes the user spend the majority of thier browsing time zooming in and out of the map having to constantly change scales to read the node text.

So what to do?
Well one solution would be to redesign the positioning function to create an auto-avoidence script that knows where its nearest nieghbour is an moves out of the way. There are a number of ways to do this in flash but all require to much of a sacrafice in control of where the node is positioned.

An alternative solution is to make a small adjustment in the positioning function to incorperate the number of children the parent of the node has and shink all sucessive braches from the node. This amounts more to dynamic scaling based on the number of siblings rather than a fully fledged avoidence script. This would require less computing power and would give a more organized structure.

In an ideal situation i could have the best of both worlds, create an efficient avoidence script that elasticly positions nodes within a set degree of separation. It would give a great organic feel to the map but may create unpredictable change to the overal structure as the node settle into place.

Im confident i can adjust the positioning script but it will have to wait iuntill i have created all the trial maps so that i can get a good feel for the typical range of map structures and asess the degree at which i will need to modify the mapping engine.

Reshaping The Direction of R & D

My primary goal in creating quantum semantic learning spaces has been to investigate how used can benefit from a carefully crated learning environment and how visual interfaces affect their learning. This has proven to be a somewhat illusive goal that in many was should be the very last thing i should really be looking at in these early stages of developing the visual mapping engine.

Instead I am going to focus on a more refined area of development that will pave the way for further investigations into how the map is used in class rooms and other learning environments. What I am going to refocus this investigation on is how to tool a mapping interface to be as user centric as possible. how to provide an intuitive set of user controls that lets the user view and manipulate media in the map as efficiently as possible. This will help ensure that the beta version is as mature as possible before I open it to general users (currently only subscribers can use the interface).

Rolling Out The Beta

The time has come for me to reluctantly roll out the first prototype for general use.
So far I have only created module maps for dreamweaver, Working with Tables, Working with Images and Working wit Text. Each map is created using the same settings for the semantic engine.

Take a look [video tutorial maps].



I decided to go for the name "video Tutorial Maps" as its a bit more descriptive of what they are and how they work than "Quantum Semantic Learning Spaces".

As I published these maps to the site one thing that became clear is a problem related to the transparencey of the swf. Given the detail of the graphic in a map it is important to make the content have a high level of contrast with the background of the map. This is important not only for readability but also as a reference point for users when dragging the map.
Initially I set the swf to transparent using wmode the embedding settings so that the gradient background of the web page design I have would show through. This presented some isssues with dragging but they were solved in this prototype.

[ziggy flash prototype]
This maps works perfectly as long as two things are true.
1. you are using internet explorer
2. You have a SXGA resolution monitor.

the resolution has to be high enough so that scroll bars do not appear on the browser window otherwise the windwo will move up and down when you use the scroll wheel to zoom.

The browser problem is a bug with firewox and opera. Essentially the way Firefox anf opera handle embedded swf file that are set to transparent is different from internet explorer. When in transparent mode mouse events do no propgate down to the level of swf file. Since ziggy is programmed using actionscript 3.0 and it object oriented "language" uses event listeners as its primary method of capturing mouse events. The mouse a events such as doublke click, or scroll are not setected by the swf when viewd in these browsers.

There are a couple of workarounds for these browser bugs however given the debvelopment I plan to do on the interface i hardly seems an appropriot use of time to chase browser bugs. So my solution has been to simply change the settings so that the swf is no longer in traqnsparent mode but rather has a fixed color background.
After a few different grays i decided on a blue to match the page baqckground. but of course that can be changed if needed.

Here is some more information on [video tutorial maps]

One Step At A Time

One of the frustrating things about this project is the fact that are so many directions in which I could develop the mapping interface. More Functions,More Interactions, More Behaviors or Better Graphics each has its benefits and each could takes a while to develop to the point where I am satisfied enough to publish the application to my website.

Development can be a slow process so when your on a roll, you run with it. Unless of course you have to get back to work on other things. In my case I have to continue producing content for my site. So for I have decided to publish the first prototype of the mapping software "as is" and use it as my research piece. The other developments I have chalked out will have to wait until after June.

Ill post a link to the maps when I have finished compiling the xml lists for flash and Dreamweaver. I'm goning to name it "Ziggy 1.0".

Building Interactivity

Perhaps the most important aspect of this project that must be done well in order for this widget to work effectively for users is the interactivity that it allows.

First set of fundamental interactions:

1. Scroll wheel zoom.
2. Drag and Drop.
3. Up down,left and right pan with keyboard arrows.
4. Double click on node to go to external hyperlink.


1. Given the potential size of the maps generated in the node maps the user must be able to zoom in and out of the generated image. To accommodate this I have built a zoom control into the mouse scroll wheel.

2. When the user holds down the left mouse button anywhere on the map they can drag the map within the window to recenter areas of interest.

Combined with the scroll wheel zoom function users can recenter the map then zoom in on a new location (like google earth)

3. some users prefer to use the keyboard as their primary method of input. To accommodate this I have Incorporated simple motion controls using the arrows on the key board. in future versions I plan to include more "keyboard shortcuts" but that will have to wait until i have decided on all the "fundamental interactions".

4. One of the limitation with using flash as a development tool for user interfaces is the fact that flash does not allow you use the right mouse button or "right click" to control a swf. So in order to create a "intuitive" interface I decided to go with the other obvious interaction the "double click". This allows the map to sense when the user presses the left mouse button twice "quickly" and then opens up an external browser window to a designated web page.

This is where i hit my first big programming road block!

Each of these interactions individually is relatively simple to achieve in flash using actionscript 2.0 the problem arises when you combine them together and have to ask flash to handle multiple different "events" and distinguish between them.

In order to do this you need to create things called listeners to listen for events when they happen and inform the program so that it can respond.

Remember that each of the nodes in flash are movie clips. Well in AS2.0 there is node way to create listeners for mouse events that work directly with movie clips. A simple work around would be to convert the movie clips into button objects in flash and use button listeners but with the potential for over a hundred nodes on screen at any one time manipulating them as buttons in flash would be extremely cpu intensive.

To solve this problem I had to use actionscript 3.0. With AS 3.0 you can use event listeners for any object you want (movie clip, button ,sprite) as adobe has moved actionscript over to an object oriented language.

Of course this meant I had to completely over haul the prototype i had developed in AS 2.0 and rewrite it for AS 3.0. so preceded another week of debugging and hair pulling until i had worked around a number of road block that AS 3.0 introduced.

But the good news is that the new features that AS 3.0 brought with it allowed the code to node only compile faster it runs way more efficiently in the flash player. As it runs conditional statements such as "IF this do that" and "for" loops much quicker. Since the majority of my code is comprised of such elements it meant a vast improvement. To add to that adobe introduced the "sprite" which is like a slimmed down "movie clip" object that has only one frame. It has all the functionality of a movie clip but is way more CPU efficient to manipulate in the player using actionscript.

so all in all a necessary step but man what a pain in the butt. Total time spent developing this project so far 4 weeks solid!

Formatting Nodes & Node Connections

once of the most important aspects of the design of this mapping system is its ability to improve the readability of the information presented on screen. To do this clusters of nodes must be easily distinguishable from each other as well as parent and child relationships. To do this without overloading the user visually will require subtle but intuitive formatting of the node and thier interconecting lines.

children are scale down in size compared to thier parent nodes



this is inherited by all successive nodes so that sibling nodes are automatically put in relation to thier parents by association with a child node.



The inherited scaling is also cumulative so that children of children of children have the postential to become extremely small. This allows for the clean and clear representation of nested nodes. In addition the distaces between the nodes is also scales in proportion to its parent child status this has the effect of auatomatically making sure nodes fit in the available space thus reducing the possibility of overlap when displayed on screen.



Following the tree analogy each time the node map branches into a child the thickness of the line connecting the nodes is made thinner. This visually reinforces the relationship between chains of siblings and the relationship between parent an child bracnches.



Another optional enahcnement is color coding the connecting lines or node themselves to highlight group clustering. one option is to use the colors of the rainbow to create an intuitive scale ie (ROYGBIVW) like a thermal color scale to denote heirachy.



Although I have set up the map to do this I will keep the initial maps a single "theme" color / For example green for dreamweaver, red for flash, gold for fireworks and so on.

Connecting The Nodes

With all the nodes appearing on screen sucessfully the next important step was to build a function that can draw the lines interconnecting the nodes. each connection has to be draw independently so that it can be formatted independently in the future. This meant that i had to draw line between nodes using the id numbers to guide the pen to each location. So if a node matches its group id with the id of a parent node then a line is draw from that coordinate to the child node this contines for each match untill all the nodes are conected in one way or another.