create new tag
, view all tags
Problem: When visiting topics that are very very long, all comments are displayed. Despite the idea to refactor, historical data is often kept. This serves several purposes. Current discussion participants don't have to dive through all the diffs to a topic just to read the history. New discussion participants can simply read the information. So just appending a comment and a signature on the end is a useful standard of conduct for many TWiki sites.

The problem is that every time you view that topic it must be displayed in totality.

Another related issue is that there is no record of what you have read and not read. If discussion follows the above norm you simply read backwards, however a simple storing of meta data on visiting long topics could allow a time-stamp to be stored on a users's home page to retain that state data. It might be used to quickly navigate to the most previous unread comments.

(A fancy version of this might simply show the RCS diffs made since the last viewing of the page.)

Premise: CommentPlugin is being used or standard appending of content with signatures is used.


There are at least two features that are interdependent for this scenario to work and likely many more on closer examination. First, Some way of navigating WITHIN a very long topic must be devised. Given the above premise, the page breaks and shifting partial viewing of the topic can be controlled by searching for standard signature lines.

Second, state data must be stored somewhere about what topics have been read and when.


Threaded discussions can take place and easily followed. This is an itch that I would like to scratch for myself (and others on Codev) since following some of the long Codev topics can be time consuming without additional features beyond the standard WebChanges date/time/author information.

This feature request is inspired by CaucusVsTWiki. Caucus works in this manner much more easily due to the way it stores and structures information.

-- GrantBow - 23 Jan 2003

For the most part Twiki threaded discussion already have useful embedded metadata: the 'this is the end of my contribution' contains the author's name and the date.

I can envisage a time when all topics are stored in XML, with the signature line being converted by Twiki to something like:

<p>For the most part Twiki threaded discussion blah blah blah.</p>

<author>MattWilkie</author><date>23 Jan 2003</date>

At which point all the server needs to do is send the complete XML topic to the browser. A transform is also sent so that the user can dynamically switch between, for example, chronological order, reverse chronological, sort by author, hide older than N, etc. without having to contact the server.

