Archive for June, 2007

Threading Comments for Conversations

Jun 07
28

The mistake that a lot of websites make with comments is treating comments like data-structures. The website Digg.com recently released a new commenting system that was met with a lot of hostility. The commenting system is overly complex both in it’s use and it’s interaction.

A typical data structure approach would be to have each comment parented to another comment allowing things to cascade deeper and deeper. The problem with this is that conversations don’t work like that. Comments on a website represent a conversation between people. When you have a conversation you don’t have a structured flow. You talk, you interupt you introject, you catch parts of various conversations, you’re human.

Most commenting systems aren’t setup for this. The interface encourages users to have an intimate discussion with hundreds of people…. And we wonder why it doesn’t work well.

I took a stab at creating a concept for an alternative commenting system based on the Digg design. The objectives:

  1. Make it easy to read and understand.
  2. Have one central topic and make it easy to have secondary replies and off-shoot conversations.
  3. Optimize the design and layout for shorter comments (most comments are a couple lines)

Digg Comment System Concept

Concept explanation

The first column is the main thread of the conversation. You can follow the core comments reading straight down the page. Secondary comments and replies are read to the right of a comment in the second and third column. If there are more replies then fit in three columns a fourth column holds the additional replies as icons. Users can hover over the smaller icons to continue reading the conversation. They can also click to read the conversation on a seperate page.

This keeps the main conversation on topic and allows for deeper in-depth discussions to continue. This encourages people to actually talk and discuss a topic in smaller groups rather then commenting and moving on to the next story.  (This will also help people who have something to say to contribute without fear of being dugg down)

The layout assumes that most comments are short and allows for one, two or three columns for text. Most comments would be one column but if someone wants to write a lot that’s ok. The height of the comment would be flexible as well.

One key element of the design is that it greatly increases the information density. You’re no longer scrolling to track a conversation or expandin/collapsing nodes. The key conversations drift to the top and secondary topics are discussed in smaller sub-groups.

The key is to think about comments and discussions in terms of communication tools instead of as a datastructures.

Two Books in my head

Jun 07
22

There are two books that have gotten my brain thinking.

1) Myths of Innovation is a fun and easy read by Scott Berkun that explores the myths and truths behind the process of creating new ideas and bringing these ideas to market. The book is really well researched and really made me consider if the focus should be ‘innovation’ or just creating great products. I give it four stars, I’d give it five stars but since Scott gives me a shout out on page 164 people would think he just bought me off with a beer. Scott’s a good guy and the books a great read. Get it from Amazon here.

2) Blink – ‘The power of thinking without thinking’ explores the split second things that your brain does in the fraction of a second. Some call it intuition, or instinct, perhaps a gut feel. This book explores the phenomena of
how your brain takes subtle cues & processes things in an instant. One of the core ideas that Malcolm Gladwell promotes is that our brain ‘thin-slices’ information and you can often learn more from the thin slices then from the larger view. The book is an interesting read, and made me think much more about the decisions I make and how and why I’m making them. If you’re interested in some of the inner workings of what makes your own head work Blink is a good read. I give it 3 and 1/2 stars. Pick it up from Amazon.

Linux Distributed Bug Tracker

Jun 07
20

So I just got back from the Linux architects conference held at Google in Mountain View, CA. It was a good trip and I hope that these types of summits help spur the collaboration that needs to happen.

One of the highlights for me was Mark Shuttworth’s keynote. He spoke not of the individual features, or high level visions but of the real day to day problem of duplicated efforts.

Because of the distributed nature of development there are many distributions that duplicate their efforts by opening, fixing and merging the same bugs across various distributions. This is an easy opportunity were we can work smarter not harder.

I approached Mark at the reception and mentioned how the Wikipedia also has a fairly distributed nature but that individuals are able to track and monitor topics of interest. Users are subscribed to a topic of interest and it becomes difficult for someone to make a change without notifying everyone who’s interested in a particular topic.

Mark said: “What if you could subscribe to a bug tracker like you do with RSS?”

I think the concept is novel in that it allows distributed projects to monitor changes, status and progress in a distributed way. You subscribe to the things you care about. You could subscribe to a particular file, folder, a particular bug or a particular key phrase. Then when someone makes comments or change you know about it.

The actual feed would be RSS so it would work with existing feed readers and aggregators. The content of the feed would be new bugs, bug comments, code changes or other related changes.

Many bug tracking systems and source code packages already have RSS plug-ins and tools. SVN and CSV, Trac, & Bugzilla all have RSS components.

The part that’s missing seems to be the actual feeds from all the major groups.

The beginnings of a distributed bug tracking system has to start with a simple standard. Another approach that was discussed was refered to as “bCard” (kind of like a an ID card for bugs). This approach would create a microformat interchange that could be indexed and searched. This would be a portable format that could be used to interchange data between different bug trackers.

This approach is also interesting but would require more work to define a schema and get the existing tools to support this schema.

Both the RSS-Bugs approach and the bCard idea aim to solve the same problem of allowing distributed teams to track monitor and view bugs so that collaboration becomes the norm rather then the exception.

Weekend thoughts on open source development

Jun 07
8

There seem to be two camps of open source development. In one camp are the Linux folks who are building an open source OS, drivers and related software. In the other camp are the open source web based technologies building Apache, PHP, MySQL and other related web tools.

The way people develop a desktop Linux application has nothing to do with the way that people construct web applications. This is a shame because it’s really a lost opportunity. The one place where Linux is really strong is on the server. In fact there are lots of developers who can build fairly complex web-based database applications but wouldn’t know where to start if they needed to build a simple ‘desktop’ application.

Windows and OSX stop at gadgets and widgets for small web-connected ancillary applications. It doesn’t have to stop there. Why isn’t there unity in the methodologies of open source development?

Web 3.0 to do list

Jun 07
5

There are a number of things that you still can’t do on the web. This is the to-do-list to continue the convergence of desktop and web applications.

  • Handle file types for opening – a file double clicked from the desktop should be able to open up a web application
  • Handle saving back to the desktop – a file opened from the desktop should be able to save back to the desktop
  • Better off line support – this is in the works but most apps still don’t do this
  • Embedding objects – I can’t take a Yahoo table/chart and embed that in a gmail email.
  • Desktop Installation & Integration – Web applications should be able to ‘register’ or ‘install’ to get a link in the start menu
  • Hardware integration – web applications should be able to get hardware status and data such as GPS location, webcam, etc.
  • Drag-in & Drag-out – Users shoudl be able to drag objects into web-pages to import or open a file and drag out to export a file or data
  • Raw processor horsepower – As web-applications get richer and more complex they will need to harness the power of the desktop for photo editing, video editing and other advanced applications
  • Optional chrome – The back-button may not make sense for every application. A calculator or post-it application should be able to be run from the desktop without the chrome. (not just widgets but real applications)
  • Unified account system.  (more than just OpenID but a complete & secure system that allows people to have a single & secure login across many locations)