Here are some of the problems with ThreadMode
- Signatures inhibit editing. Many people don't like to mess with text owned by someone else.
- Writing in first person inhibits editing. If you write, "I did X", someone else can't just append "and Y" because you didn't do Y.
- It leads to contributions which can only be understood in the context of the thread. This also inhibits editing. An answer needs its question, a particular emphasis makes sense only as a counterbalance to a different emphasis in an earlier comment. It becomes hard to extract meaning from the thread.
- It leads people to read only the changes since last time they read, which typically are at the bottom of the page. They rarely reread the whole page, so they don't develop a holistic view. They just comment on the last thing that was said. They don't consider their contributions from the point of view of the whole page. This leads to meandering threads and pointless arguments.
- Thread mode makes the information less like a dynamic encyclopedia entry. Thread mode preserves and emphasizes the trivial. Who said what and in which order may not really have lasting significance.
Let's not forget that ThreadMode
has virtues as well as vices.
- It is easier to append a comment than to refactor.
- It is less work to read just the new comments.
- Communication is more natural in ThreadMode
- It might be a way to generate ideas until better organizing patterns or ideas emerge out of the content over time. IOW, BrainStormFirstCleanLater.
"Signatures inhibit editing. Many people don't like to mess with text owned by someone else."
Just a thought here. As individuals, we look at the names at the end of each comment and start to gain familiarity with them. With that familiarity, we have a way to know with decent odds if it's worth our time to read the comment. Sometimes the signature is nearly a promise that we will learn something useful, or be moved, and therefore something that time (precious as it is) should be spent reading. The point is, doesn't this make a signature a useful tool to help people avoid linear (thread-like) reading?
True, appending new comments rather than refactoring appeals to busy (or perhaps lazy) people. However, reading just the new comments and adding at the bottom of the page is an advantage only to frequent visitors. Newcomers reading the page for the first time have to read the whole thing.
Signatures can glorify the ego. Signatures introduce a whole bunch of issues that are to do with personality and self, and that many of these are shallow. Often they involve fear - fear of treading on other people's toes on the one side, and fear of not getting credit for one's ideas on the other. The fear gets in the way. It is focussed on things which are not important, cosmically speaking. You can learn to let go.
This would be more nearly true, if wiki were about "cosmic" content. I think wiki is about people communicating with people. -- RonJeffries
I think it's about how human communication works in a field of chaos. Attempts to introduce structure to such an environment is a natural response. I have a hunch, though, that whatever patterns eventually become established here will emerge from the interaction itself, not imposed on it. This should be fascinating. -- JimGirard
Personally, I don't care to have a discussion with an anonymous set of commentators, any of whom might have changed anything on the page - or several of them in quick succession, so there is, in fact, no philosophical consistency to the page. I don't feel comfortable reading the pages on wiki that have no signatures. It is an odd, sterile, discussion. -- AlistairCockburn
I'm starting to agree more and more with this. On the BigDesign
page, I made some contributions which then completely disappeared. In ThreadMode
, they might have been answered below, or addressed above and so marked. I'm inclined to think that what needs to happen is that the original author of a page that goes into ThreadMode
needs to be more proactive in cleaning up the top bits.
I think that it us up to all of us, as authors, to be more proactive cleaning up any of the pages that we read or add to. (see: VolunteerHousekeeper)
Relatedly, it is VERY difficult to read a revised page and see what has been "improved". -- RonJeffries
Maybe this whole problem is an indication that the basic technology needs some improvement. Something that'd preserve the current technical simplicity. It looks like in order to preserve this basic wiki-simplicity, complex solutions are being hashed out.
I must say it makes me nervous that style differences are not confirmed by any mark. I.e., I read some statement, then next to it there is something that seems to be a comment, but it doesn't differ in any significant way from the statement referred to. Putting comments in , as is the convention when editing letters to the editor, or using italics, as some do here, would help to make such a "talk" more readable.
There are many places on the net better than here to hold a conversation. And there are many better ways to publish a web page too. Wiki is different. As the founder of wiki I thank those who struggle to make its difference an advantage. -- WardCunningham
I'm wondering if an integration with QuickTopic
would be worthwhile. That way, discussions could optionally be explicitly separated. -- SteveYost
I can remember discovering Daniel ~LaLiberte?'s HyperNews when it was just new. (Surprised I haven't encountered him here, matter of fact.) In all the years since, there have been very few breakthrough I consider substantial ... Wiki being one, QuickTopic another. And yet I feel we haven't yet conceptualized the "solution". But I'd add I like Wiki best, perhaps because it pretends so little and offer so much. On another note, it had never occurred to me that signing would / might interfere with refactoring. If that's so, then individual signed entries separated by HRs are surely the marks of sanctification, i.e. high inertia.
One of the things that one may find encouraging about the Wiki is it's ability to both to have thread and a linear development of the topic. The problem with threading is mainly it's ability to WarpTheThread
beyond the original topic. A linear approach to the development of a given topic may drive the content of the topic further on instead of sidetracking. -- OveRubenOlsen
has a wonderful way to separate threads from content, called SubPage
are marked up like Wiki links, but they begin with a slash. You can then have a SubPage
called /Discuss to hold the threads. -- JimFl
Discussion moved from WikiReductionists:
Wiki is a forum for collaborative writing, not a chat room. Obviously discussion is necessary when writing pages together, but once that discussion is over, the pages should be modified to reflect the outcome of that discussion. You wouldn't want to read a book if it contained all the minor discussions, disagreements and misunderstandings of its co-authors.
We aren't just the co-authors - we're the characters. You wouldn't want to read a book if it didn't contain all the minor discussions, disagreements and misunderstandings of its characters.
I wouldn't want to read a book if it did contain all the minor discussions, disagreements and misunderstandings of its characters. Even the simplest of books, like "See Spot Run." would be hundreds, if not thousands, of pages long if they got into why Spot was running, or what Jane thought of Spot's running. And chapters entitled Running Considered Harmful, In Praise of Running, and Should We Run; all of which contain the same content. As has been quoted on several other pages, "If I had more time, I would have written less." That's why editors exist.
Good point. See WikiMaster
for more of the same. I'm just saying that ThreadModeHasValue
that can't be captured in a summary. Deletion may be useful at some moderate level, but re-organization and labeling are more broadly applicable. Above it should probably say: You wouldn't want to read a book if it didn't contain any of the minor discussions, disagreements and misunderstandings of its characters.
Perhaps a solution is to leave the main page for a topic in DocumentMode, and move the ThreadMode discussions into a separate page i.e. WikiReductionistsDiscussion?, or WikiReductionistsThreaded?. That way Wiki can preserve the readability of knowledge on a topic, while letting newcomers see how that knowledge was arrived at. If the readers could then filter out the Threaded pages in the RecentChanges list, they would have a good idea of where the Wiki pages as a whole were heading. And if they instead filtered out the Unthreaded pages, Wiki would look to them to be remarkably similar to newsgroups, or SlashDot.
is about that idea exactly. Ward expressed (albeit unsigned) his view that we don't need two pages per topic. -- RichardBash
Moved from elsewhere:
[Someone asks] what's wrong with [a social wiki]. Well, the simple answer is that Wiki is a really bad
media for social interaction. Look at the following "features" and how they influence social interactions:
- A deletion system where anyone can delete anything without any explanation. Leads to EditWars and hurt feelings when people wonder "did they delete my stuff because they don't like me?" instead of assuming it was deleted because it wasn't OnTopic or useful to the community.
- Frequent inability to tell who said what in a multiperson conversation. Often leads to people copying and pasting previous contributor's words so they show up on QuickDiff.
- No context when viewing the QuickDiff of a page. When LiveJournal sends you comment notifications, it includes the text of whatever the person was replying to. When you post on forums, UseNet, or e-mail, there's almost always a handy "quote post" feature to add context. With a Wiki, the only way to do this is to touch the comment before it, which usually leads to confusion as to who wrote what.
- No organization of comments. Leads to BulletedThreadsSmell.
- No enforced "reputation". Anyone can create any SockPuppet they want, and the only way to catch them is RecentPosts. Back when people adhered to RealNamesPlease, this didn't happen often. Now, there's no trust or reputation or any incentive for people to behave.
- Not RealTime.
- No way to ignore people you really don't want to read. UseNet has KillFiles. LiveJournal has friends lists. E-mail has spam filters. AIM has block lists. Wiki has proposed FilteredRecentChanges, but I don't think anyone's implemented it.
- No way to aggregate people you do want to read. As the community grows, this becomes increasingly more important, because there's no way you can keep up with a million members. LiveJournal uses friends list for this, WebLogs have RssReaders.
I'm all for social interaction through Wiki. My e-mail and screen name are on my HomePage
, and my LiveJournal
's trivial to find (though I don't normally advertise it because it's really more about HarryPotter
than computers). But I think such social interaction should take place off Wiki, because Wiki's a really
sucky media for it.
Why not talk to people you find interesting over AolInstantMessenger
? Or get a WebLog
. Or hang out in a place like Artima or LambdaTheUltimate
, which are more focused on being communities and have better tools for it. Wiki's a medium for collaborative development of ideas. WikiIsNotaForum
, and WikiIsNotYourBlog
. And that's not because some RudeDudes?
say it isn't, it's because it makes a bad
forum and a bad
I try to keep Wiki OnTopic
because the value I get out of it is the heavily focused and refactored ideas that have been refined by some of the best people in the industry. I'd like to see other young programmers have the same opportunity to "learn from the masters". But if it just becomes an anything-goes social club, I'll leave. I don't say that out of spite (I really doubt anyone would care), but because there're other online communities I'm part of where I don't have to FightTheSoftware?
every step of the way to have a decent conversation. I believe in using tools for what they're best at. If we're going to treat Wiki like a glorified social club, why not get software that works well with social clubs? -- JonathanTang
See also: WikiIsNotAboutDebate