• Set VIEW_TEMPLATE = SvenTopicSkinView

This is a 'discussion' topic for TalkTalk. Now that the experiment has successfully created an implementation, can we

1. rename TalkTalk to TalkPageTalk
2. set VIEW_TEMPLATE = SvenTalkSkinView on TalkPage
3. set VIEW_TEMPLATE = SvenTopicSkinView on TalkPageTalk
4. delete this topic (again) ?

-- SvenDowideit - 10 Apr 2008

please not! I've fallen in love with this breadcrumb :

TWiki > Codev Web > TWikiMarketing > TWikiMarketingMeeting2008x03x24 > MarketingHub > MarketingHubTalk > TalkPagesForTWiki > TalkPagesForTWikiTalk > TalkPage > TalkTalk > TalkTalkTalk

-- CarloSchulz - 10 Apr 2008

The "Discuss topic / Back to Topic" toggle is not visible enough. Most will simply miss it. A real tab interface would be better.

-- MichaelDaum - 11 Apr 2008

Now that we have had the Wikimedia-a-like Discuss/Back to topic for a little while, I think we should discuss what we think of it.

There are at least 2 important points to discuss:

1. the UI itself (ie, mixing action and navigation, and not visible enough)
2. if it is a useful addition to TWiki.org's Codev.

1 The UI

Both Michael and Arthur have raised very reasonable issues with the userinterface - that its not obvious enough, and that it mixes 'navigation' into the 'action' buttons. I basically looked at the 'spec' to imitate wikipedia's Article, Discussion, View source, History tabs, and decided that the discussion with 'normal users' indicated that 'discussion' is an action in their minds - they are wanting to discuss the topic. The Biggest reason that I implemented it this way, is it shows how simple it is to extend the native UI of the patternSkin via topic templates.

2 Usefulness of separating 'Discussion' from ??? on Codev

Personally I think its a useful tool for some TWiki usages, but not useful here on Codev, a web that is mostly Discussion to begin with. Separating Discussion from the other in ProcessAddToHeadAdds didn't really seem to add anything to the discussion - though it would be really useful to hear from some of the less old & grumblebum TWiki-ers on this, because some of us are pretty set in our ways.

-- SvenDowideit - 30 Apr 2008

The problem with having the discussions on the same page is that it's hard to figure out if the end of the discussion reflects the status quo or the part above the discussion.

If you have a discussion topic then you obviously don't need a separate discussion tab. But if you have a topic with a more formal or official part in it then this is very much needed. Why else do people put old discussions in TopicXyzDiscussion topics or hide them behind "rev31" type links? Because they distract people and hinder them to understand what the topic is or was all about. The TWikiMission topic is a very good example for this.

-- CarloSchulz - 30 Apr 2008

Carlo. As Sven wrote the experiment in ProcessAddToHeadAdds showed that to us that use the feature proposal application daily the split was annoying.

Reason is that the proposal topics are meant to be discussions - not encyclopedia articles. Ie. there is an interaction between proposal, discussion AND form data. It is a pain having to jump between topics and you loose the history of changes done to the proposal vs the what part of the discussion that triggered it.

As Arthur pointed out at last release meeting there is also a UI problem mixing actions with navigation.

But it was an interesting experiment.

-- KennethLavrsen - 30 Apr 2008

In Codev, I'd prefer a setup similar to TalkTest: simple, fast, good usability, minimally invasive.

There are so many examples of how people (fail to) discuss online. Codev discussions work out surprisingly well ... not because but despite the discussion feature being done like it is now on TWiki.org. Some discussions in here are of quite a high quality. Alas, the larger portion simply gets lost. Even worse, keeping them like they are right now makes them an obstacle. However, discussions get lost in other forum or blog applications as well. So it is not surprising this happens here as well. While blogs and forum boards are good in "forgetting" as their content is ordered chronologically, wikis are considerably bad in "forgetting"...

But let's first focus on the usability of a single discussion topic. Sven, with all respect, but your solution doesn't cut it. TalkTest may neither. So how can we continue from this point?

-- MichaelDaum - 30 Apr 2008

@ Kenneth: Sven asked short- and midterm contributors (like me) about their opinion so that's what I did, state my opinion. Maybe having discussion tabs is annoying to you, but you are not everyone.

"But it was an interesting experiment."

So you are the one who decided that it's over?

-- CarloSchulz - 30 Apr 2008

I feel that TalkTest is actually much more invasive, and less useable - for me, I would like some information on how and why TalkContrib doesn't cut it, even though i agree.

However, Carlo is the only non-old-grumblebum to comment thus far - please, if you're a less 'old wizened TWiki-er', or even someone that uses TWiki.org less - Please speak up - we're way too insular in the design feedback that we get here.

-- SvenDowideit - 30 Apr 2008

Sven, I think you have received quite a lot of feedback right now. What's your opinion on how to make TalkContrib more usable?

-- MichaelDaum - 30 Apr 2008

From the readers point of view I prefer the TalkTest over the current TalkContrib as its faster, more connectetd to the actual content and there's no mixing of actions with navigation.

-- CarloSchulz - 30 Apr 2008

