Cycling On

The software development cycle

I have the first prototype complete AND I have detailed user feedback data however one of the key components in beta testing software (specifically user interfaces) is making changes to the interface as recommended from the feedback and then beta testing the ALTERNATE interfaces. This form of cyclic research development is usually reserved for research teams given the short time frame and the large amount of work involved.

I am pleased to say that during my TIP research I have managed to beta test multiple versions of the user interface and make significant strides in developing innovative designs that solve fundamental issues surrounding semantic mapping of digital resources. There remains a number of "bugs" that still need to be solved and of course there are still a great many ideas that have to be developed into workable prototypes. Given the challenges and the fact that these interfaces are truly original and to some degree can be considered a leading edge technology I am very pleased with the progress that i have managed to make in such a short time.

Hopefully with only a few weeks left of this I have finished building the some of the prototypes that have been designed directly from feedback the second and third beta testing cycles as they demonstrate just how far the interface has come from the 1.0 version.

Feedback From Ziggy beta 1.0

Overview of Data Collection Method
I have changed my chosen method of data collection significantly since the beginning of my research. Initially i was going to extrapolate data from trends and stats on resource usage from users of my site using analytics,alexa and a variety of other site trackers to build a picture of how the video tutorial maps impacted the browsing habits and affected the ease of use of the site. Since I have begun testing the user interface it became clear that I there would be subtle details and important user feedback that simply would not be apparent form analyzing site statistics. So I have opted for a more user centric analysis that uses direct observation and interviews that asses the different perceptions of users about the UI while using it for the first time.

During this first phase of beta testing I gave sat with users and asked them to test drive a "new browser" for my website. In each case the users had already been exposed to my site and used the traditional index/course hyperlink lists for navigation. I clearly explained to each user that this was a piece of software in development, a "beta" and that the browser they were about to use was "not finished". This was done to encourage the user to be critical of the user interface and not feel as though they would be offending the creator of the interface by recommending changes. Also I did not want users to feel as though it was complete and therefor unlikely to have modifications made to it based on their input. Being completely honest with users test driving the software enabled me to have a privileged view of the tester as a developer and work directly with beta users documenting their official and unofficial responses.

Each beta tester/user was asked a series of informal questions (each question had the same content and wording but was asked in the form of a informal line of questioning) this was done to put the user in a more relaxed mood with the intent of coaxing out greater honesty and detail from their responses. The result of using an informal interview style were extremely positive. Users exhibited an enthusiastic willingness to comment on a multitude of aspects of the user interface design and even went as far as spontaneously providing creative and insightful ideas for further modifications or "improvements".

Although The generated video tutorial maps are in many ways an integral part of the user interface itself for the sake of clarity I have attempted to classify the user feedback into two areas of analysis. The user interface interactions ie (the way the tester manipulates the mouse, uses the keyboard short cuts, and the interface tools when browsing the map) and the way the tester "reads" the information content in the map.

User Interface Interactions Analysis
There were three fundamental user interaction methods in the first set of tests on the beta 1.0 software: Dragging and dropping the map in the window, Zooming in and out of the map with the scroll wheel and double clicking to visit external content.

What was the first thing most users did when they entered the map?
What responses were users expecting form specific user interactions?
Were they surprised by UI response's?
How did users navigate around the map?
What was the most common user interaction method?
Did the user discover the UI interaction automatically or did they require instructions?

What aspects of the UI design did the users comment on as positive?
What aspects of the UI design did users comment on as negative?
How would users change/customize the user interface?

The overall response to the UI was positive. However the time it took for users to feel comfortable with the interface was reflected in their self assessed ability/computer literacy level. In cases where uses had limited exposure to computers and lower confidence levels their was a high degree of initial apprehension with using an unfamiliar interface, these users generally took a greater amount of time to "master" the interface controls.

The more computer/tech savy users stated exploring the UI immediately using universal controls without using prompting from the instructions page notably different from less experienced users who required clear instructions in order to fully use the UI tools effectively.This identifies a common chasm between experienced and inexperienced computer uses as far as UI design requirements. Creating a UI devices that are universally accessible and require no manual is once of the "holy grails" of UI design. This task generally becomes more difficult as the capability of the software increases. The more tools users have the more difficult a UI can be to use for first time users and the longer it takes to become a "proficient" user.
A good example of this would be adobe photoshop. First time users are often overwhelmed by the choice of tools and the number of options they have available to them. With many less confident users limiting the number of tools and techniques they use with the software to a handful of number of tools available. Even when they master this limited set of tools they are often reluctant to try new tools in fear of confusing the knowledge they already poses leaving them on a plateau of the "occasional tinkerer".