For "show me what I personally haven't read yet" I see two approaches:

  • cookies for each topic with a "I was last here" date.
  • an automatic table of contents which lists the dates of the comments (for this particular feature we wouldn't have to wait for complete XMLisation of Twiki. It could be done now with a plugin.)

-- MattWilkie - 23 Jan 2003

I was thinking about storing the state on the topic, but can you imagine the cruft built up over time? That contents thing sounds very cool and I can imagine some interesting features. I don't think you even need a plugin for that. It would be nice if it was %COMMENTTOC or something but not really required In fact, lesse... I guess I need a regex search WITHIN a topic, something like %INTERSEARCH{}%

-- GrantBow - 23 Jan 2003

Good idea. And if the author can put one-line summary next to signature, %COMMENTTOC could be extremeny useful - and not hard to implement.

BUT: If we want to use signature as target anchor for %COMMENTTOC plugin, it will be much nicer if signature was on the top of the comments, not the bottom. RuleOne. Will improve readability and usability immensely.

Summary on top, then TOC, then COMMENTTOC, then Individual comments. CommentPlugin as a standard, with submission by email allowed. Then we can say, Twiki is really heavy-duty platform.

Because signature on the top is so disruptive change of current Twiki style, I do not expect it be easy - we cannot decide even to change logo with questionable legal status into nicer, custom, free HighResolutionLogos.

-- PeterMasiar - 24 Jan 2003

Heh, Peter, I'd like the logo to change sooner rather than later too, but let's not get sour about it. smile

Signature on top was not what I had in mind at all when I started this topic. I don't think for simply parsing the comments it really matters whether the signature is on top or bottom. Anyway, don't emails always use signatures? On bottom is a very strong standard. It could be argued that the headers aren't part of the written email, they are part of the envelope for the (snail-mail like) letter.

-- GrantBow - 24 Jan 2003

Yes, signatures is on the bottom, but when you click on table-of-contens entry, you expect reqested entry to be on the top of what you see (as %TOC is doing). So in fact signature with 1-line summary will be the "header" - so it needs to be placed before comment.

-- PeterMasiar - 25 Jan 2003

Ah, that's a valid point. Can't we just use the jump to the PREVIOUS signature instead? Users don't need to know!

Another addressability solution is to use some of the features in Plugins.PurplePluginDev (yet to be integrated).

-- GrantBow - 25 Jan 2003

I just wanted to point to IndexedThreadedDiscussions that addresses some of the functionality discussed here using existing features entirely.

-- LynnwoodBrown - 23 May 2003

Thanks Lynnwood, this is great. However I think the intent is slightly different for the two ideas. IndexedThreadedDiscussions intends to not use a flowing continual dialog model at all - it's more usenet threaded. I believe there are good reasons to choose the use of a flat, chronological appending blog model. For other purposes a threaded model works well, but I don't think it fits well with the TWiki cultural norms.

Fundamentally the knowledge unit of a wiki is the topic or page. Anchors can be used below that but must be added manually. (PurplePluginDev addresses this at the expense of a plugin, and it's not even developed yet.) The fundamental conflict comes because for human beings (most people reading wink ), the knowledge unit is what one person says. In this particular topic right here, the text between signatures is really what's useful. I know that if I've read the previous comments all I need to do is to scroll to (manually) look for what's appended. The additions proposed in this topic just assist the human being in an automated way in what we ALREADY do. However the data needs to be prepared so that this feature is reliable and requires little if any additional work on the part of the user to use. That's the goal anyway.

So I just wanted to point out that your idea is very different in some ways from this one.

-- GrantBow - 23 May 2003

Grant - I'm not sure I really follow some of your distinctions here but I'll forge ahead anyway...

  • My intent in IndexedThreadedDiscussions was exactly better LongTopicNav. LongTopicNav may have moved towards a different model to achieve that end but the intent I think is the same. Perhaps a topic name for this discussion that more clearly defines the specific navigational model you're looking for would be helpful.
  • If I follow what you mean by "knowledge unit" I'm not sure I agree with your conclusions. It seems to me that the distinction you are making between the two uses of knowledge unit (topic versus last comment) is simply the distinction between document and thread mode. The value of a wiki to me is exactly that it has the potential to combine these two modes.
  • Regarding your comment about "flowing continual dialog model," I don't think that really accurately reflects what happens in wiki topics. It is what we are doing right now: I say something, you respond, I respond again, maybe someone else adds a comment, etc. The assumption is that there is only one discussion thread. But what happens if someone responds to an earlier comment rather that the very last one? Well, you suddenly have multiple threads. Who's to say which is the "knowledge unit" of the topic? Perhaps your assumption here is what underlies your premise about using CommentPlugin. Yet I believe this restriction would significantly devalue the "knowledge unit" of a wiki topic. Part of the strength of a wiki topic is that it can accommodate multiple theads. I just want them easier to navigate.
  • The part of this topic that IndexedThreadedDiscussions seemed particularly relevant to was the discussion about COMMENTTOC.

-- LynnwoodBrown - 23 May 2003

Hi Lynnwood,

My intent when I began this topic was a particular implementation of TWiki technology defined by the Problem, Solution & Result that I begain with. There are particular contexts regarding the social use of TWikis, the particular technologies, the observed USE I've noticed, etc. I'll respond to your points one by one. Unfortunately the "norms" of these types of topics on this TWiki would make what I think of as a truly threaded discussion illegible and less understood. Perhaps other TWiki social norms would come up with clear conventions for other styles of conversation, but this one hasn't yet.

  • From what I've read, IndexedThreadedDiscussions is very different thatn LongTopicNav. ThreadMode is where the differences start. What you call ThreadMode I do not use as a definition for a threaded discussion. My model for true threading is from my mutt mail reader and several Usenet newsreaders I have used many many years ago. Real threading is about moving data around and sorting it by topics, poster/author or what I call "meta data". While we do share a broad intent, the methods you and I are using to get to that end vary a whole lot. I hope the detail I'm providing will allow you to see why. In addition to the topic name if taken more literally than your interpretation, I have also described the Problem, Solution and Result that was originally intended. Some of the discussion within this topic has drifted a bit, but that's OK. The topic name specifically also intends to talk about the technical definition of a topic but also the social norms that go along with topic use by twiki.org users. I do not want to change the social norms, where as I think your assumptions make changes in social norms a requirement for your plan to work, specifically editing older comments which is rather frowned upon here. I am not saying that the original ideas you are referencing from Wiki:ThreadMode are wrong, just that they are not the actual practice here at twiki.org. I am resisting an urge to explain FineGrainedAddressing.
  • From a technical perspective, there is only one "Knowledge Unit" of twiki: a topic. The technology does not allow for any other knowledge unit from a technical perspective. We humans are more refined and can understand more than machines so we know that hunks of stuff followed by signatures is also a knowledge unit from a particular source. The DocumentMode and ThreadMode are architected concepts where I am not talking about theory. I'm trying to describe and enhance the practice. You are talking about potential and I'm talking about refining practice. I was hoping my definition of problem, solution and result would make this clear to any contributor to this (technical) topic. Perhaps this is another problem, the subject matter is rich (knowledge topic) and our language and tools to describe it have not been able to keep up.
  • "flowing continual dialog model" - are we not (with notable exceptions) using a flowing continual dialog model right now? The notable exceptions of refactoring are rare in this community and probably with good reason. I'm listening to this as feedback in itself and trying to understand why this is such a strong unwritten rule. Again, you are talking about ideas, I'm talking about practice. In fact, both your idea and my idea are simply practices imposed on top of twiki to enhance human understanding. The tool is what it is. It's we humans that are concerned with meaning and understandability. IMHO to do threading right you need to have a technically different "knowledge unit" and enhanced tools to do more manipulation like news readers and mail readers. Trying to understand and accept the advantages and disadvantages of each technology and using them appropriately can be a very tricky business indeed. I've spent much of my life learning about them, starting with text based Internet in 1989 and MUDs. We have certainly come a very long way.
  • aha! Those two comments by myself and Peter in January about storing data. However that discussion was about parsing existing signatures. Peter mentioned that it would be nice to add user-submitted comment summaries and talked about CommentPlugin.

If you want to move these May 2003 comments to another page I would appreciate it. However I may just launch into a separate discussion based on our exchange here. We are touching on key issues that are very important that unless you are into the technology like you and I are, the distinctions are so subtle and small that they get overlooked and not paid attention to. The same thing happened to the lifetime work of Dr. Douglas Engelbart who I have the priveledge of knowing.

-- GrantBow - 25 May 2003

Thanks for the further clarification, Grant. Looking back over your initial problem-solution-result, I see that you really did provide the context for later comments and I was going outside of that (in both my reference and discussion). Feel free to edit this thread out after viewing as I don't feel the need to take it further.

-- LynnwoodBrown - 26 May 2003

See IncludeIndexPlugin#Other_Approaches for a very different approach. It works like the WikiWay plus external structure scaffolding and seems appropriate, where DocumentMode and refactoring do happen,

-- PeterKlausner - 13 Jun 2003

Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2008-09-11 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.