LiquidThreads 3.0/Design

This document describes a redesign for the LiquidThreads discussion system. It discusses visual, interaction, and feature design. Software mechanics and design are outside of the scope of this document.

A full screen shot of a talk page

This document is a work in progress. Discussion on the talk page is encouraged. There are also open issues awaiting resolution.

Overview

LiquidThreads is a threaded-model discussion system intended as an alternative to standard MediaWiki talk pages. LiquidThreads is designed to be familiar and easy to use to most internet users and to provide a smooth on-ramp for participation and collaboration.

When developing this design, the following points were kept in mind:

• Standard "talk" pages are an extremely high barrier-to-entry for new users.
• Talk pages are not user-friendly in any way, shape, or form
• Talk pages are not always for discussion
• New users have difficulty attributing responses on talk pages to unique individuals; they often see communication on talk pages as coming from Wikipedia "as a whole"
• Wikipedians have developed many habitual behaviors (both good and bad) to overcome the deficiencies of talk pages
• New users often only want to bring attention to issues within articles; many people do not feel that they have the "right" to edit pages
• The Wikipedia community is often perceived as aggressive and overly bureaucratic

Not all of those bullet points are addressed in this design due to scope. Future projects may do just that, however.

Design requirements

The following requirements were kept in mind when developing this design. They are divided into "primary" and "secondary" requirements.

Primary

These requirements are the primary drivers behind the design direction.

