User:Isarra/talk

Supose you've got a talkpage. People talk on it...

Note - while this is based in part on current work on Flow, it may or may not reflect the development of the project itself. This document is instead an attempt to clarify the general problems and possible solutions in a somewhat more organised fashion; for official word and documentation please see the Flow Portal.

Let's start at the beginning.

Talkpages suck. Now they're awesome in many ways, but because that's all they are - pages that are used for talking - they are harder to use than they really need to be. But because they are pages, and because people talk on them, they have certain features that do make them useful, and have developed certain workflows through which folks approach them.

At some point folks decided the solution to talkpage problems was to replace them: to implement some sort of message board - a thing somewhat like a forum, with posted comments and replies each acting as their own object on the board. Such message boards have seen a few implementations already: LiquidThreads (LQT), Message Wall, and even to a lesser extent comments on articles. All, in various ways, kind of sucked, but Message Wall proves it is at least doable and can potentially be an improvement (whereas even that potential is often debated with LQT).

The argument for replacing talkpages

Talkpages do work, and quite well, even, but they have their drawbacks. Primary is that they are just plain hard to use - not always, not even most of the time, but some of the time, but that some of the time can be rather annoying indeed.

(example story of PAIN because people love stories. also pain.)

Generally problems and/or difficulty are often associated with the following:

• Initial learning curve (most users figure it out eventually, but it is unintuitive and others have been outright driven off by how unfriendly the talkpage system seems)
• Complex discussions - it can be difficult to reply to the right person or sort through all the ::::s, especially if others have responded since the comment to which one wants to reply
• Edit conflicts - need to resolve the conflict, but perhaps the new comment(s) need addressing too, and then it is more likely to run into another edit conflict as a result...
• Multiple paragraphs/other unusual formatting in a reply (yes, you can do <p> or intermix colons and list items, but it gets messy - why should we have to deal with that?)
• Finding old discussions - searching for them, linking to them
• Archiving discussions - bots can resolve automation needs, but links still break, and searching archives can be difficult
• Watching discussions - no way to only watch a single thread on a high-activity page
• Checking for new replies - only ways with talkpages are to look at the entire thing and look for new bits (and potentially miss less apparent additions) or look at the diff of the page, which may not be of much use especially if other sections have been archived
• Inflexibility of the system - everything that is put down on the talkpage is essentially hardcoded. Changing the page is an option, but whatever people put down is down - if folks prefer not to thread a conversation, then it is down as not threaded regardless of whether or not others who come in later or want to read it would prefer it be threaded to them, and visa versa - if folks thread something and others would prefer to just read it in order of post, there is no easy way to do this. BUCKETS SELF FIX THIS

If properly implemented, a message board - an organised comment system - would be able to resolve all of these annoyances while largely maintaining the useful features and workflows that users currently enjoy with talkpages.

A message board-type thing

Let's just start from the beginning with the message board.

A message board consists of three things:

• A container - the page on which it appears, or potentially any space where a bunch of threads wind up if it can be arbitrarily inserted like fora using Extension:DPLforum. Basically the container holds the threads.
  • The container contains:
    • Threads
    • Filters
    • Searchability
    • A set of actions/tools - delete, lock, add a thread/topic/whatever, mark all read