In all cases users presented a number of creative uses for the UI and the concept of mapping online resources and content. As expected users had their own personal preferences to towards UI design but there were a number of common points made by the first set of beta testers.

Analyzing The Mapping Language
The range, depth and eagerness or user interactions was just one aspect of the UI design analysis. The other important factor that was investigated was the users inate understanding of the "language and structure" of the map itself. Some of the users were self confessed visual learners while others adamantly declared that they prefer traditional page layouts with text based content. Ultimately these differences in learning style did affect the "favour" of their responses but in either case users were able to identify key aspects of the interface design that they recognized as assisting with their "learning" or acquisition of a new concepts.

Was the map intuitive to interpret?
Was the node text clear to read?
Could users identify the theme of the map?
How did the user interpret the colors in the map?
How quickly did users identify patterns in the map structure?
How did users perform when locating unfamiliar content?
Once users identified patterns in the map structure did this aid the process of locating unfamiliar content?

What aspects of the Map design did the users comment on as positive?
What aspects of the map design did users comment on as negative?
How would users change/customize the map/interface?

With this type of new and unfamiliar user interface there are countless modifications that could be made and factors that must be considered to create the "best" user interface of this type (visual concept mapping of digital resources). The various nuances of UID and the science behind the language and structure of the map itself could be the subject of number of detailed research papers. Even the optimization of data packing efficiency versus readability & usability could be the focus of a phd on its own so I don't expect to definitively answer the majority of profound questions raised by this research project. However the initial feedback i have already received has yielded some valuable insights into what factors need to be carefully considered and controlled, what must be flexible, what elements can be potentially controlled/customized by users and what can be considered to be entirely optional when designing interfaces of this type.

Streaming Video Content Into Ziggy On Demand

The powerful aspect of flash that initially convinced me that flash was the best medium to develop the mapping software is its ability to load multiple video/animation "movie clips" into the flash environment and treat those video or vector animations as objects. Treating them as objects means that i can change the scale, reposition or even animate the moving video just as i would a simple bitmap image (using actionscript). When you combine this with the fact that flash can do all of this in a very small file size or required CPU/RAM flash becomes the only choice.

One of the chief design goals in the development of visual mapping software and a popular request by beta users is the ability to load the video tutorial inside the map itself instead of having to open up a new web page an view content externally to the map page.

Well good news, Ive just completed another milestone and have successfully created a working prototype that achieves this. When users double click on a node instead of opening up a new web page and viewing pages externally users see the video tutorial and instructions load inside the map. Because it is inside the QSLS environment it is associated with the content node (as it is nested in inside the mc) and can be positioned automatically then scaled and dragged around by the user at will.

Of course this is all done on demand so users can actually view multiple video tutorials side by side to compare an contrast techniques or view veins/themes of content in a node cluster.

The really great thing about this whole beta testing and development cycle is that i have managed to make the entire map run off a xml file and the content that is loaded into the environment and associated with each node is also structured using simple xml files.

This means that the content floating in the mapping environment comes directly from the same xml pages that feed my XSL pages on my website. So users can browse content using the regular menus and indexes of my site or view the same styled xml pages in Ziggy without me having to create special versions for web pages that work in the QSLS environment. Since XML is the future of web dev this could become a very powerful GUI. Plus given its ability to efficiently stuff allot of information into a relatively small amount of space it has some promising applications in mobile web services and iphone/UMPC devices.But more importantly coupled with a semantic agent Ziggy could become a great asset when having to deal with semantic search results or websites of the semantic web.

Quantum Leaping

Initial user feedback form the first round of beta test indicate that easing the work users must do when moving from node to node has become important factor to consider when trying the create a user friendly mapping interface. Since users of my maps will most likely be required to use the scroll wheel and mouse intensely when moving up the node hierarchy or moving from a node on one side of the map to another. Even in occasions when the user wants to gain a clearer perspective of other related nodes around a parent node they need to drag an zoom out each time.

Automating these tasks and them building into the interface so that users can access these tools in a simple routine way. Building tools such as this requires a dynamic function that responds to each node uniquely. The function would have to recenter the viewing window on the node that has been clicked on, then zoom into the node position so that it becomes readable in the window view.To fly into a node on auto pilot we would need the coordinates of the chosen node and the "child value total" const (cdt) these would change depending on the node that is clicked on.

Today I completed the function and used the built in easing class to smoothly accelerate into the node location. The effect is somewhat like Google earth's interface. When the user presses the "Ctrl" key then double clicks on a node the the autopilot is activated and guides the user to the node.

I chose to use "ctrl" double click as it was a more efficient action than requiring the user to triple click on the node and it is in line with my current minimalist UID.

