Recently, I came across a national geographic article describing a theory behind how easter island statues were moved — or more appropriately walked. What was not mentioned in the national geographic article is that this theory also explains how TallyTree visualizations work .

Using ropes to walk the moai may not be the most efficient or fastest way that the Rapanui people could have moved the moai statues but it would have definitely been a very engaging experience. Strong ropes where attached to the forehead of the statues and then people divided into groups, each group in charge of pulling one of the ropes. They would have had to use a signal to keep themselves synchronized and balance their forces. If people in one side pulled too hard or reduced tension on the rope, the other side would have had to react quickly otherwise the statue would fall. From the hundreds of moai statues at least a dozen of them did not make it all the way to their destination.

TallyTree works using a similar concept. People are divided into groups based on what side they will take in an argument. They will pull statues or other figures — not using their muscles — but using their power of reasoning and communication. The goal of the visualization is not to balance the forces in an argument but to capture the dynamics of discussion as the argument unfolds, at an individual level. A person exploring a TallyTree visualization should be able to easily see where the collective force is leaning toward as well as where each individual positions themselves and how they are contributing to the discussion.

I need to choose a small and efficient visualization library that supports force directed layout and works on majority of browsers including those on smart phones. Some visualization libraries are written with either Canvas or SVG in mind while some others are at a lower level and support both methods for rendering the graphs. I am considering both SVG and Canvas during my testing to see their potential. If you have ideas about how or why I should use one of there methods, please let me know.

Can I avoid both SVG and Canvas and create my visualization purely based on CSS and positioning of DOM elements? I came across a pure CSS line graph during my searching which makes me believe it may be possible to create the TallyTree graphs in that way. However, I am not willing to go down that road right now since the benefits are not clear to me and it may significantly limit how I could change the visualizations in future. For example I don’t know how I would be able to control curving of the edges of the graph.

I only need the force directed layout for now, so I was not very concerned about other aspect of these libraries. Below is a summary of what I found. I tested demos of these libraries on Firefox, Chromium and the native browser on my android phone which is a samsung galexy s running android 2.2. Unfortunately, SVG support on android was disabled in the webkit built until version 3.0. I would love to use SVG because of all its benefit, but I am not sure if that would be a good idea considering that there are still many Android 2.x devices out there.

Arborjs

Arborjs is well documented and focused entirely on force directed layout. It does not force any particular drawing method so I can use Canvas or SVG. There are a few examples demonstrating usage of Arborjs for instance a graph with 117 nodes. For the most part performance is reasonable however in this demo the graph takes a long time to balance, which may be intentional and fixable by tweaking parameters. The demos also worked on my android browser.

D3

I heard about D3 from a few colleagues and I specially like their focus on data. I tried some of their force directed layout demos such as this one. D3, at least in the demos use SVG to render. I dont think it is heavily dependent on SVG since they are a low level library, it should be easy to render things to Canvas as well.

JIT

JIT is the only library I came across that has also incorporates simple zooming and panning to all its visualizations including the force directed layout. It requires a nicely formatted JSON as input which is cool. The only issue I found with it is that when you move the nodes in the graph, it does not seem to animate them back to original position — that is something I like to have since the original layout of the graph has significance.

A few other libraries/frameworks out there that support force directed layout:

• Processing which has been around for some time and is a mature visualization toolkit. However, for the purpose of this project I think processing may be overkill so I decided not to use it
• Springy is what we used in the first prototype of TallyTree and it relies on canvas. In that implementation we used Raphael to handle drawing of the curves and since Raphael renders as an SVG element into the browser I was not able to see it on my old mobile phone
• I came across another canvas based layout that surprisingly worked well on my phone, but it is build with canvas in mind so it would probably be difficult to use SVG to render the visualization — but I am not sure yet

Almost all of the libraries I looked at above seem like a good fit and have their own advantages. I need to have an starting point and I like it to be something minimal and flexible that is under active development. I am going to start implementation of TallyTree with Arborjs and if any blockers appear along the way I may fall back to any other one of these libraries.

If you have any suggestions or comments please let me know!

My goal this week was to define what information needs to be saved by TallyTree plugin and how I will use WordPress API and the database to store these information. Fortunately WordPress — with all its power — has a very elegant and simple data model that is easy to understand. Everything I needed to know was available on Codex database description, including this nice diagram.

Wordpress data model

