(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
View Attach Info

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-20) was last changed on 04-Mar-2008 04:37 by 129.78.64.101  

This page was created on 01-Feb-2007 13:02 by ChristophSauer

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 10 removed 25 lines
The most common way that good formats make the machine work harder is by allowing multiple administrator or user-group choices or plugin configurations to deal with the same simple markup. This should be done anywhere that a decision must be collective on the part of the users as a group without every single user being necessarily able to over-ride the decision. Three examples to illustrate this:
== specifying emphasis without differentiating bold, italics, underlines, fonts
When defining titles and alternate titles, quotes or editors notes, or headings, or links, we don't usually want to specify how. What matters is that everyone presents the same type of thing (external link, internal link, alternate title, quote, citation or reference) the same way for clarity. Fonts and text styles are supposed to be a subtle cue to meaning, not an excuse for users to show off how much markup they know (why we all hate PowerPoint and the PowerPointies who use it to lie to us). CSS goes a long way to make it easy to standardize these presentations so that people can easily read our text without our having to put a lot of work into learning typography, which is an expert profession of its own.
== tags, lists, categories
Bloggers use tags, wikis have categories, everyone has lists, and it's all the same thing. We are attaching keywords to items and asking for lists to be put together from them automatically. This is one way the machine really must work much harder, and where wiki has fallen behind drastically by assuming that every list must be manually maintained. It would be nice also to see lists that are assembled from internal information put into the same namespace as the manually maintained ones, perhaps with a prefix like "all" so we know they're up to date.
Also a few conventions can save manual work and redundant pages like letting {{{ [[tag:WHATEVER]] }}} direct by default to {{{ [[category:WHATEVER]] }}} and possibly include external resources with that tag (not just the local items in that category). It is hard to think of a case where you'd want a tag named WHATEVER to not put items into a category with the same name exactly, where that category already exists.
In practice, there are many variants of a tag all of which would redirect to a single category. If categories were smart about knowing which tags indicated things belonged in that category, a hierarchy of bottom-up tagging and top-down categorizing would quickly crystallize, with lists handling most side cases and non-hierarchical purposes.
A lot of best practice ([[http://let.sysops.be/wiki_best_practice]], [[http://let.sysops.be/category:praxis]]) suggests that categories should be used to directly support the users' core work process while tags and lists can proliferate madly and unreasonably for many purposes. Wikipedia is a good example, with very encyclopedic categories but many strange lists and quite a few tags that deal with editorial issues within the pages.
== handling votes, ranks, surveys, polls
Contentious decisions are inevitable in [[wiki governance]] and not all of them are unanimous. Modern definitions of [[consensus]] allow for the exclusion of a small number of persistent voices with very different priorities, or for those who disagree to be differentiated into a watchdog or indemnified group that is highly motivated (and maybe rewarded) to spot problems with the majority view. Some definitions go further and claim that "consensus" only means about 75 per cent of the voting members! In other [[social software]] it's become common to have surveys, polls, ranking, votes, and other formal quantitative ways to rank options. This could even apply to trivial matters like presenting people in a list or allocating some kind of points like BarnStars. In any case, the machine can offer a far far better polling booth than the ordinary and generic wiki page. Yes, wiki pages do barely work for this, but only if everyone cooperates.
So one way to make the machine work harder is to let users specify things to vote on, like pages to delete or users to elect as administrators or policy to adopt, in the simplest possible notation, preferably some variant of [[list]] notation. Characters for this can be reserved (as they often are in language/format work) without requiring the functionality to be implemented in the wiki software itself. If it isn't, then, the functionality defaults to an ordinary list and people deal with as they do now on wiki voting pages. If there is however some support for voting, then each notation can be assigned to one type of vote, which allows for a lot of methods, or a very few methods, to be applied. When we vote we are used to preferring one method and getting another (especially for say the President of the United States) so it's no tragedy if only one method is available. Being forced to agree on voting methods is part of democracy. In practice, it's not hard to list candidates and say "I prefer preference voting but if approval voting is available use that, if neither then first past the post, and if nothing then just make a normal list marked as a vote". This could be done by using list notation variants like {{{ *#v }}} etc. '' as specified at [[Talk.ListsReasoning]].'' When plugin developers see a market developing that wants real support to run those votes, they'll act quickly. Reserving those character combinations meanwhile costs $0.
Version Date Modified Size Author Changes ... Change note
20 04-Mar-2008 04:37 4.54 kB 129.78.64.101 to previous speling missteak
19 21-Oct-2007 12:13 4.571 kB RadomirDopieralski to previous | to last restore
18 21-Oct-2007 05:15 4.58 kB 210.17.247.39 to previous | to last
17 26-Sep-2007 09:33 4.571 kB ChuckSmith to previous | to last restore
16 26-Sep-2007 01:10 4.61 kB 203.69.39.251 to previous | to last
15 26-Sep-2007 01:09 4.592 kB 203.69.39.251 to previous | to last
14 22-Feb-2007 02:46 4.571 kB JimGettman to previous | to last
13 08-Feb-2007 10:37 4.502 kB 150.254.78.39 to previous | to last moved the parts irrelevant to Creole to the bottom
12 08-Feb-2007 00:42 3.659 kB 216.132.15.200 to previous | to last Egregious fussing
11 08-Feb-2007 00:40 3.664 kB 216.132.15.200 to previous | to last Needless fussing - JG^.^
10 08-Feb-2007 00:02 3.427 kB 216.132.15.200 to previous | to last Jim Gettman is a systems analyst for Point.360
9 05-Feb-2007 22:37 1.393 kB ChristophSauer to previous | to last romoved stuff since it is completely out of scope here... read before you post.
8 05-Feb-2007 19:51 6.89 kB 142.177.76.130 to previous | to last fixing the syntax suggestion as per Radomir (who should like this page now)
7 05-Feb-2007 19:21 6.932 kB 142.177.76.130 to previous | to last wiki best practices
6 05-Feb-2007 19:19 6.891 kB 142.177.76.130 to previous | to last a little more on tag/category coordination
5 05-Feb-2007 19:12 6.109 kB 142.177.76.130 to previous | to last fixing a few things, extending voting example
4 05-Feb-2007 19:04 5.546 kB 142.177.76.130 to previous | to last three examples, dunno this JSPwiki markup, hope I got it right
3 01-Feb-2007 16:50 1.393 kB RadomirDopieralski to previous | to last added some context
2 01-Feb-2007 14:12 0.165 kB ChristophSauer to previous | to last typo
1 01-Feb-2007 13:02 0.169 kB ChristophSauer to last
« This page (revision-20) was last changed on 04-Mär-2008 04:37 by 129.78.64.101