@Carlo - It is in the context "Feature proposals" I found the split in two pages a huge problem. I am the one that is supposed to keep track of the progress of all the proposals and I cannot maintain the overview having things split in two. With the usability problem addressed the same approach may work fine for other Codev topics like those that describe a process. So keep on experimenting. But please don't split the feature proposals because I loose the overview.

-- KennethLavrsen - 30 Apr 2008

It is good to experiment and refine our collaboration model on twiki.org. As Kenneth said, I find it also a bit distracting to open two windows to see spec of proposal and discussion. Personally I like the split approach: Top of topic is DocumentMode (spec should be refactored there), followed by ThreadMode (linear discussion). There is a clear marker (the Discussion heading), so I do not think it is confusing to have both on the same page.

What we need to get better at is to refactor the top part of the page to reflect the consensus of a discussion. I think that is the real issue. That is, I do not think that splitting up document and discussion into two pages will make a difference in refactoring. In contrast, I think it will make it less likely to go back to the document topic to refactor the content. Time will tell.

-- PeterThoeny - 01 May 2008

Time has already told:

• Codev is a mess
• People are suffering from not finding the information they need
• knowledge isn't managed well in here
• the system does not support finding a consensus

Don't leave it as it is. Try to understand why it is so bad.

True, people don't refactor the proposal. But keep asking why! There's a hidden reason. It surely is a mixture of technological aspects, interaction design, web design, information architecture and last but not least social aspects.

People prefer to add comments on comments on comments on comments. On TWiki.org, they are not behaving differently here as they do in email threads.

As has been said before (e.g. on the last twiki summit), one way is to slim down pages that users have to scan for the "real info" is to move the discussions off the front and put it onto a separate tab/topic. Whenever someone has to say something he wants to stay as part of the issue at hand, he'd have to move it from the discussions part to the front. This would immediately ease the consumption of Codev topics and remove lots of bias and heat from the real issue.

Sometimes topics do get refactored: by deleting all of the discussion. They are either preserved as part of the topic history or moved to an extra archive topic.

Let's plan this refactoring step ahead by separating discussion and proposal right from the start.

Please, this TalkTalkTalk is just one of the points why TWiki.org is a very bad showcase for TWiki. It is so bad, that there even is no point in doing any technical improvements under the hood.

As has been said: there is a mixture of aspects to make this all more effective. Think of it as the product of all these aspects or the space opened in a diagram with axes representing the scoring for each aspect. I believe that we are quite good on technology compared to the other aspects ... which keep holding back TWiki.

Anyway. Let's refactor discussions on Codev, please. Don't neglect the problems we have.

Here's an article on Creating a slick tabbed content area in case you lack inspiration.

-- MichaelDaum - 02 May 2008

The talk page experiment problem was that it was TWO independent topics. One contains the proposal and the important form fields like the committed developer, status and if someone raised concern. And the other the discussion. So I could be on the talk topic and having to navigate back to the proposal topic to see the proposal as well as the status. That was confusing. Each time I saw a WebChanges update of a talk page I needed to open the proposal in a separate browser window to see what the proposal was all about and to check the status and if the proposal had been refactored. It did not help me at all that the split was in two topics. On the contrary I could no longer easily see the exact version when a comments was added and a corresponding refactoring was done without manually comparing dates in the history. What took me seconds before took minutes. It simply did not work because the two were split apart.

I have also seen the other experiments where the discussion is within the same topic but hidden behind some smart looking tabs. That is much better. But only in view mode. The minute you hit edit you see all the advanced geek stuff that make up the tabbed design.

The idea is good but from a UI it has to be "clean" so either you see a topic or the comment and you have to be able to jump between the two edit fields.

It is not lack of webdesign that creates the problem with not reaching consensus. We actually used to have a good track record of reaching consensus on feature proposals but the problem has been lack of participation. Only 2 or 3 people comments on the proposals and the proposers are not following up the discussion.

Another issue is when what starts as a simple proposal - simple to implement - is being developed into a "save the planet" proposal which the original proposer does not have the skill-set or time to implement. Naturally people should not feel that you cannot propose something better and more advanced. I think we need to develop a better way to then split up such a proposal in a short term that the proposer can start with and a long term proposal - or people need to add themselves a committed co-developer.

The general observation on refactoring on Codev is true. We are not good at refactoring. Refactoring takes time. You easily spend an hour refactoring a twiki page because it is not just a matter of writing but also to get the facts right. No webdesign will change how much time people are willing to spend refactoring.

I keep on saying - and I know I am almost alone with this opinion - that we are not good at deleting content. This topic for example. In 3 months it is close to worthless. In 2 years it is pure noise. We know it already now. And yet it will stay here on Codev till end of times. Being a talk page or hidden in a talk tab in meta or whatever does not change a thing.

The tabbed comments on Wikipedia works because Wikipedia is an encyclopedia. It is the whole idea. The discussion is usually not interesting and most of us never look at them. It is a whole different context.

And even here on codev we have different contexts.

A feature proposal is alive while it is being debated and implemented. A year after it is just history which is nice to have and should not be deleted but not really very relevant for people to find in a search.