• Threads - related groupings of comments/replies, also potentially referred to as 'discussions' if one wants to be optimistic about the nature of the project. On a talkpage a thread would be analogous to a section.
  • These might be attached to a particular page or topic, but a single thread could appear in multiple containers as relevant - for a thread about how a policy applies to an article, it could appear in both the article's talk container and the policy's (just don't ask how the thread would figure out that it is relevant to both of these).
  • Each thread would have a title for the specific discussion, say, "Proposal to revoke BWilkins' adminship" - after which would come the first poster's comment explaining why they don't want BWilkins to be an admin, and the rest of the ensuing drama would take place in subsequent reply comments indented according to which particular other person the each poster is inclined to yell at at the time.
  • A thread contains:
    • Comments
    • Title
    • A set of actions/tools - edit, delete, lock, etc
    • A possible summary
    • Collapsibility
    • General reply functionality
    • Tagging/categorising functionality
    • General information about the thread - Time, commenters involved, number of replies, containers it shows up in

• Comments - these make up the threads, either starting a thread, or replying to another comment. All comments in a thread are children of either other comments or the thread title. The first comment is a child of the title, as would be any outdented comments getting back to the original point or merged in comments from a duplicate thread, if such is supported. The rest reply and discuss like civilised people. Things. Objects.
  • Each comment contains:
    • Poster's username, avatar, user information, actions on user (block, directly contact, etc)
    • Message - the actual content/text of the comment
    • Time of post, other info
    • A set of actions/tools - edit, delete, move, protect, etc
    • Reply/quote functionality

Things to worry about

Now that, of course, is pretty basic. Doesn't account at all for searchability, what will be doable through the API, or how exactly the replying, tagging, etc would actually work.

Requirements

• It works - can make now threads, reply to comments, read indented converstions...
• It works in general - normally or without js (though not necessarily prettily), in stupid skins, from the API, etc
• All the usual things - multi-user interaction, threading, editing, locking/protecting, archiving, whatever
• A personal feed that gets all watched threads into some grand feed - probably just integrate this into the watchlist
• Supports wikimarkup and VE
• Allows watching pages or just specific threads
• Taggable threads - for searching/filtering
• Searchable (preferably directly - on the page/whatever so a user can search a specific page/area for a topic)
• Some way to distinguish between read/unread comments, and to mark comments as read/unread

There has been confusion about the distinction between a personal feed and a user feed. Consider the user feed essentially their talkpage - easily accessed from their personal feed (watchlist), but a separate feed that anyone can access. All pages will have an associated feed; the personal feed includes all relevant threads off any of these, either because the page is watched or the thread is.

Implementation

How shall discussions - threads, comments, tags - exist in the database?

Should comments each be their own pages within some new namespace, with parent containers and threads being simply information about those pages stored as metadata or such, or should comments be something else entirely, contained in new tables with their own implementation distinct from those of revisions and pages?

While probably easier to set up a basic working model with pages, it seems messy and ultimately unintuitive. It would confuse the search when searching all pages - a comment is not a page in the user's mind - and also create issues with how metadata like parent threads and containers and tags are handled, and subsequently also with the searchability of any of that.

Either way would probably work, but which is chosen will affect development time as well as what all can reasonably be done on the front-end.

How shall discussions be sent to the browser?

There are two ways to do this - have the browser dynamically assemble the page with javascript, or assemble the page prior to sending it.

There is absolutely no good reason to do the former. Dynamic assembly is only useful for two things - infinite scrolling and draining batteries. This is probably not somewhere where we would need infinite scrolling, but even if we do it should still at least build the initial chunk of page before sending it.

General javascript functionality, however, will be integrated into the UI.

Transition from talkpages

There will be a transition in any already existing wiki - talkpages will be archived, and thread containers (message boards, if you prefer) will replace them. To not do this - to only replace on some pages, or only use the thread containers on new ones, would be very confusing especially for new users and just result in a horrible sort of mess.

Of course there is the issue of how, but given most projects have their own ways of archiving things they'd probably be able to come up with the best things to do with their archives themselves. This, however, assumes all projects would have the means to implement something following their usual methods (which tend to be done manually especially on smaller projects), which is not a valid assumption.

Due to the arbitrary ways in which users start talkpage threads and reply to each other manually (for instance creating no new section for a new discussion and using strange section headers, outdents, indents, indents of random amounts, etc) there is no real way talkpage discussions could be automatically migrated (someone might want to do this because if it were doable then the old ones would benefit from the searchability of the new system, and also allow for more easily linking back to old discussions, or even resuming them, with the new system).

LQT, however, probably would be migrateable, though the difficulty may depend on the implementation of the new system. May also not.

Users who hate being constrained

Block button works even better at constraining people.

Layouts

Variants on some general gists. Based in part on the layout at the top of this page, as it should wind up something like that.

Comments

Comments may or may not have avatars, may or may not have user information, may or may not use space various ways. This will affect the layout.

Date format will be determined by the user's preferences. Presence of avatars may also be a preference (or wiki configuration setting). Borders are included mainly to show the use of space; actual styles may or may not include borders.

• 
  LQT (currently deployed)
• 
  Possible variant
• 
  Another possible variant
• 
  Variant with avatar
• 
  Format maintaining talkpage comment layout
• 
  Another variant with avatar

Threads

Threads are pretty straight-forward - have title, comments, info, various tools. Main question is which tools and where.

Three threads are shown per mockup - expanded, collapsed, and closed/archived.

• 
  Tags not shown on thread
• 
  Tags on thread
• 
  Tags on thread, info at bottom, compact tools
• 
  Category-like tag management, slightly different tools

Container

Container shouldn't have a whole lot besides threads, a search, and archive links. Might need a ToC, but then again that may not be necessary.

• 
  Layout like WP:ANI with box for archives
• 
  More collapsible layout
• 
  Collapsible variant with TOC
• 
  LQT layout
• 
  With TOC, tools broken next to relevant stuff

Perhaps treat the entire thing like a template with various parameters (with defaults per namespace a la talkheader):

• Intro (editable part where all the options wind up)
• What the sections should be referred to as (section, notice, topic, etc)
• Old archives (for dealing with converted pages - just stuff whatever sort of {{Archive }} box the wiki or user likes to use in here, perhaps)
• 'Archival' frequency
• Related navigation links (could just be stuffed into the intro, but a more elegant way of switching between noticeboards or forum sections or related policy talkpages etc would be kind of neat, especially where multiple pages share a talkpage in the current setup)
• Etc

And what would an archive of this even look like? It could be... anything. Any kind of navigation, any sort of handling... blimey.

Replying

Replying will probably be like with lqt or bugzilla, but smarter. There will need to be a non-js fallback (like the current LQT implementation) if we don't want users rioting, but we probably want the normal replying on the page itself (like how bugzilla does it, though slightly more complicated), just uncollapsing out of the space after the post to which the reply is directed. The parent.

Personal feed (watchlist)

This presents a whole lot of unique problems that don't show up anywhere else.

• How do we include the title of the page the threads belong to? (What if a thread belongs to containers for multiple watched pages?)
• Would this be the only one where read/unread messages comes into play?
• Will read messages fall off the feed entirely, collapse, what?
• Threads that aren't specifically watched on watched pages - special? Perhaps start out collapsed as a notification that hey, there's a discussion happening without actually splaying the entire discussion on the page?
• How will it interact with other watchlist stuff - page edits, notices, etc? Just a separate tab? What if when the discussion happened is relevant to when the edits happened?