• The barrier to entry must be low; the system must be friendly and behave according to expectations with little-to-no coaching
• The system should encourage positive interaction and promote community health
• The system should enforce the idea that discussion occurs between individuals and not Wikipedia
• The system should be flexible (e.g., it must allow for edge-case usage, like with the Administrators' noticeboard)
• The system should not break existing tools, gadgets, and bots, if at all possible
• Backwards compatibility with existing LiquidThreads deployments is strongly desired
• The system should be keyboard navigable

Secondary

These requirements are secondary, and could be removed if the project must be de-scoped.

• The system should provide a "flat view" mode.
• The system should allow for simplified editing
• The system should allow for in-editor login and account creation to minimize user frustration
• The system should encourage shallower thread depth and topic splitting

Keyboard controls

The system must be navigable through the use of the keyboard. The following key mappings should be implemented (case-insensitive, but using capitals for clarity and readability):

• N - next post
• P - previous post
• U - next unread post (in current thread)
• [SHIFT] + U - previous unread post (in current thread)
• [SPACE] - next post
• [SHIFT] + [SPACE] - previous post
• X - expand or collapse current post set
• T - next topic
• [SHIFT] + T - previous topic
• R - reply to current post
• M - toggle minimal view

Note that keyboard controls require the use of JavaScript.

Dynamic insertion

Notifications pointing to new posts within the stack.

The notification that the system is polling.

The error message when the polling system fails

The system will continually poll the server for updates to topics that are currently within the view pane. If the server indicates that a new post has been made within the topic, the system will retrieve the posts and insert them into the page dynamically without the need for refreshing.

The current "active" post will not change position. New replies are inserted regardless of position.

A notification will be given to the user that new replies have arrived. This notification will also indicate the direction (up or down) that the posts have appeared in.

If, for some reason, the polling fails (e.g., the server has become unavailable, or the user's network connection has been severed), a modal, dismissible alert will appear indicating that the user must refresh the page to re-enable automatic updates.

For overall performance reasons, the polling system will slow down and eventually stop over time if the user is inactive. When the polling stops, the alert will be shown.

Use of color

Individual elements (posts and summaries) have a colored background. This is important for several reasons:

• Colors (e.g., not grey or neutral tones) encourage users to invest energy and time into an application. Saturation indicates that a content block is something that should be paid attention to and may be of interest.
• Color helps to distinguish individual posts. This has the following effects:
  • It breaks content blocks up into more manageable sections, preventing the "wall of text" effect
  • It serves to enforce the idea that individuals are collaborating and not "Wikipedia as a whole"

However, overuse of fully saturated colors will compete for the user's attention and can cause stress. Therefore, color is desaturated to avoid this.

Bright, desaturated color enhances a friendly atmosphere while desaturated dark color encourages a serious atmosphere (like that found in a business application). Since one of the goals is to be friendly and open, brighter colors are chosen.

Warm colors (red, orange, yellow) often invoke feelings of alert and energy while cool colors (blues, greens, and purples) are considered more peaceful.

Thus, the following colors are applied:

• Summaries are colored purple
• Posts are colored blue
• New Posts are colored green (and have a "new" icon)
• In the future, De-emphasized Posts will be colored grey (so that they fall into the background)

The currently "active" post - the post that the system considers being "read" will have a more saturated color blue.

When an unread post becomes "active", its color changes to the saturated blue, and then to the lighter blue when the next post is reached.

Page sections

Each page contains the following sections:

• Head - this is a wikitext section.

  It is useful for placing global information, such as project templates and links to non-threaded discussion archives.

• Table of Contents - this is a dynamic control that enables easy browsing of topics. In JavaScript-enabled mode, its initial size is variable based on the user's browser window. In JavaScript-disabled mode, it is a fixed sized.
• Viewing Pane - this section displays topics and all of their posts. It is an enclosed section and does not pass beyond the lower boundary of the browser.

Infinite scrolling techniques

There are two places on a page's interface that employ a technique called "infinite scrolling". In this technique, data is loaded automatically from the server and appended (or prepended) to the visible content in a buffer.

• The Table of Contents
• The View Pane

The two sections are tied together. Scrolling through one will cause the other to scroll as well. Whatever is the top-most topic in the Table of Contents will be the top-most visible topic in the View Pane (and vice versa).

Note that the scrolling speed will vary between the two panes. Topics tend to be larger, so the Table of Contents will not auto-scroll until the next-most topic reaches the top of the View Pane.

Rapidly scrolling the Table of Contents will require the system to wait until scrolling has finished before buffering content.

Non-JavaScript mode

If JavaScript is unavailable, the Table of Contents will remain static and pagination controls will become visible. Paging through the Table of Contents will cause the entire page to reload.

The contents of the View Pane will be loaded into either a scroll-overflowed div or an internal frame. The contents (e.g., the available topics) will be identical to the topics visible in the Table of Contents.

Table of contents

The Table of Contents is the user's view into the topics visible on a page. It utilizes a technique of "infinite scrolling", allowing the user to navigate through all topics within a page.

The table of contents is globally positioned. If the user scrolls down the page to where the TOC would no longer be visible, the lower Control Bar will always be present at the top of the screen, along with a control to cause the TOC to re-appear at full value.

Note that the Table of Contents has different elements in "History Mode", as explained at the end of this section.

Control bar

The table of contents manage bar.

The management bar when JavaScript is disabled

The control bar appears in two locations: at the top of the table of contents and again at the bottom of the table of contents.

• New Topic Button - This button activates the "New Topic" editor. The page is auto-scrolled to the editor position, which will be at the "top" of the viewing pane stack. This button is absent in "Subscriptions" mode.
• Topic Count - This is verbiage indicating the number of topics on the discussion page
• Refresh Control - This control will refresh the contents of the table of contents (Note: This may not be necessary)

  Note: - this may not be required and may be eliminated

• Mark All Read Control - this control passes through all unread posts and marks them as having been "read"
• Search Topics Control - This control allows the user to search all topics on the discussion page (and only the topics on the discussion page). See below for search mechanics.

Line items

The hover behavior over a table of contents new items notice

• Topic Title - The title of the topic. Clicking on the topic title will advance the viewing pane to the top of that topic and auto-scroll the user to that position.
• New Reply Count - This is a notification area that only appears when there are new replies to a topic.
• Reply Count - This indicates the total number of replies.
• Last Reply - This indicates the date stamp of the last reply. Technically, this is a last-modified date.
• Page Name - This column indicates the name of the page that the topic is home to. It only appears in "Subscriptions" mode.

The headers of the table allow for sorting in both A-Z and Z-A method. The default sort order will be "Last Reply", descending.

Striping mechanics

Line items will have alternating color bands (zebra striping) to better facilitate distinction.

The table cells within the sorted column will have a slightly darker shading than other cells, so as to better distinguish the sorted column.

New items hover mechanics

If a line item contains new posts, items, or changes since the user last viewed it, a marker will appear indicating how many changes have occurred.

Hovering the mouse over the marker will display a tooltip that summarizes the changes.

Search mechanics

The table of contents, when filtered by search

The search box on the table of contents will act more like a "filter" than a standard "search results" system.

When a search is executed, the contents of the table of contents (and the viewing pane as well) will be replaced with the topic items that match the criteria.

The control bars are modified as follows:

• The topic count verbiage changes, indicating that a filter has occurred
• The default text of the search box will show the text being filtered to
• The search box magnifying glass is replaced with a "clear" icon. When clicked, the text of the search box is removed and all filters are cleared.

Viewing pane

The Viewing Pane is the lowermost section of the page. It contains the "meat" content of all topics and posts. It utilizes "infinite scrolling" technique.

It is important to understand that the viewing pane contains a "stack" of topics. Topics may exist before and after what is viewable; however, there is a definitive "top" and "bottom" to the stack.

The order of topics within the viewing pane is exactly the same as the order of the topics within the table of contents. Re-sorting the Table of Contents will re-sort the topics within the viewing pane.

The Viewing Pane is self-contained. There are a series of controls available to the user which will alter the behavior and display of the topics and posts within the Viewing Pane.

Viewing pane controls

The control elements for the view pane.

The Viewing Pane has several control segments. Modifying any of the settings will be saved in the user's LiquidThreads settings.

Mark all read button

This button marks all unread posts as read, across the board.

Expand control

This control set alters the collapse/expand state of posts and topics.

• In "All Posts" mode, posts are expanded by default. No posts are collapsed.
• In "Unread Posts" mode, posts are collapsed by default. Topics with unread posts will be expanded if and only if they have child posts that remain unread. The parent post, if any, will be expanded as well in order to provide context.

View control

This control set alters the display stats of posts and topics.

• In "Thread Mode", posts are threaded.
• In "Flat Mode", posts are displayed flat, in chronological order.
• The "Avatars" item will enable or disable the display of user avatars.

Topics and summaries

Topic summaries are standard wikitext elements. They are the master element for any topic. All topics will have them but they may or may not be visible.

All topics are attached to a "master" page (channel).

Summary focus vs. post focus

A summary, filled.

A summary, prompting for completion.

A summary, when no summary exists or is being prompted for

For simplicity's sake, summaries and topics should be considered to be one and the same. The summary is attached to the topic.

All topics shall have summaries. The summary will be the "master" element within a topic; collapsing the summary will collapse the entire topic.

When a new topic is created, a blank summary shall be created at the same time. The first post of the topic, the one the user creates, shall be slaved to the summary.

If a post is split from a topic, a new summary will be created, and the split post shall be slaved to that summary. Thus, all topics will have a summary.

However, in some instances, a summary may not be necessary. For example, a topic with only three replies may not require a summary. For this reason, blank summaries will only begin to appear (and prompt for editing) after a certain threshold of replies has been crossed or it is explicitly created by a user.

Summary elements

Headline

The summary headline area consists of the following elements:

• Collapse Control - This control changes the topic's state between open and closed. When closed, all child posts are removed from visibility.
• Page Title - This only appears on topics within the user's subscriptions page (see below)
• Topic Title - The title of the topic
• Watch Control - Allows the user to watch or unwatch a topic. This has more value when the topic is within the user's subscription list.
• Edit Subject - Allows the user to alter the topic's title. This will open a dialog.
• Link - This allows the user to easily obtain direct links to the item in question.
• History - This link will take the user to the topic's history page
• Move - This link will open a dialog, allowing the user to move the topic to a different master page.

Body

The summary body is a standard wikitext element. A summary body can be created or edited at any time but is not necessary.

A threshold for posts (say, five) will be required before the system begins to prompt for a summary. Until then, the summary body will be hidden by default.

Tail

The tail section of a summary will have two elements:

• Add Comment - Creates a new, top-level posted reply to the topic
• Edit Summary - Allows the user to edit the summary.

Posts

A single post

A collapsed post

A shared post example

A highlighted post and an unread post

The header of an anonymous post

The header of a post with avatars disabled

A post is a discrete response to a topic or post. They are typically threaded and have parents (and possible children).

The visible change depending on if the post is collapsed or not.

Shared Posts vs. Private Posts

By default, posts made by a user are "private." In that sense, the only person who is allowed to edit or delete them are the original poster or an administrator.

However, upon post creation, the user may elect to make the post "shared". Shared posts may be edited by anyone. They are marked as being shared and display a "group" avatar. Such posts are useful for voting, or polls, or other collaborative postings that are not necessarily good for summaries.

Deleted Post Behavior

When a post is deleted (for any reason), it is actually "hidden". In order to preserve thread structure, a "blank" post will be inserted, simply indicating that the post has been deleted (or has been hidden).

It is important to understand the distinction between a post that has been "deleted" and a post that has been "purged". A purged post will never be visible - even by paging through a topic's history - while deleted posts will re-appear in the timeline.

Collapse control and behavior

This is a control, located in the upper left of the post area, the controls whether the post (and its children) are visible.

Collapsing a post will "collapse" the triggered post and "hide" any child posts (they will retain thier individual collapse/uncollapsed state).

After a certain depth (configurable in software), posts (and children) are auto-collapsed.

Uncollapsing a collapsed post will open the triggered post to full viewing mode.

The collapse control will emphasis itself when it is hovered over.

An uncollapsed post consists of multiple, discrete sections and controls.

• Headline
• Post Body
• Tail

A collapsed post does not have a Tail and its Post Body is replaced with additional information:

• The number of replies to the collapsed post. Hovering over this will display a tooltip that shows the hidden post structure.

Headline

The headline is the area at the top of a single post. It contains a User Information section and a set of Post Maintenance controls.

User information

This section contains information about the user who made the post:

• User Name - This is drawn from the user's saved "signature", though any date element is stripped and not included. If, for some reason, "talk" and "contribs" links are not present in the signature, they will be added.
• Post Date - This is the timestamp of the post
• Avatar - This is a 32x32 pixel thumbnail of the user's avatar. If no avatar is provided or set, a generic avatar will be used instead.

  Thought - ideally, we could generate automatic "gravitar" style images for each user, so as to better differentiate between users.

• Unread Notice - for unread posts, an indicator will appear showing that this is an unread post.

For anonymous users, the User Name field will be the IP address of the user (per normal) with the additional text "Anonymous User" immediately following.

If the user is blocked, a notice ("Blocked User") will appear in the headline as well.

Post maintenance

The Post Maintenance section contains the following controls:

• Edit - Allows the user to edit the text within the post. The editor will open within the post body. Posts that have been edited will be indicated within the Post Body (see below).
• Link - Opens a modal dialog box with a set of "link to" links.
  • Two links will be provided (local and remote)
  • Next to each is a "copy" control which will automatically copy the text of the given link into the user's cut/paste buffer
  • A cancel control will kill the modal dialog
• Move - The functionality of this action has changed. It no longer allows for moving the discussion object within the page; instead, it is used to move discussions to different pages
• Split - Allows the user to take the individual post (and all of its child replies) and splits them into a new topic. A modal dialog will appear, requesting that the user provide a title for the new topic.

The "history" link has been removed. Since history is only important when a post has been edited and the history link is provided within the edit notice, this link is irrelevant.

Post body

This area contains the text of the user's response or posting. It is a standard wikitext element.

Edited post notification

The hover behavior of a post edit history

If the post has been edited since its original creation (by any user), a notice will appear at the bottom of the post body section indicating so with a link to the history of the post.

If only one person has edited the post, the text will be simple and indicate the name of the user doing the editing within the text.

If more than one person has edited the post, there will be a hover-over listing of who has edited it in addition to the link to the post history.

Tail

This section of a post contains various "content addressing" controls.

• A Reply button. Clicking this button will open the reply editor, directly below the post being replied to (this may not be the location that the saved post is placed, however - see below).

Editor

The same editor style is used for managing summaries, new posts, and replies. However, new topics are opened in a modal form and have an additional field for topic title.

Editor behavior

The reply editor

The reply editor is a stripped down, minimal version of the standard MediaWiki editor. It does not have a signature button.

Anonymous post detection

When a reply is submitted, the system (in JavaScript) initially checks to see if the user is logged in or is posting anonymously.

If the user is posting anonymously, a modal pop-up dialog will appear, asking if the user intends to do so anonymously or not. The user is given three options:

• Yes, post anonymously.
• No, I need to log in
• No, and I want to create an account

The login prompt within the editor

The login screen included in the editor's login prompt

In order to avoid user frustration and loss of data, Login and/or Create Account actions should be handled in-place, through modal JavaScript dialogs.

Signature stripping

Upon submission, the software will strip any text that it determines to be a signature (e.g., multiple tilde characters). Posts are auto-signed, so this is not needed.

Post submission behavior

Upon a successful reply submission, the editor box's contents are cleared replaced with the success (or failure) message. The box should shrink in size to accommodate this.

The message contents will consist of three elements:

The message if the editor succeeds

• A visual indicator of success or failure (checkbox or error icon)
• Headline text ("Reply added successfully") or ("There was an error")
• "Jump to" text, allowing the user to navigate directly to their post (this is useful if the post will be buried off-screen).

The location of the user's reply will vary according to the following formula:

• If this is a new posting, it will be appear in place (at the top of the stack, chronologically)
• If this is the first reply to the originating post, then it will appear directly beneath the message box (as a normal post)
• If this is the 2nd (or more) reply to the originating post, then it will appear at the bottom of the stack (chronologically), at its proper depth.

Subscriptions mode

A full screen shot of the subscriptions page

All users will have a "subscriptions" page. This will replace the current "new messages" system. The purpose of the subscriptions page is to grant users a high-level view of all discussion pages and topics that they are watching, following, or subscribed to.

Any topic a user has replied to will appear in their subscriptions list (unless they specifically choose to unwatch it). If a user watches a discussion page, all topics on that page will appear within it.

A user's subscriptions page behaves slightly differently than a normal discussion page, as described below.

Table of contents

The following changes appear to the Table of Contents on the subscriptions page:

• The "New Topic" button is removed.
• The verbiage regarding the number of topics changes to reflect the new context
• An additional, sortable column, "Page", indicates which page the topic is located on.

Viewing pane

By default, the viewing pane will be placed into a mode where previously read posts are collapsed by default. Only unread posts and their preceding posts will be expanded (to give context). The user can, of course, switch their expanded/collapsed system on individual posts or topics.

History mode

A full screen shot of a topic history page

Topics and LiquidThreads pages have a history mode. In history mode, the display of the Table of Contents and the posts within the View Pane are contextually altered.

In topic history mode, the line item "stack" consists of the same topic multiple times. Scrolling through the View Pane will be the same as if the user is scrolling through history. The next item in the stack is the same topic, only as it existed at the time of the revision.

In page history mode, the line item "stack" consists of changes to the whole page. The View Pane displays multiple revisions of the page.

Note: this behavior is likely to be very tedious but should be included for consistency's sake with other viewing modes. An alternative could be to only load a specific revision into the Viewing Page and not allow infinite scrolling.

Table of contents

When viewing a page that is Thread History (or the Page History of a LiquidThreads discussion), the Table of Contents behaves slightly differently.

Firstly, the Control Bar is replaced with a notice indicating that the user is viewing a historical version of the topic or page. This will include the total number of revisions.

Secondly, the visible columns have changed:

• Time- This indicates the timestamp of the revision. This is the default sort column.
• User - This is the username of the user (or IP address) who made the revision
• Action - This indicates the type of revision (e.g., "New Post"). Each action will include a hoverable "summary" link.
• Topic - This indicates the topic that the edit happened in. This is only visible in page history mode.

Hovering over a summary link will display the edit summary (if any) in a tooltip.

View pane and posts

Since the concept of "read" and "unread" is irrelevant in this mode, controls to manage that are missing. Likewise, posts have no controls (save for "history", which opens a standard wikitext history page).

The location of the edit (post or summary, typically), will be highlighted.

To-do

This is a list of design elements that have yet to be included in this document.

• Avatar mechanics
• Topic title edit dialog
• Administrator mechanics
• New messages notice
• Thread/Post protection mechanics
• Post deletion mechanics and display

Screenshot gallery

• 
  A full screen shot of a talk page.
• 
  A full screen shot of the subscriptions page
• 
  A full screen shot of a topic history page
• 
  A full screen shot of a talk page in "flat" mode
• 
  A full screen shot of a talk page with avatars disabled
• 
  A full screen shot of a talk page with JavaScript disabled
• 
  The reply editor
• 
  The header on the editor when the user is anonymous
• 
  The login prompt within the editor
• 
  The login screen included in the editor's login prompt
• 
  The error message if the editor fails to save
• 
  The message if the editor succeeds
• 
  The "link" dialog, after being clicked on
• 
  The modal "move topic" dialog
• 
  The modal "new topic" dialog
• 
  A single post
• 
  A collapsed post
• 
  A shared post example
• 
  A highlighted post and an unread post
• 
  The hover behavior of a post edit history
• 
  The header of an anonymous post
• 
  The header of a post with avatars disabled
• 
  The table of contents manage bar.
• 
  The management bar when JavaScript is disabled
• 
  A summary, filled.
• 
  A summary, prompting for completion.
• 
  A summary, when no summary exists or is being prompted for
• 
  The table of contents, when filtered by search
• 
  The hover behavior over a table of contents new items notice
• 
  The control elements for the view pane.
• 
  Notifications pointing to new posts within the stack.
• 
  The notification that the system is polling.
• 
  The error message when the polling system fails