-
Notifications
You must be signed in to change notification settings - Fork 11
Comments and conversations
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.
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.
Much of this can happen gradually. It is okay if we start with plain flat-threaded comments at the end of the Thing, so long as we build the internals correctly and plan for improvements.
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. OTOH, it may make more sense to just make them a Property on the Thing, so that they get swept in with everything else. (LATER: no, that would be bad. I need to keep out of memory anything that can be out of memory. So let's have conversations loaded dynamically as needed, and restrict the QL functionality a little for now to make that plausible. We will load the discussion on a Thing on-request, and cache it in memory for a modest time -- perhaps 5-10 minutes.)
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.
Comments should have full Markdown capabilities, same as everything else. Raw HTML will probably not be supported. They will eventually use the same WYSIWYG editor as everything else.
A critical thing for us to think about is the mobile implementation of Querki -- a hard rule nowadays is that a consumer product lives or dies on its mobile interface. This presents some interesting challenges.
The really interesting part is going to be that, AFAIK, nobody has to date implemented a decent threaded conversation system for smartphones. The problem, of course, is that a smartphone doesn't give you a lot of screen real estate for showing thread context. So we're going to need to be creative here, and try out some new ideas.
Let's start with a little requirements analysis. Here is what I believe we need in heavyweight-threaded conversation.
- Table stakes: we're doing heavyweight-threading. This means that a back-and-forth conversation is displayed flat, but you can add additional responses to any given comment, and those can turn into subthreads.
- It must be extremely simple to follow a single thread. The most common action is to simply read from top to bottom.
- It must be easy to understand which comment a reply adheres to. That is, I need to be able to see my context.
- It should be easy to see new comments within the conversation, wherever they are, while still being able to see context.
So the right approach seems to be an extension of where CommYou was in its later days. (Which was around where Wave got to, as well.)
The main focus at any given time is a single flat thread. If the conversation consists of one thread, then it looks just like a typical flat-threaded conversation system: a simple stream of comments.
If a thread is in reply to a comment, the header comment shows up, stubbed, at the top. This is probably a single line (maybe two, maybe configurable), showing an avatar icon, a user name and the beginning of what that comment says. The thread shows, slightly indented, below that.
In general, I believe we should use indentation as a subtle visual cue, but it should only be a few pixels. It is there to indicate that this is a reply, but cannot be used to show what level of reply it is -- that is, we can't count on the amount of indentation to help the user understand that comment A is replying to comment B unless they are right next to each other. LJ demonstrates vividly that that doesn't work.
If there are other replies before the current one, they meld into a single "..." at the top of the thread, right below the header comment. This should help illustrate that there is something there. You can pull down to scroll stuff out of that, or click on it to show the top of the reply threads.
You can get back to the context header by clicking on it or (I suspect better) by pulling right. Then, pulling left again brings you back to the reply that you were looking at. While probably not 100% intuitive, this right-left approach gives us a fast way to be able to relate the reply to what it's talking about.
So when you simply scroll down through a threaded conversation, you'll experience threads as a message getting "caught" at the top, compressing into a one-liner, and then you are now scrolling through its replies. If a sub-thread comes up, when its header gets to the top, it shoves the current header off the top and replaces it. When you get to the end of the sub-thread, the previous header returns.
This is a fairly radical UI, and will need a bunch of user testing and likely a fair amount of tweaking. But I think it's a good start, and may help kickstart some discussion and evolution in the industry, about how to manage sophisticated conversations on a small screen...