Threaded discussions with NavFrames

In this learning project, we build a flexible operational model of a w:threaded discussion system with wikitext and NavFrames (see also: w:WP:NAVFRAME). I invite everybody to join.

Summary

As I know it, in mediawiki, every edit can alter only one page. The first conceptual question the programmer asks himself is: how can we make the parent node/thread/comment aware of a new sub-node/sub-thread/reply?

We achieve this by putting various replies to a previous comment on separate sections on a page, each transcludes all its replies, each transcluding all its replies.... Each has a customised reply button, an "external link" to an editing page for the subnode. The editing page is in turn "w:preloaded" with the same wikitext, and so the cycle continues.

So the key is in the preload page. The relevant wikitexts consist of two lines (the link and the transclusion):

*reply[{{fullurl:{{<includeonly>subst:</includeonly>NAMESPACE}}:{{<includeonly>subst:</includeonly>BASEPAGENAME}}/{{<includeonly>subst:</includeonly>REVISIONTIMESTAMP}}|action=edit&preload=project:Threaded_discussions_with_NavFrames_with_subst/preload&section=new}}]
{{{{{subst|}}}{{<includeonly>subst:</includeonly>NAMESPACE}}:{{<includeonly>subst:</includeonly>BASEPAGENAME}}/{{<includeonly>subst:</includeonly>REVISIONTIMESTAMP}}|subst={{{subst|}}}}}

The "{{{subst|}}}" are for "optional substitution", to allow archiving and exporting, as explained in #Collapsing a thread.

Note that, as it turns out, e.g., the page Wikiversity:Threaded_discussions_with_NavFrames_with_subst/20070522105803 contains only the replies to what we think of as "comment/node number 20070522105803". "Node 20070522105803" itself is actually a section in its parent page. Thus we have provided a special:whatlinkshere link for each node to aid "naviagation towards the root thread".

[[Special:Whatlinkshere/{{<includeonly>subst:</includeonly>NAMESPACE}}:{{<includeonly>subst:</includeonly>PAGENAME}}|What links here]]

Grafting threads

Sometimes two threads/discussions started out indepentdently would converge. Our model is adept in handling such a situation.

We can graft two threads by simply adding a transclusion. In order to keep the thread "alive and in order", it is advisble not to simply cut and paste somebody else's comment/section/thread into another page(but it is all right to cut an paste your own comment/sectionthread). We have provided the preloads /graft and /grafteasy (which calls /grafteasy1). What they do is simply to add a comment which amounts to that "some other thread should be relevant to us here", and transcluding the "some other thread", and the structrure becomes as if that "some other thread" is (unknowingly) a reply to the local discussion. Schematicaly: (starting from left)

              -------*----*---
 /-----*----*/
*
 \--------*--------------------*
           \ "grafting"
            \
 /-----*----*------------*
*
 \--------*--

Collapsing a thread

Since a thread consists of many wikipages, it is not feasible to export all of them to another wiki. Here we use the optional substitution technique to collapse all the threads into one page. The relevant wikitext on the thread, which generally reads

{{ {{{subst|}}}namespace:basepagename/revisiontimestamp|subst={{{subst|}}} }}

is produced by

{{{{{subst|}}}{{<includeonly>subst:</includeonly>NAMESPACE}}:{{<includeonly>subst:</includeonly>BASEPAGENAME}}/{{<includeonly>subst:</includeonly>REVISIONTIMESTAMP}}|subst={{{subst|}}}}}

in the proload page.

Testing

Experiments has been carried out at betawikiversity:wikiversity:td,betawikiversity:wikiversity:tda,betawikiversity:wikiversity:tdb , betawikiversity:wikiversity:tdc , meta:meta:Threaded discussions with NavFrames, here WV:THREADNAV, wikiversity:Threaded discussions with NavFrames with subst with depth and w:zh-yue:user talk:hillgentleman/preload.

Reading a threaded discussion

By its nature, threaded discussion does not require archiving, and no thread is truely dead. One can read/monitor a threaded discussion by starting at any page/node. For example, in [[user:hillgentleman] may choose to transclude any one node amongst the subpages of his talk page.

We here have chosen to use w:NAVFRAME for displaying the threads. (I do not know any simpler trick that works - for example, transclusion and indentation do not work together. ) The relevant wikitexts are

<div class="NavFrame" style="text-align: left;">
<div class="NavHead" style="text-align: center;"> [[{{<includeonly>subst:</includeonly>NAMESPACE}}:{{<includeonly>subst:</includeonly>BASEPAGENAME}}/{{<includeonly>subst:</includeonly>REVISIONTIMESTAMP}}|{{<includeonly>subst:</includeonly>REVISIONTIMESTAMP}}]]</div>
<div  class="NavContent">

Here the m:magic word REVISIONTIMESTAMP, substituted, produces a time stamp which look like this: 20070522193137, which gives a unique index for each thread.

However, we may forgo the transclusion and just keep a link. Then each page displays only one node. And we would need a "what links here" link, once again, for navigation towards the root thread.

More discussions

See

• WV:THREADNAV
• Talk:liquidThreads

Further developments

• Make it more robust and easier to use
• JAVA script: it is inconvenient that one needs to open many NavFrames to get to a deep thread, every time. It would be convenient to have an "open all subthreads" (is it possible?) or at least "open all NavFrames on this page" button.
  • Is it possible to make functional the table of content links to hidden sections ? (asked JWSchmidt on the talk page)
• Add colours to differentiate the levels. Red-->Blue-->Green-->yellow may suffice.
• To make new threads more prominent
  • Alternatively, we may put all the new threads in such categories as category:threads on yyyymmdd, and have a page New and recent threads to monitor them.
• To separate the data (comment) and the structure (nested transclusions). That will probably require two clicks of the "save" button for every comment.
  • Without drastic change, we may go as far as putting the display elements into {{threadnav foot}}, which is called by {{threadnav footer}}, and {{threadnav head}}, which is called by {{threadnav header}}. Note also that the preload here is preloadwithtemplates. See the demonstration in [1]. In this manner, the display mode is easily switched by modifying the template - or one may add a parameter in the template for an automatic switch. Only the comment and the bare bone structure are kept in the main text. This provides us with more flexibility; and it becomes easy to make the threads machine-readable (by blanking out all the display elements).

• One stumbling block so far is: the only "communication" from a node to a subnode is in the pagename, during page creation. I don't think it is possible to add a paremeter on the preload. Therefore the only thing that a subtnode "knows" about its parent node is its own pagename, which comes from the revisiontimestamp of the parent node. For example, it doesn't actually know where exactly its parent node is. That is why we need the "what links here" link.
  • This problem may be solved, albeit inelegantly, with adding "&autosummary=..." to the query; however, this only works if javascript is turned on, and it does not work for ip-users, and hence it is not feasible (or, if you like, not comopatible with the meta:foundation issues.

• It is very plausible that, in a heated discussion, two comments would have the same timestamp. There are several ways to solve this problem. In order to give each a unique code/subpagename for identification, we may append the usernames to the revisiontimestamp. The simplest way - using three tilds ~~~ would require m:stringFunctions to remove the brackets. Or we may ask the author to add a his text signature or initials. In each case we need a separate preload, perhaps named as "/preloadwithauthorsignature".

• Extenion:Tree view ([2]) is very suitable for displaying threads. Can we use it? It should be straightforward to write a script to organise the thread-summaries into a tree

{{#tree|
*1.
**1.1
**1.11
**1.2
*2.
...
}}

• Can we use template:thread? 17:58, 1 April 2010 (UTC)