(redirected from MultiplePointOfView)

ViewPoint

MeatballWiki | RecentChanges | Random Page | Indices | Categories

"ViewPoint" is a working name for a new system. The following text is an early attempt to describe the idea.

Background:

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:

Wiki is like a public message board. Wiki pages are like individual sheets of paper. Anyone can put up messages, or edit messages (think margin notes, copy machines, cut/paste, and replace). Under any particular title (area of the board), at any one time, there is only one text. Readers generally scan the board looking for new items, and those that have changed significantly.

The viewpoint system is (vaguely) like a set of magazine publishers sharing a common slush/content pile ("submissions queue"? newswire?). Anyone can be an "editor" of their own magazine (viewpoint). Submissions come in from writers, and are placed in the common slush pile. Any editor can copy any material from the pile, and place it as a page in their magazine (viewpoint). All pages altered by editors are also copied to the slush/content pile. Some magazines are mainly original submissions, while others are mainly pages taken from other magazines. Readers subscribe to a selection of one or more magazines. (Some default bundles of subscriptions could be presented on the first visit.)

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:

Any writer can write anything they want to write. Writing is easy, with no significant barriers to contribution. No usernames or other authentication is required, but authentication is available to those who want it.

Any editor can change anything they want, to any degree of editing including deletion. All of the different versions will be kept.

No edits will be forced on any editor, but editors can edit the output of other editors to an arbitrary degree. (The output of any editing is also a submission, which can be copied/branched and edited.)

Any reader can read the "best" version of any material, for their own particular view of what's best. This should require *very* little effort, like maintaining a magazine subscription.

All people can be writers, editors, and readers.

