Filling in the gaps

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