Since the content in each node are quantized learning modules and users move form video module to module following a non linear course. Ive nicknamed the act of flying or leaping between quantized nodes "quantum leaping". The phrase has it roots in quantum physics but i figured it was appropriate as the mapping engine is called Ziggy.

demo: ziggy 1.1
demo: ziggy 1.2 (with quantum leaping)

Note: hold down the ctrl key and double click on a node to quantum leap.

The beautiful thing about working xml and seperating the data from the mapping engine itself is that i only have to update the swf file embedded in the web page to upgrate the maps interfaceas the map essentially displays and manages external multimedia files.

Visual Bread Crumbs

One of my primary goals in creating this mapping interface is to design it for visual learners. Creating symbolic scale markers and putting a text based bread crumbs in a panel at the top of the map does not fulfil this goal sufficiently.

To make the bread crumbs and scale markers more visually oriented I propose a visual form of bread crumbs that can be shown in the side of the window. The visual bread crumbs panel will consisted of a series of thumbnail representations of the map at set scales. As the user diggs deeper into the map by zooming down to content nodes a series of map thumbnails are created documenting scale changes.

A visual reference of this form could serve as a valuable method of "grounding" the user as they leap about the map following along the paths of connecting lines between nodes. This would reduce potential disorientation and increase the ability of the user to know where they are in the map without having to zoom out to get their "bearings" (something i noticed beta users doing frequently).

User Friendly Zooming Interface

Once the constants in the positioning algorithm where adjusted to reduce the likely hood of node overlap it left the map with a high level of scale differentiation between 1st order category nodes and content nodes. This meant that the user had to zoom in a great deal to read the content nodes. Since the map is designed so that users can explore content across the map this meant the map required heavy use of the scroll wheel to maneuver from node to node. After a few times of doing this beta users reported that they felt they where spending the majority of their time and effort zooming in and out of the map.

This is a specific issue that i imagined might become a sticking point with users. After giving some thought to the matter I have decided that the best way to face this issue is to create a user power tool. In particular a power tool that gives the user the ability to fluidly and relatively effortlessly change scale in the map around points of interest. To this I'm going to build another fundamental method of interactively with the map.


Actions
keyboard shortcut
If a user presses the control key the clicks a node with the left mouse button

Mouse only
If the user triple clicks a node.

Triggered Effect
The viewing window will then automatically center on the node and zoom in to a readable scale. In effect users can leap from node to node throughout the map and automatically change scale.

Self Similarity

One of the problems i have discovered since building the first set of video tutorial maps, is the fact that the maps show a high degree of self similarity.

Essentially self similarity is the property an object exhibits where it shows the same structural features regardless of scale. For example: [fig3].

Self similarity presents a unique problem to my mapping project as it makes the identification of scale difficult for the user. The importance of being able to recognise the zoom level of the image window with respect to the global map is crucial. Firstly it allows the user to locate their relative position within the map, easily find the parent node and associate context to the video or article they are viewing from the "content" node.Secondly self similarity works against the user when they are trying to uniquely identify content node clusters as to quote a user from initial trials "they all look the same from a distance".

Breaking Symmetry
One possible solution to the problem of selfsimilarity to impose symmetry breaking on the positioning of the nodes. This will result in a asymmetric positioning of parent nodes and in turn clusters of content nodes. Of course i have yet to figure out the best way to break symmetry in a controlled manner.

Artificial Scale Markers
Another possibility is to create some sort of artificial scale marker that the user can use to quickly identify the scale of the section of the map in the viewing window. Although their is a clear scale change between parent and child node the effect is only useful form a distance and you need to have a relative reference to see the scale change. when you are zoomed in the map their is no obvious relative reference so an artifical reference such as a scale marker must be made.

An effective scale marker could be to create a symbolic code that appears at the top of a category node. A simple symbolic code could be to use a series of dots to denote the hierarchical level of the parent node. For example:

1st order parent node: one dot, .
2nd order parent node: two dots, ..
3rd order parent node: three dots, ...
and so on.



The dots would be useful they wouldnt require much processing to create (as they are points) and the user could get a quick impression of what zoom level they are at by looking at the nearest parent category node. But the dots themselves do not take up much information space.

Note: The content nodes would not contain any scale symbols as the nearest parent node will remain in the window area while content is being viewed.

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.

Positioning Objects

Once the coordinates have been calcualted and stored in an array the next job is to buld a function in actionscript that will create the graphic for the nodes. The easyest way to do this off the bat is to create new movie clips then draw shapes inside then and add text fields and images. once this is done the movie clip called is then told where to position itself iniitally on stage using the coordanate stored in the coordainte array. This is the starting position for the node in the map.