The basic "viewpoint" idea started with the "Usenet Moderation Project" about 5 years ago, when I thought I could apply the idea to Usenet. I finally gave up, largely because it's extremely difficult to get new features in widespread use for Usenet. I first saw Wiki as "the perfection of Usenet". My view now is that most Wikis replace technical security with social and political limits.
The Wiki and viewpoint system metaphors:
The "perfect" objective:
Most new systems tend to be like the old ones they replace, but with a few features improved. I think some progress can be made by considering a "perfect" system, and then considering which compromises need to be made to make it real. (The great thing about computers is how few limitations are necessary.) Here's a starting list of desired features:
Obviously, a few compromises need to be made. The core ones are:
"WorseIsBetter" is the key. My starting goal is a "worst of breed" implementation--more of a learning experience than a real system. Then I'll see what the land looks like from my new view. Xanadu-like perfection is Not Allowed.
Alice decides to write about a funny thing that happened today while in school. She visits the site, fills in an edit form, and submits the text. Bob is one of the "very open" viewpoint people who watches the incoming submissions. Bob is reading the new submissions list, and sees the edit from Alice, who has had "acceptable" edits in the past (not likely an unknown, or attacker). He reads the submission, thinks up a title like SchoolHumor?, and places Alice's submission there. A few extreme content-junkies read the submission right away.
Dave, Ethel, and Fred all see the new accepted edit over the next few days. (Cliff is on vacation.) Dave ignores it, since he doesn't do humor--he wants only practical programming. Ethel accepts it into her "interesting stories" view, and edits the story slightly to make it more consistent. Fred also likes the story, and puts it on his GoodHumor? page. George never sees the story--he doesn't subscribe to non-technical editors. Harold subscribes to Ethel's interesting stories, and sees the (slightly edited) version listed in Ethel's roadmap.
Status (April 2000):
A first attempt at implementing viewpoints failed due to a confused model and metaphor. A second attempt will begin shortly with a new model. The viewpoint idea is mostly a weekend project, so results are likely to take months to emerge. The goal is NOT to get everything right the first time, or even necessarily to produce a useful system. The goal is to create an "inspiring failure" which explores a few ideas and generates new ideas for future efforts.
I've been considering a GradualViewPoint approach. The PersonalCategories approach is another possibility. Ordinary UseModWiki development is keeping me busy, however--I'm not sure if much ViewPoint work will get done before UseModWiki 1.0 is released.
I have not worked on ViewPoint ideas for well over a year, and I doubt that I will start again soon. The recent success of the WikiPedia project  has led me to question the need for ViewPoint. On the other hand, there are several people who disagree with the "NeutralPointOfView" values of Wikipedia--they might prefer a multi-view system.
See ViewPointComments for questions and other comments.
See also WebLogDigests.
A less powerful implementation (editing of the original submissions is not possible) can be created using TransClusion. And TransClusion has been implemented using UseMod:WikiPatches/RawWikiInclusion. Whether this kind of system is usable or desirable remains to be seen. -- AlexSchroeder
Here's what I thought about ratings: make it implicit. If the user reads a page, it's a vote. If the user cares, he can also leave a negative vote or any kind of explicit vote ( a scale from very bad to very good).
What I thought had a few minor twists:
One thing to make it more of an Wiki:AttentionEconomy, by forcing editorial teams to collide with each other to some degree. For every name, such as Wiki:StaticTyping, that is subject to contention there will be a highlight icon (probably somewhere in the top right) to make it clear to the reader that there's one or more alternative points of view on the subject. This should ensure that minority voices have a greater chance to be heard and compete on merit, and also that the formation of captive audiences is avoided. A pull down menu (I like the interface at http://senseis.xmp.net/ ), would give access to alternative viewpoints. An added ornament would be to put some indication of ratings of the alternate versions or the teams that edited them in the menu that teleports the user between versions.
Also there should be a prize/reward in this attention economy: the edit team who is best ranked should get leads from anonymous readers or readers who don't rank teams among their preferences, obviously such reads will not be counted as votes.
The last think would be to make it backward compatible with existing wiki. Wiki will act by default as the current wiki, no editorial team needed, until somebody (an already established team, or even one person) decides that a page is not what it should be and cannot be made valuable by good old wiki collaboration, and only then the first editorial version of that page will be created. If my intuition is correct, and the subject of contention on a program
This can ensure a migration from current wikis, it may even preserve some spirit of the wiki, because potential attackers, knowing that there's no real harm or EditWar they can do to a page, will have a lot more incentive to collaborate and express their point of view reasonably and intelligently. Because when somebody does attack a page, the page will be forked, a team of editors will assume both control and responsibility, and he's likely to be left out in the cold.
Also because they will know that there's no way they can hide from the competition of other points of view [this much is enforced technically] , editors would strive for less bias (at least acknowledge alternative viewpoints), lest they lose the trust of their readership.
I have not figured out all the details, but now that I saw ViewPoint I'm much more confident that I, we (or whoever gets to it first) should implement it. I'm game for writing it down as "use cases" / "user stories", because there are some details left at brainstorming level, and just implement it. I'm thinking of the minimal subset of features that would allow to bootstrap the project at an acceptable level.
I think I just had a revelation (you know, one of those minor ones you get when following the spaghetti of a wiki): despite the claim that used to be above, ViewPoint is nothing like a wiki.
One of the basic tenets of a wiki is "open editing": editing is constrained by CommunitySolutions, not TechnologySolutions. ViewPoint is diametrically opposed: collaboration must be implemented with a CommunitySolution, and extra TechnologySolutions tacked on to the underside, if you will.
That doesn't mean it won't work. It simply means it's nothing like a wiki. Anything using ViewPoint must give itself a new name. I've therefore removed the "wiki-like" tag from the opening sentence. -- ChrisPurcell
Sunir, many wikis have different namespaces and support the restriction of access rights. Additional "publish" or "subscribe" features can hardly transform a wiki to a not-wiki. So I do not see how ViewPoint and WikiQualityStandard must conflict necessarily. The only real conflict would come if someone would identify "wiki" and "open". But this wouldn't work anyway because then no intranet TWiki or private PIM could be named a wiki, which IMHO wouldn't make sense. -- HelmutLeitner
My point is that we can argue back and forth about what the word 'wiki' means. There are political, economic, ideological, and technical reasons for this debate. The WikiQualityStandard is meant to exclude some coattail riders. This discussion about precluding the use of the word 'wiki' for all new technical advances in the conversational Web. So it goes. I personally would take a stricter view of the word 'wiki', but also one that is cautiously adaptive. -- SunirShah
His prototype is not very complete yet. -- SunirShah
A PatternLanguage is also strict, but adaptive. Take a very conservative view of what a wiki is, but add to that view as new facts become necessary. For instance, WikiWiki did not have a long VersionHistory until recently. WikiSpam defenses are become de rigeur. But page locking is not. We can have a debate about access issues, as in whether or not a wiki must be accessible to the wider public, but at least I think that has been answered: no, a wiki need only be accessible to TheAudience. As a wiki is primarily social, its audience may differ depending on the social context. The trick is to see if there are wide enough examples to demonstrate that each adaptation is commonplace enough to be introduced into a central definition. Everything else are either experimentations, local adaptations, mutations, or departures.
The reason why this matters is that if things keep going in the direction they are going, every conversational website will become known as wiki. Maybe that's all well and good. Wiki is more of a workflow than a technology. However, if that's the case, ViewPoint is not at all like a wiki as it does not possess the same workflow. -- SunirShah
I think I now understand what you mean. We have a kind of "best practices open wiki community process" that combines technical features and cultural habits to give us the "wiki experience". Will others appreciate this quality like we do? I don't think so. Probably everyone will use wiki to his own advantage and adapt it in a way that fits his purpose. -- HelmutLeitner
I don't think it's really even that narrow. People like [Writely] are putting word processors on the Web, but they only edit one document. There is an element of open and fluid editing, but it is still only a word processor on the 'Net, which is not moving beyond UNIX in any real way. Wiki is more than a web interface to the UNIX file system, albeit not much more. I think it's important to view wikis as something beyond mere word processing on a network or content management on the Web. Those things already have names. Conversely, highly structured workflows defeat the fundamental point of a wiki being a conversation that refers to words that don't exist. If you can't refer to words that don't exist, or all the words are predefined, then you are disempowered. Wikis are a constructive space, not a structured space. It is critically important who has the most power: developers (non-wiki) or participants (wiki).
Implementation note: This reminds me of the arch distributed version control system . Arch allows arbitrary branches, local modifications and easy repository publishing via HTTP. -- DavidSchmitt
See also MultipleViews.