Project: Online Deliberation Mapping Tool Development

As planned, version 1.0 of deliberation map was completed. It includes following features:

1. There can be only one seed for the deliberation map. When the map starts, it will look like this.

2. Any body can post and reply, without logging in. So, it is open to public. When deliberation map is running on a server, whosoever gets access to the URL of the deliberation map, can add posts to it. As a consequence, two users, probably from two different computers, can view and edit the map at the same time. Changes made by one user will be reflected to all others when the map is refreshed at the viewer’s end.

3. Currently map refreshes at a particular client computer when a new post is added by a user at the client computer, it is NOT refreshed at all other clients viewing the map.

4. The view is in a tree like fashion. Reply to a post is in the next level. Within a level posts will be in chronological order with earliest on the left and the latest on the right.

5. When a post is added, the map rearranges and scales dynamically to adjust the display to show all the posts on the map. The nodes, representing the post, decreases in size automatically to fit into the display. For example, the map changes to look as follows:

Technical Details

• The deliberation map has been implemented using ASP.NET technology.
• It has been developed based on MVC (Model View Controller) architecture.
• Back-end or server end details:
  • The database contains two tables, first table, named posts, holds the data which is required to show the structure of the map while the second table, named content, contains the actual content of the posts. The columns in table posts is post_id, father_id and post_type and the columns in the table content are post_id and post_text.
  • Stored procedures are used to update the database. The store procedures are:
    • get_one
    • get_all
    • clear_all
    • add_post
  • Database access is done using a C# class called DBAccess, which calls the stored procedures of the database. The functions in the DBAccess class have the same name as the stored procedure they call. For example, function get_one calls stored procedure get_one.
  • Each post will be an instance of C# class Post with fields corresponding to the columns in the database, viz., post_id, father_id and post_type.
  • Deliberation map is shown in the page display.aspx . In the code behind this aspx page, i.e, display.aspx.cs, the functions get_one, get_all and add_post are defined and exposed as web-methods. These functions have been so named because they call the functions with same name in the DBAccess class. The functions in the code behind which are in C# will be called from the client from their javascript code.
• Front end or client side details:
  • The client side is where heavy processing will happen, this is for scalability reasons. All that is requested from the server is the structure of the deliberation map, which is nothing but the data residing in the posts table of the database.
  • On page load, the javascript included in display.aspx makes an ajax call to web-method get_all to get all data from the posts table of the database. This data is required for deciding the structure of the deliberation map, i.e, to decide which post should be on which level and the order of posts within a level. Further, the color coding of edges based on the response type is decided by this data.
  • The client sends request to the server whenever a user wants to see the details of the post. In the current version, this request is made when the user hovers over a node of the map. A user is going to see utmost one post at any point of time, we take advantage of this and have only one tool tip window. We position this tool tip at the node where the user is hovering the mouse and updated the data in the tool tip with the data corresponding to the post that the node represents. This is done though a ajax call to the server’s webmethod get_one.
  • When a new post is added by pressing reply button on the tool-tip, a ajax call add_post is made to the server, using the data populated in the tool-tip.
  • The layout of nodes in the UI has been handled by javascript function draw(). This function derives the levels of every node and also the position of the node within its level. The whole display is divided into uniform rectangular regions. The height of a rectangular region is decided by the number of levels in the tree, while its width is decided by the number of nodes in the most populated level. Once, the grid is setup, the nodes are drawn in their respective regions.
  • Whenever a mouse is moved, its position is analyzed to detect which rectangular region it is hovering over. Further, within a region, it is detected whether the mouse is hovering over a node. If yes, a reverse mapping from region to node is used to find the post which has to be pulled from the database, using get_one web-method.
  • All the ajax calls, send and receive data to and from web-methods using JSON object, this was preferred over XML because JSON is faster.

Reference

• JSON (vs) XML

Project: Online Deliberation Mapping Tool Development

Before we start implementing the project, we need to decide the timelines and milestones so that the product can evolve in a systematic fashion. To do this, we needed to prioritize the features and decide which features are going to be in the version 1.0 of the product. Further, we needed to fill in the gaps, that is, those aspects of the tool which may not be features per se but would be necessary for the product to be functional.

The priority features for the version 1.0 are :-

• Structure of display of the posts would be in a tree line fashion. We tried time line representation and concentric circle representations and various flavors of tree representations, finally we decided to go with a tree model which would make the deliberation intuitive to follow and easy to contribute to. An approximate sketch of the tree representation is :-
• Time slider : Users entering the conversation should be able to see the state of the deliberation at any previous point in time.
• Types of connections between posts. A reply to a post can be of neutral, agree or disagree type. These will be represented by different colored edges connecting the appropriate posts. Another distinct color will be allocated for edges representing connection between a post and a question to that post.
• There should be visual cues to the annotations to a post. We came up with a name “annotaticons” for such visual cues.

Subsequent questions that arose during design phase:-

•  Should a user be allowed to delete a post made by him/her?
  • To this question, we thought that a user should not be able to delete a post because there might be many subsequent posts which might have resulted from this particular post. If we allow a user to delete a post, the context for the posts which were reply to this particular post will be in jeopardized. The user might own a post but he cant own the subsequent conversation. Hence, to maintain the integrity of the conversation, we have to disallow users from deleting their post.
    • However, a question arises. Can we distinguish between a delete which can disturb the context of the deliberation from a genuine error, say a misspelled word, in the post ? This seems to be a complex question for version 1.0.
• Should the deliberation map be updated in real time ?
  • I thought of this while trying to design the code in the ASP.NET platform. The complexity development of the tool will increase by leaps if we have to allow the map to be updated in real time. However, if we want to, we can use SignalR library of ASP.NET platform to implement it. Definitely, we are not going to do this in version 1.0.
•  How will the tree be represented in database ?
  • This is a non-trivial question. As we need the number of calls to the database to be minimum. There has been considerable research into this problem.
• How many seeds (independent post) do we allow in one deliberation map?
  • We restricted it to one for version 1.0, so that the tool remains simple. We call such a post to be the SEED of the conversation.

To sum up, lot of implementation related questions are arising while developing the tool. I would interested to know if you can foresee any question that might arise. Or if you think the questions that I have raised might have been tackled differently. Even suggestions for new features are welcome. Please do feel free to reply to this post. Further, I will be sharing the issues that I face while I implement the tool, in my subsequent posts.

References:-

• http://en.wikipedia.org/wiki/SignalR
• http://stackoverflow.com/questions/4048151/what-are-the-options-for-storing-hierarchical-data-in-a-relational-database

Project: Online Deliberation Mapping Tool Development

As the fall semester was about to end, we were about to finalize the design and functionality of our tool. Starting from where I left in my last post, we went on to step 4 of our design sprint. In this step, each one of us, individually, made a storyboard using the materials from mind map and the crazy eight phases. The storyboard would highlight the most important functionality desired by that individual from the tool.

The storyboard was to be stand alone, anonymous and with a catchy title. These requirements were needed so that the storyboards can be reviewed without any bias and the best ideas for the tool would surface. There were three rounds of review of the ideas in the storyboards. First, the silent review round. In this round, people walked around going through the posters looking for cool ideas. Then, in the second round, each person described the idea which he liked the most. If there were some important aspects of this idea which was being missed, the actual contributor of the idea would fill in. Finally, in the third round, there were special stickers given to use. Each one of us would pick two features that we definitely want the product to have.

By the end of the design sprint, we had clear idea as to what needs to be in the tool and how important or novel each feature was. So, we were setting the stage to move to the next phase of tool development, that is implementation.