GradualViewPoint

MeatballWiki | RecentChanges | Random Page | Indices | Categories

---

It may be possible to gradually form a ViewPoint-like system from a wiki. The original ViewPoint idea was to start fresh, and create a new system designed for the ViewPoint goals. The new goal is to gradually add capabilities to a wiki until the ViewPoint goals are achieved. (People write, edit, and read what they want.)

The biggest advantages of a gradual method are:

• Early feedback and learning from mistakes (or even non-mistakes). An early working model can be tested to find weak spots, and redesigned before additional code is layered on top of the weak point.
• Some features may be unnecessary, or unused by the community.

Some of the intermediate steps include:

• User preferences
  • RecentChanges options
  • Rendering options (page colors, link styles)

• PersonalCategories: mostly invisible metadata
  • Complex user preferences
    • Lists of categories
  • Extra editing interfaces
    • Category editors could choose to display a list of category-adding links on each page. Clicking one of these links would add a PersonalCategory? entry to the current page.
  • Additional search tools
  • Per-user/namespace security model
    • "Open" spaces that anyone can edit
    • Single-user locked spaces
    • Group-shared spaces
      • Revokable access?
  • Initial namespace divisions
    • If two people want a single name (for different purposes), who should get the name?
    • Initially, all namespaces may be numbered, like XpReview?1
  • RecentChanges categorization and filtering

• Personal Metadata
  • Like categories, but each entry has a name and associated data.
    • Useful for rating. Rather than individual categories like XpReview?1!Great, XpReview?1!Good, XpReview?1!Poor, one could have a single "rating" metadata like "XpReview?1!Rating: 7".
    • Could be used for some alternate-view data, like credits (for searching), editorial comments, and related pages.

• Multiple page sections
  • Like PersonalMetadata?, but a user could display/render some of the metadata whenever they visit a page.
  • Editorial area(s) for every page
    • Could discuss refactorings, merging versions, rationale for ratings, etc.

• Multiple versions of main page content
  • Possibly as simple as displaying MarySmith?37!MainPage?
  • Maybe display more than one version, or even diffs between versions.
  • Requires new reader tools to select version(s)

• Multiple database views
  • True renaming and deletion of pages local to the viewpoint.
  • May not be necessary with synonyms and filtering?
    • A full view might be a list of (lists of) synonyms and filtered pages, along with a list of page sections to use.
    • Might be needed if the extra layers are too difficult to use in practice?
  • Possibly only useful for extremely different experiments like a Wiki:StoneSociety?

Misc features (could be added anywhere):

• Admin abilities
  • Basic security model (single password?)
  • Page deletion and renaming
  • Abuse detection/prevention

• Optional "submission" method
  • Rather than directly altering a page, a user could submit their proposed edits to all interested editors. Editors could easily review, select, and edit submissions into existing pages, or create a new page if appropriate.
  • Submissions could be valuable even in simple single-view wikis, especially for authors who are unsure about contributing.
  • Probably most useful for adding new pages.
    • Some read-mostly sites could use reviewed submissions rather than simply setting their site to admin editing only.

• Page synonyms rather than renaming/redirecting?
  • For instance, suppose the content of "BobSmithXpExperiences?" is excellent, but you hate the name. Rather than renaming the page, one could add a synonym like "XpDiaryBobSmith?" (to fit in with all the other XpDiary? pages).
  • Synonyms are similar to redirection, but not quite the same. For instance, in the example above, the user could edit and bookmark the "XpDiaryBobSmith?" name.
  • Synonyms would give each page multiple possible names.
    • In a database-driven system, there might not even be a single "true name".
    • Some indication of the other names should be available (not by default?)
  • Could be global, open-metadata, or personal metadata

• Page filtering rather than deleting
  • A filtered page name would be effectively undefined. If one tries to define a "filtered" name, one would be shown the existing page.
    • One could then define a new main-content section, however.
  • Could be global, open-metadata, or personal metadata
  • Global filtering could be used as a step short of deletion
  • Negative filters? (always show, even if otherwise filtered)
  • Global filters might be overridden by personal ones?
    • Ordinary users might filter pages that they do not want to be notified about.
      • Pattern-matching filters? (Hide XpPoetry?*, Show *OpinionFromGeorge?)
  • Voluntary Global HiddenPages
    • For topics like dieting, hobbies, or personal subpages that are not of general interest.
  • Could tie nicely with PersonalCategories.

• Shift from file-based to database storage.
  • Much more powerful searching and organization tools.

---

Any comments? (I know it's hard to comment on such huge brain-dumps like this one.) --CliffordAdams

Add TransClusions to the UseModWiki script. Run the script with SubPages turned on. Add user identification. Add user-level page + subpages (entire page hierarchies) locking. Add versioning. Run the script. Find something big, political, loud and controversial to talk about. Build the community. Flow. -- SunirShah

Some clarification. No, don't do that to MeatballWiki, please! (Where's your sense of adventure? OK, I'll try to keep things more stable here. :-) These are changes I think would be sufficient for a good start at a ViewPoint. As for the TransClusions, I meant use InternalTransclusions.

I've considered transclusions a few times, but I don't see what benefits it would bring. I'm not really interested in writing the ultimate tool for bringing together all possible forms of information. Some examples of benefits would be welcome. (Perhaps the main benefit is making nice examples for the concept of transclusion. :-)

The major advantage of transclusion over copying is that all (transcluded) copies will be modified if the original is modified. This can also be a disadvantage, as the original may be lost or altered in ways which make it less appropriate for transclusion (see ContentSwizzling).

I'm considering (long-term) a few related ideas. One is to allow editors to mark pages of special interest, possibly with a text reminder. The editors would receive a special notice (probably on RecentChanges) when marked pages are changed. This could be used to mark the source page of copied text so that the editor could copy appropriate updates.

Another more radical idea is to allow pages to be split into "fragments" which could be individually displayed or hidden. Transclusion of fragments might be more appropriate.

Any more ideas? --CliffordAdams

Transclusion seems necessary with ViewPoint as wholesale duplication of information is the nature of the day. Copy and paste is just as bad here as in programming, I figure. -- SunirShah

The current ViewPoint plan is to use "page sections" and view-layers rather than transclusion. One could write additional sections (displayed before or after the main content), and/or replacement/overlay sections (replacing the content). Most views will be based on another view--the "base" or "original" view will be displayed unless some change is made. The main difference between sections and transclusion is that the selection and ordering of sections will be done with metadata.

I don't expect the first version of ViewPoint to work well. Hopefully the first version will provide enough learning experiences to make the second version easier. --CliffordAdams

Does everyone's added sections show up on everyone's views? To properly diversify the number of viewpoints, I suspect you'll need to copy (or transclude/include) in whole another datum and surround it locally with your own work. But you should not affect that datum doing so. --ss

The main goals are to allow editors to create exactly the views they desire, and for readers to read the "best" views. Reading should require minimal effort (choosing a few views, or a single group of views). Editing should also be easy for the typical case. Tools like sections or transclusions may be supported if they make these tasks easier.

One could think of page names in ViewPoint as locations. At each location there will be a pile of sections. Some of the sections will be alternate versions of the main content, while other sections will be "additional" (like extra references, jokes, editorial comments, etc.). A "view" is basically a set of instructions for converting the available sections into a final rendered page. (Some of the popular additional sections may become user-selectable.) More on this later. --CliffordAdams

---

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: