Comments and conversations

Conversations in Things

One of Querki's truly unusual features is that it is going to be social to its core. We are used to that in many domains nowadays, but I don't think I've come across a "social database" before.

This will start with the Use Case Blog. The reason why blogging is going to be the first use case is largely because it will force us to get at least the first draft of comment threads working. Comments are obvious for blogging, but won't be restricted to that: instead, comments will be available for any Thing in any Querki Space. It will be optional, but probably opt-out -- by default, Spaces will have comments enabled.

Look and Feel of Conversations

Comments should be done in what I think of as "heavyweight threading". This is the way comment threads worked in CommYou -- most people would think of it as the way that comments worked in Wave. (Which was nearly identical to CommYou in many ways.) This model has distinct, indented threads, but not quite the every-response-commented approach of LiveJournal (which is "lightweight threading"). The notion of heavyweight threading is that threads are encouraged to be in a single line, not indented. Basically, the first response to any comment happens at the same level as that comment. Only subsequent responses to the same node are indented. While this is a bit logically inconsistent, it is somewhat easier to read, and works well for ongoing conversations -- back-and-forths are linear instead of deeply indented.

Ideally, we will have Wave-style blips inside of text nodes. The comment system should be designed so that a comment thread can be attached to the Thing as a whole (and displayed at the bottom); attached to a specific Property on the Thing; or embedded inside of text.

I'm not yet sure which way we will display embedded comment threads. Three possibilities present themselves offhand:

• Displayed inside the text, right inline, the way Wave did it.
• Displayed to the side, at the right height, the way Word does it.
• Popup overlays, with a little button to click on to see the comments.

We can potentially try any or all of these -- they probably have the same internal data representation.

Comments are optionally displayed. I suspect it will be a user setting, whether to always show comments or only when you choose to do so.

Comments will likely be shown on the same page as the Thing, not on a separate tab. We want to encourage comments as a collaborative mechanism, and that means not sticking them off to the side too much.

There will be separate ACLs for comments: you can choose who can comment at a Space or at a Thing level. It will be fairly common to make a Thing public and not make comments public, so don't assume that comments are available for anything you can read! (But it is likely that anyone who can write a Thing can comment on it.) Comments can also be entirely disabled, again at either a Space or Thing level.

Implementation

Comments will probably be kept in a separate table (per Space, as usual). For each Thing, there will be one big Blob, I believe, although we might build something more SQLish later.

A Discussion blob will contain a tree structure of Threads. Each Thread is distinct, and rooted at a particular location in the Thing -- it will specify either the Thing as a whole, or a Property as its root. If a Thread is attached to a Text property, it can optionally be tagged as being inline. If it is inline, we expect to find a notation in the Text itself, saying where the Thread goes. This notation doesn't matter much, but I suspect it will be something like '''34''' to note the location of Thread 34. (This notation should ideally be hidden in the Text editor.)

Discussions should be history-recorded, just like everything else, with full undo capability.