WordPress also has an API that provides access to the database. In particular functions to work with meta data for posts, users and comments is going to be very handy. I do need to add a table to the database to store customizations of each tallytree object so that a user can create their favorite configuration and reuse them in several posts. Below is a list of information that will be stored that I came up with so far.

Information needed for each post

These information will be added as meta data for post using the WordPress API.

• enable_tallytree: boolean to enable/disable TallyTree
• tallytree_id: the id of the TallyTree used in this post
• question: the main question which will be under discussion
• answers: an ordered list of answers which can be empty
• show_comments_list: whether to show classic nested comments or hide them

For a TallyTree object

This is the configuration table that I will add to WordPress called wp-tallytree_themes

• theme_id: primary key
• theme_name: an alias for this theme for viewing in the admin panel
• type: the type of this tallytree. possible values so far are “statue” or “convex-polygon“
• statue_path: the URL or local path of the image appeared as statue (statue only)
• background_image: URL of the background image
• css: URI of the CSS file containing the styles for this theme
• width: in pixels
• height: in pixels
• min_votes_before_fall: minimum number of votes that can make the trunk fall down (statue only)
• fall_percentage: the percentage that makes the statue fall to one side (statue only)
• max_questions: maximum number of questions that can be added to this tallytree. (convex-polygon only)

For User Votes

This is a table that I will add to WordPress called wp-tallytree_votes

• user_id id of user who accepted a comment
• user_email email of the user who accepted (voted for) a comment
• comment_id id of the comment that was accepted
  
• date the timestamp of the time this user voted for this comment

For each Comment

These information will be added to each comment on a TallyTree post — as meta data using the WordPress API.

• tallytree_for_answer: The id (position in the list) of the answer that this comment was made for. If the comment is neutral, this value will be -1

 Additional Information

The values below do not have to be persisted. Just to do a sanity check, I need to be able to get the following information on the fly.

• Number of votes for each answer
• List of users who have made an argument to support one of the answers
• List of users who have voted for a comment
• List of users who have only left neutral comments
• The time a user casted their vote
• The time a user left their comment/argument
• …

My experience designing data models is very limited, but fortunately I could take advantage of the WordPress API here for the most part.  One thing in particular that I am still not sure of and I think can be improved is the way to store the timestamp for when a vote was given. Voting for a comment is a concept that TallyTree will add to the comment section. Multiple people can vote for a comment but in most cases one person can vote for only one comment per TallyTree discussion.

Dear reader, please let me know when you see any areas that can be improved or if you have other comments or suggestions. I will edit this post as I receive feedback.

Based on some of the comments I received about my initial design to visualize comments for a two-sided question – I decided to create a new visualization that supports several answers. There are two general use cases for this visualization:

• Owner of the TallyTree wants to define 3 or more choices as potential responses and ask participants in the discussion to pick the best answer. But the owner does not want to allow any more answer to be added by participants
• Owner wants to allow participants to provide their own responses. Optionally owner could define a few choices to help kick start the discussion

I decided to represent each response with an angle in a convex polygon. When there is more support for the answer represented in one corner of the polygon the angle of that corner will decrease in size creating the effect that the polygon is being stretched toward the stronger group. Below is a simple figure showing how the layout will be calculated.

In this example the K1 response has more supporters so the angle on that corner has decreased.

Do you think there are any potential issues with this visualization? Do you see any suggestions to improve it? Have an idea of how the area inside the polygon can be used? Let me know in the comment section below

The goal of TallyTree is to quietly integrate into a blog post when needed. There are two main actors who would interact with a TallyTree: Owners and Participants.

• Owners are those who have edit rights to the blog post containing a TallyTree. They can create, modify, and delete the TallyTree associated with the blog post. They are also responsible for moderating the discussion on that blog post
• Participants are those taking part in discussion and voting for their favourite arguments

The interaction with TallyTree starts with owner of a blog post creating it. The owner can create a new TallyTree and configure its option using the plugin settings page. Below is a mockup of how that page could look like.

Mockup of TallyTree plugin Settings Page. I have left some room for options that will be added. Some of the options are applicable to certain type of TallyTree, so I might change this layout to make selection of tallytree type more prominent.

Once the user customize and save their new TallyTree it will become available to all the posts in the blog. However, I would think that normally people would create a new tallytree for each post. I am not planning to put restriction on how many times a tallytree can be reused. However, since tallytree going to integrate into all parts of blog post and comment section, I will be limiting the number of tallytrees to a maximum of one per post.

The next step after creating a TallyTree, is to actually insert it into a blog post. For the first iteration of this I will actually use a shortcode to keep things simple. Once I get a shortcode that works decent, I will design an interface to generate it. For now the shortcode is going to look something like this:

[tallytree post_id type left_text right_text question
statue_path min_num_voter fall_percentage ]

For example:

[tallytree 5 "two-sided" "Yes" "No" "Should TallyTree Allow Multiple
Emerging Responses?" "Chess_piece.jpg" 50 70.5 ]

This is going to be for testing and I dont intend to ask real users to configure these shortcodes in their blog posts.

Let me know if you have any questions or suggestions.

Do you ask two sided question on your blog? Yes? No?

Two sided questions are everywhere on the blogs and forums and stack overflow etc. However it is challenging to form constructive discussions around a two sided question that generates a lot of controversy. Well that just means that there are lots of people on both sides of the argument. We can think of such a discussion as a game of tog o war.

There is a strong tension between two groups during a game of tog o war.
(picture is from Tenessee Journalist)

Just by glancing at the image above we can get a lot of information about the game. For instance we easily distinguish those who are playing from spectators. We can see there are six people on one side and they are trying pretty hard to pull the other group toward themselves. We can understand and visualize the physical model for tension very well.

In TallyTree visualizations the avatars will represent the people and the edges are the ropes that will allow people to pull an arguments toward one direction. Because TallyTree will be asynchronous, it will likely progress much slower than a game of tog o war. In order to capture what side the argument is leaning toward we will put a figure that can be tilted, in the middle of a two sided question. Below is the design that we came up in our previous implementation.

Each person who provides an argument, or support someone else' argument will contribute a force to pull the object in the middle toward their side. A force based layout will be used to distribute avatars in a natural way around the figure in the middle.

Can you guess where does the tree structure come from?

The tree structure is based on who you support. In other words, who convinced you to take their side, or motivated you to make a good argument for the side you stand for. The trick is that you have only one vote. You can choose to support only one other person who argued for the side that you want to support.  If you don’t support anyone else’ argument and make your own — hopefully original argument — then you will become a root node. The choice that users make is a very simple interaction that will be added right where user place their comment. For a two sided question, there will be three types of comments:

• Neutral, either you are not sure or need more clarification, or just want to leave a humorous comment
• Comment for “left side” which means you support the left side
• Comment for “right side” which means you support the right side

Example of integration options to choose side while leaving a comment for the blog post. This is to show the interaction requirement, the actual implementation will have a different visual design.

Once a user posts a comment that is to support left or right side, that comment will become available to vote on. That means that other viewers of the blog can choose that argument as their reason for supporting one side. As I mentioned earlier, each user will have only one vote per TallyTree and consequently, per blog post. However they can leave many arguments or comments, or reply several times to other comments, as is the case with existing comment systems.

I am happy to announce the start of the TallyTree project. TallyTree is a set of interactive visualizations to assist discussions in blog posts by integrating into the comment section of your blog. The project was originally designed and prototyped by Elyse Regan, Aras Balali Moghaddam, Lu Di, and Giles Crisfield as part of a course project for CSCW at university of Victoria, BC in Fall 2011 which was supervised by Dr. Margaret-Anne Storey.

A basic example of a TallyTree visualization in a discussion around a two sided question.

I have been wanting to see what happens when people actually use our wordpress plugin. However, our focus on the first iteration of the plugin was to arrive at a working prototype due to time constraints of the course. Although the code for this prototype is available, it is not fully-fledged and is missing many essential features before we can list it on wordpress plugin directory.

Ever since the course finished, I have been wanting to go back and finish this plugin. I want to make it intuitive and usable and to see where people will take it and how they will use it. But somehow it always fell down to the bottom of my list. After a few months, it looks like the stars have finally lined up properly — nReduce came to rescue! Since I joined nReduce, which is an online community of entrepreneurs, I have been much more motivated to finish this project.

My plan for the next couple of weeks is to first iterate one more time over the design of the visualizations and produce some mockups to capture the vision of this project. That way I can hopefully receive more critical feedback before I dive in too deep into the implementation. If you want to get involved in any way, or have other comments or suggestion please get in touch with me.