Showing source for Querki Comment Threads
ProWiki
|
RecentChanges
|
Preferences
Here is a vague design for what the UI for comment threads might look like, in a highly AJAX-y environment. The core concept is that there are potentially two panes: the main text pane, and a lower comment pane below. (Yes, this idea is lifted from Word.) They are contextually linked -- insofar as possible, the panes try to stay in synch with each other. To create a top-level comment, you highlight a bit of text in the main window; this activates the "comment" button. If you press that, the Edit Comment pane/window pops up (this might be either a popup window or the bottom pane). It lets you enter a new object, which descends directly from the Comment type -- in theory, this type should be as configurable as everything else. Once entered, the comment adheres to the main entry, and specifically to the highlighted text (which means that it's editing the text to show the borders?). In the usual rendering, it shows up as a slight highlight to the chosen text (maybe a cream-colored background, or somesuch). When reading the main entry, you can see from that highlight that there is a comment on this text; if you hover over it, you get a little Javascript popup showing the beginnings of the comment, and a "double-click to see comment". If you double-click, the comment pane opens, showing all of the comments to this page, scrolled to the relevant one. Comments are threaded -- at the bottom of each comment is a "reply to this comment" link. Clicking on that takes you into the same Edit Comment pane as for creating a top-level comment. The child comments adhere to the parent, at least initially. Removing comments is an interesting problem, mostly because of the threading. I think we need to have two buttons -- "remove comment" and "remove comment thread". If you just remove the comment, it re-weaves the child comments into the parent page. (Basically, you're slicing a node out of a tree.) If you remove the thread, the whole thing falls off of the parent, and becomes orphaned in the DB. It is possible that thread-removal is the most desireable use case, and it's clearly easiest, so it should probably come first. Note that comments might be a permission unto themselves. That is, even if you don't have permission to create and modify pages in a namespace, you might have permission to comment on them. That said, this might be a distinction without a difference -- it isn't clear how often it's going to be *useful* to have that as a separate permission, especially since comments are still a wikispam vector. So this is a low-priority feature at best. Back to [[Querki Requirements]].