(later) Arbitrary subsystems (like Merel's Wiki:StoneSociety, moderation, rating, etc.) can be implemented within the larger system. Subsystems can cooperate or ignore each other.

(later) Any site can participate or leave at any time without serious disruption. Any site can contain any subset of the full material, and/or variant versions that are not for the full public (like an "adult" site).

(later) I'm only considering text and HTML for now, but other media could eventually be integrated. For now, any multimedia would simply be links.

The compromises:

Obviously, a few compromises need to be made. The core ones are:

Individual writers and editors have no control over what readers see. A writer can say something, and no editor may wish to use the material, or the material may be altered until it is unrecognizable. Even if the original message is accepted by an editor, there may not be any readers who subscribe to that editor. Writers aren't guaranteed any editors, and editors aren't guaranteed any readers.

No right of attribution for submissions. [Before Wiki, I would have considered this a fatal flaw.] The need to preserve attributions restricts editors so it is removed. [I do think protection against malicious misattribution is a good feature, however.] Attributions do not have to be stripped, and many editors will try to preserve them.

All submissions must be essentially public domain, as they may be copied and/or altered at will. [Exceptions to this and attribution would be handled by links to an outside controlled system.] Even the Open Content license is too restrictive. Perhaps the freedom to copy/edit may be restricted to within the system, however.

Submissions need to have some value worthy of their disk space. This isn't hard for human text, but some people would insist that a gigabyte of random numbers, or 100 emacs core dumps are an artistic statement. Those people should buy their own disk space. For other people, a small starting amount (like 5 meg) could be given, and expanded if they provide value (even relatively low value) to the community. This is also a problem for editors--their edits need some value.

Beyond a certain size, bandwidth needs to be paid for. (Bulk dedicated bandwidth should be around $1/GB pretty soon--right now there are a few $2-3/GB deals.)

Implementation:

"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.

Each viewpoint is a complete wiki, controlled by an editor. Only the editor (and later, anyone they authorize) has any permission to change pages within the viewpoint.

Each page within a viewpoint can be either content, or a (text) pointer to another viewpoint/page location which has the content. A viewpoint can be based on another view, which means that any page not found in the current viewpoint would be looked up in the base viewpoint--very much like inheritance.

To start, writer submissions may be listed in a simple queue. A few "open view" viewpoints would accept almost any submission, and give it a page title. (Frequent authors may simply publish their writings in their own viewpoints.)

Readers use a cookie (which can be anonymous) which records which viewpoints the user subscribes to. (If the usual list gets long, it might just become a username with the subscription list kept on the server.)

At the start, viewpoints are controlled by single accounts with complete power over their viewpoint. Editors can voluntarily work together, but each view has a single executive. (If others disagree, they can copy all the content and set up a new view.) Later, maybe systems like voting would allow more automated cooperation.

Full HTML control could be given to some views.

Story example:

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.

August 2000:

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.

April 2002:

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 [1] 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.

--CliffordAdams

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

ViewPoint requires full VersionHistory plus the ability for users to create and read filtered versions of the site content. -- SunirShah

: Actually, most of ViewPoint would not require full versioning. Each editorial view will only be edited by people accepted into the view. Some short-term versioning might be useful, but truly divergent versions should be in different fragments, pages, or views. Kept pages might be very useful for the "open" views, however (the "open" views would be very much like current wikis). --CliffordAdams

So there's this Wiki:WikiChangeProposal that I am embarrassed to have thought about it in ignorance of Clifford's ViewPoint (pun intended). --CostinCozianu

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

: Chris, I'm not so sure about this. For example CostinCozianu is developing a wiki prototype that will have parallel pages of different workgroups and of course he will call it a wiki. A lot of wikis have options to protect or restrict access to selected pages. There are wikis used for PIM, where only one person has access. Who will want to ban the use of the term "wiki" for such extensions or uses. -- HelmutLeitner

Helmut, you will. cf. WikiQualityStandard. (I support restricting the use so the word retains some semblance of meaning.) -- SunirShah

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

: That's just a hard restriction on who your community is, which is a matter of who you let access the edit functions - a HardSecurity measure to cut out unwanted collaboration built on top of the wiki's basic collaboration. ViewPoint starts from there being no collaboration, and optionally adds it on top, piecemeal. -- ChrisPurcell

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

: Since MeatBall has started to talk about ViewPoint, I like to let whoever not in the know that CostinCozianu is heavily promoting his prototype Wiki:WikiChangeProposal as a ViewPoint like device. So maybe it is no longer CategoryUnimplementedWikiTechnology? Also I would appreciate initial views whether such devices can help to preserve community harmony, if insiders start to persist on EditoralControl?? Thanks for any opinion shared -- DavidLiu 26Oct

His prototype is not very complete yet. -- SunirShah

: Sunir, could you elaborate on "stricter view of the word 'wiki', but also one that is cautiously adaptive", perhaps we can define a new framework to order all our viewpoints.

: I agree that we actually "argue back and forth what the word ''wiki' means" and this discussion is nowhere at the end. The difficulty of creating a wiki definition seems to come from wiki being a MultiPattern. I would like to distinguish between what a wiki engine is able to do and what a wiki engine is configured to do. WikiQualityStandard might make wiki engines somewhat measurable, not in the sense of "this is a wiki and this isn't" but in the sense of "this engine is 50% WQS-1 and this engines is WQS-1 + 70% WQS-2".

: It is interesting that I just got a request for a political wiki system (elaborated specification, does this exist? can this be implemented?) that is close to what ViewPoint and Costin want to offer. I think that the ViewPoint idea was just a few years too early, ahead of its time. -- HelmutLeitner

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).

By the way, I'm not convinced ViewPoint isn't wiki-like. I'm just saying it's a reasonable conclusion to make. -- SunirShah

WikiBlogging and the use of TiddlyWiki could be a new way to elaborate on ViewPoint. -- FridemarPache

Implementation note: This reminds me of the arch distributed version control system[2] [3]. Arch allows arbitrary branches, local modifications and easy repository publishing via HTTP. -- DavidSchmitt

: I think that WikiPedia:Knol can be considered a ViewPoint system (in fact, it isn't a wiki). Knol [seems] to have completely failed, because of lack of collaboration, I suppose, since Knol discourages collaboration because of ViewPoint itself (see CliffordAdams on ViewPointComments), and because of incompatible and not-free licenses. --FedericoLeva

(redirected from MultiplePointOfView)

ViewPoint

Discussion