Several years ago, I became somewhat obsessed with the idea that certain forms of digital communication mediums were lagging in their evolution relative to others. You would need Silverlight to view this, but this page demos a proof of concept of one of my attempts at improving electronic bulletin boards (aka message forums).
Here’s the back-story…
Consider the world of electronic communication mechanisms: email, instant messages, chat rooms, interactive web sites (such as blogs), bulletin boards and of more recent popularity, micro-posting (Tweets, Facebook status updates) – each has a certain structure and protocol that define how the author interacts with recipients and respondents, how historic correspondences are found and observed, and over time tools have been developed to maximize the efficiency for using each medium. An email client specifically caters to email discussions (duh). You wouldn’t necessarily use an email client for holding instant message discussions (though the lines have become blurred) because there are elements specific to emails that are uniquely different from instant messages, and these differences have left room for specialized toolsets.
Over time, we’ve seen tremendous improvements made across these toolsets. Email clients are intelligent and can even be used to predict which messages might be important to us. Instant messaging spans devices – you can start a discussion on your browser and continue it on your phone. The toolset for blogging is leaps and bounds ahead of where it had been a decade ago, and micro-posting is brand-spanking new. The toolsets have become more functional, more efficient, and more smart.
But, what about bulletin boards? (AKA message forums.)
A bulletin board is a technology that allows for one individual to post a topic, and then for any number of other users to reply in turn. Posts can be organized by categories, and meta-data supplements posts further. Bulletin board conversations can be threaded, that is, different paths of conversation can be spawned from the same root post. Consider, I post topic A, to which there are three replies, B, C, and D. Each of those replies has their own set of replies and in turn a giant tree of posts takes root. The different levels of communication are often visually represented by indentations, or collapsible/expandible buttons. If lucky, you’ll be able to understand who is replying to whom:
A. Initial Post
B. Reply to (A)
E. Reply to (B)
F. Reply to (B)
C. Reply to (A)
G. Reply to (C)
D. Reply to (A)
etc…
If unlucky, you’ll have to decode the one long thread based on context and possibly a nesting of “Re:” prefixes in the post subject (eg., “Re: Re: Re: Initial Post”).
The toolset available for manipulating bulletin boards pales in comparison against that of email clients and instant messagers.
Visualizing
So, my thought was to develop a tool that can visualize bulletin board discussions. Plot out posts and replies in a 2-dimensional structure. Attribute visual indicators to the meta-data (posts by me in red, by you in blue; posts I haven’t read show with a blinking border; etc…), and use that to enrich the discussions. Whereas it can be difficult in your standard bulletin board to figure out what posts are new, or to which exact post you’re replying, in a 2-dimensional visualization, this can be immediately obvious. Value can be further added by providing different types of algorithms for laying out or coloring posts. Rather than rendering as a tree (initial post on top, reply posts below), threads could be organized into other types of axes such as Time x User (showing the chronological timeline of when things were posted and by whom). There are a lot of possibilities.
When I first started tinkering with this idea, it was really difficult to pick a programming language that would be able to handle massive renderings of large datasets. The main options were Javascript+VML/SVG, Flash, or Silverlight (brand new at the time). Silverlight was the fastest with handling text rendering and text scaling so I worked with that. It became clear that showing 500+ posts (a typical Digg or Reddit comment thread) took up too much space and took too long to render, so I investigated alternate methods of showing a lot of stuff at once. A Google Maps type of implementation (multiple “zoom” levels plus drag-n-drop to pan) seemed the way to go in combination with a customized fisheye-algorithm.
