FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:

RSS

Qatar, National Day, San Marino, National Foundation Day

TurnBasedVsInterruptedThreadMode

(this page will soon be moved/renamed to our local ReplyToTheWholePost page.)

A ThreadMode argument frequently starts like so:

  Blah.
  Therefore, Blah.
  So, Blah.

Then someone wants to reply. They have two choices at this point:

An example of an InterruptedThreadMode response follows:

  Blah.
     But, I think Bleh.
  Therefore, Blah.
     But then, by Bleh, it would be Blook.
  So, Blah.
     I agree with this part.

I’m calling it “InterruptedThreadMode,” because the thread is interrupted.

The other option was a new response, which we’ll call “TurnBasedThreadMode,” because we take a new turn to reply:

  I disagree with Blah, I think Bleh.
  By Bleh, Blook would follow.
  I agree with your general conclusion, though.

InterruptedThreadMode

Recursive include of InterruptedThreadMode!

Responding by interruption is easy: You just read through the inspiring message, and insert comments wherever inspiration strikes. The reader of your responses can see exactly what you are responding to.

However, InterruptedThreadMode can become very troublesome. You can end up playing whack-a-mole with arguments. After a couple of rounds of response, the threads of discussion can wildly diverge. Prioritization of threads generally does not happen, beyond “let’s discuss this,” or “let’s not.” (See DivergingArguments for more on these problems.)

Readers (as opposed to participants) of InterruptedThreadMode suffer the most. Readers have great difficulty following arguments, because arguments are fragmented over the page, and because the sense of temporal flow is hard to gather.

Consider 5 exchanges:

  A - 1st exchange   B - 2nd exchange   C - 3rd  D - 4th  E - 5th
  AAAAA.
    BBBBB?
       CCCCC.
         DD.
            E.
    BBBBB.
       CC.
         D. 
    BBBBBBBBB.
       CC.
  AAAAAAAAAA.
  AAAAAAA.
    BBBB.
       CCCCCCCCCCCC.
          DDD.
              EE.
          DD.
              EE.
          DDDDD.
              E?
       CCCCCCC.
          DDDDDD.
              EE.
          DDDDD.
              EE.
    BBBBBBBB.
  AAAAAA.
  AAAA.

See how the 1st message- message “A”- is divided all over the page? The responses are similarly divided.

And notice how it’s easy to lose track of the causality of the conversation? As you read from the top of the page to the bottom, time jumps forwards and backwards. It’s easy to get confused.

It’s also common to encounter “serial responses,” that say the same thing. Serial responses may take the form of “Again, the same argument,” or something like:

  So, Apples are Red.
    But not all apples are red. Some are green.
  Some balls are red.
    And there are also green balls, too.
  There are red lights on top of control towers.
    But not always- some are white.
  Thus, everything is red.
    So, how do you account for the things that were green, and the white lights?

We get serial responses because we structure our conversation by the order of the flow of the text, not by the key points of the text.

So let’s recall the advantages and problems of InterruptedThreadMode.

Advantages:

  • easy to write- respond where inspiration strikes while reading
  • responses close to inspiring comments

Disadvantages:

  • DivergingThreads?, DivergingArguments
    • (argument whack-a-mole)
    • (wild divergence)
    • (lack of thread prioritization)
  • readers suffer
    • arguments are scattered
    • chronology is confused

Note that in some mediums, InterruptedThreadMode isn’t so bad.

In E-mail or UseNet, for example, readers don’t suffer. The chronology isn’t scattered, because you can easily go back and watch the argument develop. Furthermore, there is “quoting” (putting a “>” in front of older message contents), making it easier to determine what is fresh, and what is not, provided there is some consistency in whether participants use TopPosting with their quotes, or not. These two things, an intact chronology (see also RememberAndAppreciate) and coherent quoting, together make it much easier to collect arguments, and keep the chronology straight.

  e-mail 1:
  AAAAA.
  AAA.
  AAAAAAA.
  e-mail 2:
  > AAAAA.
  BB.
  > AAA.
  BBBBBBB.
  > AAAAAAA.
  BB.
  e-mail 3:
  >> AAAAA.
  > BB.
  CC.
  >> AAA.
  > BBBBBBB.
  CCC.
  > BB.
  C.

If you’re reading e-mail 3, and want to see what “B” was looking at and responding to, you can go back to e-mails 2 and 1. You can recognize the entire argument, by starting with #1, then reading #2, than going on to #3.

However, DivergingThreads? remains a problem, even in E-mail, or on Usenet, if people are interacting by InterruptedThreadMode.

(To add: On wiki, it’s also hard to remember just where you need to respond. It can be easy to get lost in indentations. There is no quoting. So, the wiki page doesn’t exactly shout out “respond here!” You have to scan for the deepest indentation, to keep track of where you are going to respond.)

Interrupted thread mode is also known as Wiki:InterleavedParallelThreadMode.

Responding by interruption is easy: You just read through the inspiring message, and insert comments wherever inspiration strikes. The reader of your responses can see exactly what you are responding to.

However, InterruptedThreadMode can become very troublesome. You can end up playing whack-a-mole with arguments. After a couple of rounds of response, the threads of discussion can wildly diverge. Prioritization of threads generally does not happen, beyond “let’s discuss this,” or “let’s not.” (See DivergingArguments for more on these problems.)

Readers (as opposed to participants) of InterruptedThreadMode suffer the most. Readers have great difficulty following arguments, because arguments are fragmented over the page, and because the sense of temporal flow is hard to gather.

Consider 5 exchanges:

  A - 1st exchange   B - 2nd exchange   C - 3rd  D - 4th  E - 5th
  AAAAA.
    BBBBB?
       CCCCC.
         DD.
            E.
    BBBBB.
       CC.
         D. 
    BBBBBBBBB.
       CC.
  AAAAAAAAAA.
  AAAAAAA.
    BBBB.
       CCCCCCCCCCCC.
          DDD.
              EE.
          DD.
              EE.
          DDDDD.
              E?
       CCCCCCC.
          DDDDDD.
              EE.
          DDDDD.
              EE.
    BBBBBBBB.
  AAAAAA.
  AAAA.

See how the 1st message- message “A”- is divided all over the page? The responses are similarly divided.

And notice how it’s easy to lose track of the causality of the conversation? As you read from the top of the page to the bottom, time jumps forwards and backwards. It’s easy to get confused.

It’s also common to encounter “serial responses,” that say the same thing. Serial responses may take the form of “Again, the same argument,” or something like:

  So, Apples are Red.
    But not all apples are red. Some are green.
  Some balls are red.
    And there are also green balls, too.
  There are red lights on top of control towers.
    But not always- some are white.
  Thus, everything is red.
    So, how do you account for the things that were green, and the white lights?

We get serial responses because we structure our conversation by the order of the flow of the text, not by the key points of the text.

So let’s recall the advantages and problems of InterruptedThreadMode.

Advantages:

Disadvantages:

Note that in some mediums, InterruptedThreadMode isn’t so bad.

In E-mail or UseNet, for example, readers don’t suffer. The chronology isn’t scattered, because you can easily go back and watch the argument develop. Furthermore, there is “quoting” (putting a “>” in front of older message contents), making it easier to determine what is fresh, and what is not, provided there is some consistency in whether participants use TopPosting with their quotes, or not. These two things, an intact chronology (see also RememberAndAppreciate) and coherent quoting, together make it much easier to collect arguments, and keep the chronology straight.

  e-mail 1:
  AAAAA.
  AAA.
  AAAAAAA.
  e-mail 2:
  > AAAAA.
  BB.
  > AAA.
  BBBBBBB.
  > AAAAAAA.
  BB.
  e-mail 3:
  >> AAAAA.
  > BB.
  CC.
  >> AAA.
  > BBBBBBB.
  CCC.
  > BB.
  C.

If you’re reading e-mail 3, and want to see what “B” was looking at and responding to, you can go back to e-mails 2 and 1. You can recognize the entire argument, by starting with #1, then reading #2, than going on to #3.

However, DivergingThreads? remains a problem, even in E-mail, or on Usenet, if people are interacting by InterruptedThreadMode.