Topics like ReadmeFirst, DeveloperResponsibilities, TestCasesTutorial etc are a totally different context. Here the Talk page or discussion totally separated from the topic make 100% sense. Such pages should be free of discussion and refactoring should be the norm and not the exception when a question on the discussion topic is answered.

But on the feature proposals, I prefer the simple split of proposal at the top and discussion at the bottom because I need the simultaneous overview and I need the sync info between comment and re-factorings. Different contexts different solutions.

-- KennethLavrsen - 03 May 2008

Hm, your description of how you use TWiki.org to track changes sounds a bit artificial, i.e. your description of not being able to track changes in the talk and in the proposal once they are on separate pages. Sorry, but I am pretty sure you practically never had these problems, mostly because the by far largest part of currently ongoing discussions is not split over several topics. We factually still keep proposal&discussion on the same topic. So it seems that your description is only an outline of a theoretical use problem that you think you might have once every proposal had a separate talk page at a distant point of time in the future.

Anyway. Setting up online discussions is not that easy to get away like this on TWiki.org. It simply does not scale, wrt number of changes, users and last not least usability. Modern forums - and we are talking about the forum situation here - have to cope with some 10k users, 50% being active. Nobody would be able to cope with such a level of activity if it would happen on TWiki.org. And that's why it does not happen.

Even forums are bad in forgetting. Everything is kept forever. Though they have a natural advantage over wikis ... as I outlined before. If you need to actually delete discussions to be able to cope with new ones, then something else is wrong.

"The minute you hit edit you see all the advanced geek stuff that make up the tabbed design."

Which geek stuff do you mean? Do you mean the TalkTest example? There's not much geek stuff in there as far as I can see. How much geek stuff would be acceptable?

-- MichaelDaum - 04 May 2008

I would like to highlight something more IMPORTANT that Kenneth said:

"I keep on saying - and I know I am almost alone with this opinion - that we are not good at deleting content."

I think that there are a large goup that would like to see content deleted. I also think there are a large group that would like to see topics deleted. I created the TalkTalkTalk demo specifically because some people were of the opinion that it would solve our woes (on TWiki.org), even though I dissagreed, for the same reasons Kenneths aludes to (see my point 4 at the top of the topic!).

IMO neither Micha's nor mine are good for Codev, though they both have application elsewhere (and I've been working slowly on a 'dead sexy, ajaxy goodness, non-geeky update to TalkContrib' but I've had little spare time recently.

So, to get back to the important - I think the majority of TWiki.org users would like to see more archival of out dated content - how do we give everyone permission to delete?

-- SvenDowideit - 05 May 2008

Set up an archive web and simply put everything in it that hasn't been edited since Dakar is out

-- CarloSchulz - 05 May 2008

Kennet, you're not alone. The trimming of Codev content has been discussed perhaps "one time too many" times. Crawford even gave a proposed algorithm for archival.

Deleting content in a topic has not been that controversial (it only happens when someone grew tired and totally refactor a proposal). Deleting/Archiving content is always invariably squashed by the "CoolURIsDontChange' argument.

I would gladly help to trim down Codev (by archiving, deleting, or moving around topics), as soon as it is decided that the trimming will be done.

-- RafaelAlvarez - 05 May 2008

Tried to delete this topic already (see CodevTalkTalkTalk)

-- FranzJosefGigler - 05 May 2008

Sven asked for more input from "non-old-[TWiki]grumblebums." I'll add 2 cents. I'm a new TWiki admin, trying to find answers about problems we're experiencing and figuring out how to do things that we want to do. The release docs on the TWiki web are mostly helpful, but really limited as far as helping with these two needs. So that leaves Codev and Support. I find a lot more discussion about the topics I need help with on those two webs but, as many are saying (at least on just about every topic on Codev), there is a serious problem with [lack of] refactoring. I could be wrong, but what it looks like to my inexperienced eyes is this: A discussion begins with enthusiasm. But one of two things happens.

If someone suggests something something that seems to work (a patch, a change in code, or the use of some poorly-documented workaround) the long-time TWiki folks say, "Yup, I think that will do it," and their interest stops. There is no refactoring that solution into the documentation or otherwise explaining it for those that aren't Perl scripters or have intimate knowledge of the code. Maybe that's justifiable because the Codev is arguably about and for the developers and their work, but the problem is that much of this information doesn't seem to ever get incorporated into any documentation. And, again, to me it looks at least a little like those who know lose interest in the subject as soon as they see mention of something that should work.

The other thing that I perceive I think others may have alluded to here--a sort of apathy. An discussion begins enthusiastically. Then someone brings up the topic of refactoring and the original discussion becomes lost in the debate about cleaning up TWiki.org. The whole thing degenerates until everyone feels tired and helpless to do anything about it so that discussion loses interest until a new one begins.

As far as the original discussion about TalkContrib, I agree with Sven about its use on Codev. It seems redundant as it seems to me that Codev itself IS a discussion. But I love the idea in general. I think it would be perfect for TWiki's release docs, for Plugins, and for our company TWiki and probably those of many others.

-- DavidWolfe - 14 May 2008