(To add: On wiki, it’s also hard to remember just where you need to respond. It can be easy to get lost in indentations. There is no quoting. So, the wiki page doesn’t exactly shout out “respond here!” You have to scan for the deepest indentation, to keep track of where you are going to respond.)

Interrupted thread mode is also known as Wiki:InterleavedParallelThreadMode.

TurnBasedThreadMode

Recursive include of TurnBasedThreadMode!

Now, let’s consider TurnBasedThreadMode.

TurnBasedThreadMode is where you take turns exchanging messages, but do not write within one another’s text.

For example:

  (message #1)
  So, Apples are Red.
  Some balls are red.
  There are red lights on top of control towers.
  Thus, everything is red.
  (message #2)
  Nah nah nah. Not all apples are red, some are green.
  Some balls are green. And I've seen white lights on
  top of control towers.
  If everything is red, how do you account for those things?
  (message #3)
  I demand proof. You must ''show'' me green apples,
  green balls, and white lights. I've heard people talk
  of these things, but none has proved it. They were all
  obviously ''paid'' to assert those things. It's all
  propaganda.

TurnBasedThreadMode has different advantages and disadvantages.

Advantages:

  • DivergingThreads? solved:
    • the message has a focus (prioritization, no “whack-a-mole”, no wild divergence)
  • easy for readers:
    • clear chronology
    • message has integrity- it’s structure is clear, the message is not fragmented

Disadvantages:

  • harder to write- have to hold structure of response in your mind while writing
  • if you reach a dead end in an argument, you need to back-track to plan a strategy of response- you can’t just look at the tree structure

Now, let’s consider TurnBasedThreadMode.

TurnBasedThreadMode is where you take turns exchanging messages, but do not write within one another’s text.

For example:

  (message #1)
  So, Apples are Red.
  Some balls are red.
  There are red lights on top of control towers.
  Thus, everything is red.
  (message #2)
  Nah nah nah. Not all apples are red, some are green.
  Some balls are green. And I've seen white lights on
  top of control towers.
  If everything is red, how do you account for those things?
  (message #3)
  I demand proof. You must ''show'' me green apples,
  green balls, and white lights. I've heard people talk
  of these things, but none has proved it. They were all
  obviously ''paid'' to assert those things. It's all
  propaganda.

TurnBasedThreadMode has different advantages and disadvantages.

Advantages:

Disadvantages:

Implications for Wiki ThreadMode Conversation

On Wiki, we tend to favor TurnBasedThreadMode.

Contributors

LionKimbro


CategoryOnlineDiscussion CategoryThisWiki

Discussion

One takes turns in a discussion. On the other hand, when writing a document one may indeed take turns temporally, but the goal is for the document not to reveal that turn-based nature in its structure. A page that has been written in DocumentMode is naturally edited in a fashion that might grow to look like InterruptedThreadMode. This is a problem with advocating DocumentMode as the default mode, but dismissing NeutralPointOfView as a SuperordinateGoal. What starts as a document gets turned, by dribs and drabs, chaotically, into a discussion studded with disjointed threads. If one can write from the outset with an aim of NPOV, and welcomes expansive correction and addition to that document without getting into a discussion about the points, DocumentMode can be preserved. Otherwise it might be better to start off with no intention at all to work in DocumentMode.

When considering other discussion-oriented pieces of SocialSoftware, one can make the distinction between linear conferencing systems and threaded conferencing systems. This conception of turn-based vs interrupt-based thread mode maps very well to that (though in the former case the term “thread” is used as a distinguishing mark, applied to one but not the other, whereas the latter case uses thread for both, and the distinction applies at the level of thread-vs-document.) PicoSpan (the software that the WELL started with) is linear/turn-based. Slashcode is threaded/interrupt-based. – anon

:There is an analogy, but I’m not sure if it maps well. One can have TurnBasedThreadMode which is “threaded”, or TurnBasedThreadMode which is “unthreaded” (one might call the latter “SingleThreadMode?, because there is typically one single thread per page, without subthreads). **There is an analogy here over exactly the same subject: WikiFolks(interrupt-based) & WikiDe:BaumListing (turn based). [de]man braucht beide. [en]one needs both. --sigi :By indenting this reply, I am using “threaded” TurnBasedThreadMode. By indenting, I indicate that this post replies to the previous comment. This provides more information than if I had not indented it, in which case I might just be replying to the DocumentMode text, or to the “entire discussion”.

:However, this post is NOT using InterruptedThreadMode. I didn’t interrupt the parent post, I started my own separate post after it. The difference is that TurnBasedThreadMode forces you to “target” your parent post at the level of granularity of entire posts; you cannot “reply to” part of a post. By contrast, InterruptedThreadMode allows one to reply to part of a post.

:– BayleShanks

For contrast, this post uses our DenotingAuthor system, which does not allow indentation. So, this encourages only “unthreaded” TurnBasedThreadMode. There is no way for me to “reply to” a single post; based on indentation, it looks like I’m just chiming into the discussion, maybe to reply to the parent post, maybe just to say something new.

re: DocumentMode

It seems when we collaborate over DocumentMode, we either:

  • Edit the document directly, if we think everyone would agree.
  • We add annotations, if we disagree. (“Interruptions.”)
  • We start threads at the bottom of the page, if we disagree. (“Turns.”)

Perhaps we should use a little symbol, meaning “see discussion section below,” to make annotations that point to threads at the bottom of the page.

But this page was intended just to talk about dedicated ThreadMode conversation, not DocumentMode conversation. (Perhaps we should write: “DisagreementsInDocumentMode?,” on how we like to handle those situations.)

We have some problems, because “Threads” means different things in different contexts. Perhaps we need to rectify our names.

On this wiki, the conventions we use for DenotingAuthor automatically favors turn-based thread-mode. Interesting. Never thought of it.

Oh wow; I never noticed either. Neat!

The conventions we use here automatically favor TurnBasedThreadMode. How comes? The speaker and listener friendly mode, letting someone finish his thought, before arguing, the polite-, the cultural-way. Why is it favoured by some little pictures? Is the illusion of beeing on a common camp fire, of seeing each other, of feeling warmth, feeling security really this strong?

No, I think it is due to the graphical layout.

We are really talking about two different things here (see my above posts). The interface discourages InterruptedThreadMode; if you interrupted someone, either you would not use new::, and your post would be easily missed, or you would use new::, and you would not be able to indent your interruption, and besides the huge picture would make even a small comment into a big interruption, so you’d feel more bad about interrupting.

However, the interface also discourages subthreads in TurnBasedThreadMode:

  1. If you use new::, your picture goes at the left-hand side of the screen; you cannot indent your post.
  2. You are discouraged from replying without using new::, because the background behind your text doesn’t change color, and that combined with the color change at the next new:: makes it look like your post is just part of the parent post.

See the two example posts I made above just now. In one case, I didn’t use the new:: primitive, and it is easy to miss my comment. In the other case, I used the new:: primitive, but I couldn’t indent (I couldn’t reply-to a specific post).

I would prefer if the software were modified so that “threaded” TurnBasedThreadMode were allowed. Specifically, allow indentation to work with new::.

Actually I think I would prefer it if people reorganized the page, using headings to mark the start of a new thread, or move to a new page entirely. I feel pages that are full of interruptions are difficult to read both for newcomers and for old hats like me. I think the current solution is nice (eye candy is important) if used in exactly the way intended – and thus good style is encouraged. I guess we’d have to check why we’d like to encourage InterruptedThreadMode. What do you like about it?

my background is usenet, lots and lots of it, and i love threading there (which is interrupt-based). i started out quickly disliking a lot of discussions on wikis because they were a royal pain to plow through, and thought at first it was the lack of good threading, but i’ve since clarified my ideas on it. it’s not that i actually dislike TurnBasedThreadMode – i like it just fine here, and i find myself getting annoyed on pages where people don’t start their contributions with the “new::” thingie. What i don’t like is the mixture of interrupted threading and turn-based threading without a clear indication of what’s been changed, without time-stamps, without author denotation. the wikis i’ve seen all do not handle tree-based threads well enough by far, and i am therefore coming around to gasp wanting to actually discourage them, unless something in the underlying infrastructure gets written to make changes more easily visible. the layout is really clean here, and i find it much easier to follow what’s going on, even though i have to scroll more as well, and might have to write slightly wordier comments to include more context.

i think each written page should have a “discussion” section underneath, and once discussion has died down somewhat, somebody ought to edit the main body and incorporate what has been learned, and the discussion can get moved off onto a historical page, or something, but the section header left for future discussion of the resultant document. i realize refactoring is much harder for a lot of people than originally writing a page, but it’s one of the very strongest features of wikis IMO, and i think it should get done more frequently.

Well, by my lights, I don’t want to encourage what I called InterruptedThreadMode. But I do want to encourage what I call ““threaded” TurnBasedThreadMode”. (I’d be fine using different terminology if you’d prefer, but I do need to disambiguate “threaded” TurnBasedThreadMode from InterruptedThreadMode; you are calling both of those InterruptedThreadMode).

The reason is that it makes it easier for the reader to skip over parts of a discussion that they don’t care about (i.e. replies to a given post which they are uninterested in). This saves the reader time.

I think disallowing indentation is moving backwards, not forwards. What I want eventually is WikiFeatures:BuiltinThreading . I want the features that a WikiEngine has to be a superset of the features that DiscussionBoard? software has.

Maybe we need an easy way to link to replies so that at the end of a comment, you can jump to answers, maybe skipping unrelated comments in between… Maybe another macro suchs as [reference]. When you then use [new::] elsewhere on the page, all the instances of [reference] will be replaced by links to the new comment.

Vis a vis Alex’s remarks above, on how we can actually design for the preferred mode of interaction… I’m introducing the concept of WikiAffordances

Bayle’s post above relys on : to indent which doesn’t seem to work on this wiki. That makes for a strange situation where the comments rely on being indented and they are not. Can this be fixed in code or this comment rewritten? Please. :-)


Due to the fast changing technological context, there are often surprising solutions, not yet taken into account:

A combination of annotations, graphics and wiki is in the air. – FridemarPache 2006-12-14 21:10 UTC

Of course. That is already accounted for in the page.

This page explains why, in email, or usenet, interrupted communication is (by and large) preferred.

And why, in wiki, we think it’s better to use turn-based communications.

Every medium will have it’s optimal methods for whatever your purposes or values are.

Wiki, by and large, use turn-based communications. For the reasons explicitly explained in this document.

Hi Lion, the surprising part is, that we can reconcile turn-based communication, with other forms, that are not disturbing the textflow of the base wiki, e.g. making additional annotations like this one. – FridemarPache 2006-12-14 21:40 UTC

I don’t understand what you’re saying.

Sure, you can do things in parallel. You can annotate whatever you want. It doesn’t mean that it’s a good idea.

This page is full of explanations and justifications. I’m not hearing any argument from your end, providing an explanation or a “why.”

My point is, that it becomes more and more an illusion, thinking that we solve the problem of optimal communication style, by making rules. If we rule out other thinking and communication styles by defining a fixed grammar, this may be shocking for other communities. – FridemarPache 2006-12-14 21:57 UTC

“More and more an illusion,” over time. Of course that is true.

But it is not yet sufficiently “illusion” that TurnBasedThreadMode is in most cases superior to InterruptedBasedThreadMode?.

If you think that it is, then you need to provide reason about why now, a different system will work better.

Do you have reasons, now, that, with the tools available, it would be better for everyone on CommunityWiki to decide to use DiiGo instead of commenting in pages?

We haven’t ruled out anything. On CommunityWikiGovernment, we’re talking about, at most, mere endorsement.

What we are, is SelectivelyOpenMinded. We will listen to reasons on this issue. What we don’t do, and what it seems like you’re doing, is just saying: “Technology! Everything is different! Capitulate to the new way! I don’t need to explain myself!”

It’s been 3 years. The Singularity is fast, I’ll grant that. It may even be “that fast,” which is why I have, myself, re-examined about the possibilities of us upgrading to include a WebAnnotation system.

I thought about it, and figured, “Well, there are some things we could do.” There are opportunities. Will we just up and shift to DiiGo? No.

GroupServer would be closer in line, I think. But I’d need convincing (with reasons, discussion, hearing) before suffering a CommunityWiki / DiiGo split.

Recognize that my principle dictum here is: Provide Reasons. Discuss. Answer our questions. You’re not doing that. You’re just saying: “Singularity.” Yes, singularity. Now: the reasons. Answer challenges and questions.

Note that I may elect not to respond, (now,) because I’m busy. There is an agenda here. CommunityWikiGovernment is highest priority.

Best: Prove the form somewhere.

Evaluate it’s strengths and weaknesses: surely it must have both.

Then, evangelize it from there. When people say, “No, for these reasons,” recognize that they may be good reasons, and that you simply need to evangelize to a different audience, with different needs.

There are places where WebAnnotation is extremely useful. I just don’t think commenting on CommunityWiki is the place.

Please respond on WebAnnotation, if it’s not about TurnBasedVsInterruptedThreadMode.

Lion, I feel fine with TurnBasedThreadMode, the mode, that has stabilized here and that is gently supported by the new:: syntax.

You are right, there is currently so much community work to be done, that it is surprising that we all are still alive and in good humor.

Yes, the topic WebAnnotation is the right place for continuing the discussion, but for now, I think it is optimal to help each other to get their primary goals realized. :-)FridemarPache 2006-12-14 23:43 UTC

Thank you. :)


See

A problem I see in my brief skim of ReplyToTheWholePost (I may be in error…) is that it takes a somewhat essentialist position on how people should talk.

This page takes a different position; It presents analysis and arguments for TurnBasedThreadMode as a result of how wiki works. It also presents arguments for why InterruptedThreadMode works so well in e-mail, and in usenet, where the environment is different.

The optimal way of communication is a function of the tools used to communicate, not some platonic ideal of “Turn-Based” or “Interrupted” conversation. 1

So while I prefer the title of ReplyToTheWholePost (“TurnBasedVsInterruptedThreadMode” is just aweful,) I would not link to that page specifically to talk about what we mean.

Renaming this page to “ReplyToTheWholePost” would be a good thing, I think, though; If you want to do the work, just don’t forget to also change the rest of the links of the wiki to point to this page. It’d be good to see if the LinkLanguage “sounds right” when the replacements are done, as well…

By the way, I have recently been using TurnBasedThreadMode for “substantive” comments, but InterruptedThreadMode for very short replies like “thanks”, stupid jokes, etc. I guess my current criterion is to use InterruptedThreadMode for comments which:

  • are very short
  • aren’t very important, and can be removed in reworking (i.e. a joke or a “thanks”)
  • are direct replies to an earlier comment

In these cases, I figure that the cost of effort for the reader in terms of the small loss of continuity are outweighed by the costs of looking back to the earlier comment if the comment was placed at the bottom (for example, if you see a post that just reads, “Alex: :)”, and you have to scroll up a screen and a half to find Alex’s comment, the “parent”. In such a case, you’d probably prefer to find “:) – Bayle” inserted directly after Alex’s comment).

I believe that breaking this page up into smaller (MicroContent) chunks will make it easier to edit and improve this page. Hence, I’m not sure why there would be an “regrets”.

Hmm. A while ago that we have been writing this page. Still. The quest here - the “search for a Magellhan projection of human communication” - is similar to the one on the chain-video-wiki I started a while ago inspired by the German kettenvideo.de project. Their system of allowing to fork a thread whenever whereever and continue at whichever of its current ends (or before) seems interesting to me. A nice technical solution enabling it on wiki would likely help both: written communication and chain-videos.

Footnotes:

1. Though, come to think of it, given infinite flexibility in medium, including the laws of the universe, and clear purpose, it might be possible to find a perfect or optimal communication system. Then again, it might simply end up being manufacturing a perfect copy of yourself, and replacing the other person with your perfect copy. Then again, this is the opposite of common-ication, supposing that the other person has something to teach you, too. We aim to get the best out of both people, after all. EvolutionarySpirituality: Perhaps the entire universe itself is such a communications device, and evolution its vehicle of communication.

Define external redirect: SingleThreadMode DisagreementsInDocumentMode InterruptedBasedThreadMode DiscussionBoard DivergingThreads

EditNearLinks: PicoSpan ReplyToTheWholePost DiiGo DocumentMode MeatballWiki UseNet NeutralPointOfView WikiEngine

Languages: