Alternate wiki-implementations: Difference between revisions

    From Consumerium development wiki R&D Wiki
    No edit summary
    No edit summary
     
    (14 intermediate revisions by 9 users not shown)
    Line 1: Line 1:
    Currently 3 out of 20 of our registered users are registered [[MediaWiki]] developers, which makes our percentage of developers among users '''15%''', which is likely the highest figure any public MediaWiki installation can boost so that is an good incentive to try to adapt MediaWiki for our use over other wikisHowever they might just be here ''because'' we are using MediaWiki, so, it is important to make clear that one of the things the [[R&D Wiki]] is doing is ''choosing'' what technology best fits our [[hardware requirements]] later.
    '''Wiki code''' enables the [[Research Wiki]] and [[Publish Wiki]].  Choices we make about it will guide the [[Consumerium Software License]] and likely also the [[software development process]] - probably in ways we can't easily change or undo laterWith so many '''alternate wiki implementations''' out there, it is important to sort through the advantages and disadvantages of each.


    There are three leading candidates, and a few dark horses listed afterwards.  It seems likely that we'd ask those who want to be [[Consumerium developers]] to work on [[wikitext standard]]s and on soliciting and forwarding [[end user feedback]] better, starting with our own [[MediaWiki modifications]] requests.  Consumerium users should not have to do anything but list these here.  Similar pages for [[TikiWiki modifications]] and [[MoinMoin extensions]] can be created, and which one meets our needs can be more of a competition.  In most cases, the features that must be ''added'' are different for each package, since they start with different feature sets.   
    This starts by considering the [[wikitext standard]] that our present text is in:  Currently 3 out of 20 of our registered users are registered [[MediaWiki]] developers, which makes our percentage of developers among users '''15%''', which is likely the highest figure any public MediaWiki installation can boost so that is an good incentive to try to adapt MediaWiki for our use over other wikis.  However they might just be here ''because'' we are using MediaWiki, so, it is important to make clear that one of the things the [[R&D Wiki]] is doing is ''choosing'' what technology best fits our [[hardware requirements]] later.
     
    Also, a good [[software development process]] ''requires'' shifting to a ''new'' development base when moving from [[R&D]] to [[production code]] - most studies show that it is very very bad to use the same platform and the same libraries, for instance, as one used in the R&D phase, in real production.
     
    So, there is ample reason to believe that we might move off [[MediaWiki]] later, or reserve it only for R&D use.  There are three leading candidates, and a few dark horses listed afterwards.  It seems likely that we'd ask those who want to be [[Consumerium developers]] to work on [[wikitext standard]]s and on soliciting and forwarding [[end user feedback]] better, starting with our own [[MediaWiki modifications]] requests.  Consumerium users should not have to do anything but list these here.  Similar pages for [[TikiWiki modifications]] and [[MoinMoin extensions]] can be created, and which one meets our needs can be more of a competition.  In most cases, the features that must be ''added'' are different for each package, since they start with different feature sets.   


    Also [[APC Action Apps]] might become important to integrate, since they have broad use among [[nonprofit]]s.  One might for instance be written to support some common [[barcode]] readers, in cooperation with [[Adbusters]] or another of the [[essential projects]] which recognizes barcodes as being as critical as we think they are.  Maximum cooperation and out-sourcing should be encouraged.
    Also [[APC Action Apps]] might become important to integrate, since they have broad use among [[nonprofit]]s.  One might for instance be written to support some common [[barcode]] readers, in cooperation with [[Adbusters]] or another of the [[essential projects]] which recognizes barcodes as being as critical as we think they are.  Maximum cooperation and out-sourcing should be encouraged.
    Line 8: Line 12:
    <table>
    <table>
    <tr>
    <tr>
    <th>[[MediaWiki]]</th><th>[[TikiWiki]]</th><th>[[MoinMoin]]</th>
    <th>[[MediaWiki]]</th><th>[[GetWiki]]</th>
    </tr>
    </tr>
    <td>
    <td>
    *Not humanly possible for [[end user feedback]] to reach developers reliably
    *Not humanly possible for [[end user feedback]] to reach developers reliably, though [[Meta-Wikipedia]] has some channels experienced [[trolls]] can exploit
    *PHP based
    *PHP based
    *Proven to perform well under heavy load - but with hard limits
    *Proven to perform well under heavy load - but with hard limits
    *Most likely basis for [[wikitext standard]]
    *Only rational basis for [[wikitext standard]] given over one million articles in fifty languages
    *Working now for R&D purposes
    *Working now for R&D purposes
    *Dedicated developer community which also mostly develops content
    *Dedicated developers heavily involved in content problems, although they are in general [[Wikipedia]] content problems
    *Readable documentation, thanks to the above
    *Readable documentation, thanks to the above
    *A very high ratio of developers (15% of registered users) registered in [[consumerium]]
    *supports [[MySQL]] only
    *supports [[MySQL]] only
    *already converted into the [http://en.wikipedia.org/wiki/TomeRaider TomeRaider format] for off-line browsing on many [[handheld device]]s
    </td>
    <td>
    GetWiki is a [[fork]] of MediaWiki under [[CC-nc-sa]]
    *same de facto [[wikitext standard]]
    * Auto-import of Wikipedia articles via [[XML]] using [[PHP programming language|PHP]]'s [[Expat]] Library
    * Well-formed [[XHTML]], replacing deprecated [[HTML]] 4.0 versions
    * Improved use of [[Cascading Style Sheets|CSS]] styles (colours, positioning)
    * Cleaner output to the browser, [[PHP programming language|PHP]] code underneath
    * More integrated and effective use of [[Cascading Style Sheets|CSS2]], beyond font colours
    * More intuitive User Preferences page
    * Clearer labeling and checkbox placements
    * Fixed user login retention and other fixes
    * Better use of [[license|licensing]] notices on pages
    * Image [[Wikinfo:Image use policy|thumbnail]] display
    * Better organization of [[function]]s and classes, filenames and [[variable]]s
    * More comprehensive [[sysop|administrator]] tools
    </td>
    </td>
    </tr>
    <tr>
    <th>[[TikiWiki]]</th><th>[[MoinMoin]]</th>
    </tr>
    <td>
    <td>
    *Not humanly possible for [[end user feedback]] to reach developers at all - form for describing [[wiki feature request]] incomprehensible even to a [[usability guru]]
    *incomprehensible, worthless, [[SourceForge]] bug reporting;  Not humanly possible for [[end user feedback]] to reach developers at all - form for describing [[wiki feature request]] incomprehensible even to a [[usability guru]]
    *Feature rich (e.g. forums, picture gallery, blog, maps, email newsletter)
    *Comment forum on every page
    *Granular [[user group]] permissions - may be drawback, see [[forgiveness not permission]]
    *PHP based
    *PHP based
    *meets ''many'' standards ([[CSS]], [[XHTML]], [[pear.php.net]], [[smarty.php.net]], [[RDF]]
    *Uses different [[wikisyntax]] then Wikipedia
    *email/forums (and integration) built-in
    *Meets ''many'' standards ([[CSS]], [[XHTML]], [[RDF]]
    *Group management built-in
    *Relies on [[pear.php.net]], [[smarty.php.net]]
    *chat support intended
    *email/forums (and integration) built-in but rarely used
    *[[Group management]] built-in - would this help with [[faction]]s?
    *Visualization of wiki-links
    *Visualization of wiki-links
    *Polls built in
    *[[Polls]] built in
    *Many developers doing lots of detail work on CM and CMS
    *Large active developer community with scattered documentation and communition forums
    *supports Postgres, Oracle, Sybase and [[SQLite]] (built in PHP 5.0!) databases not just MySQL - strategic to integrate with some [[essential projects]]
    *Supports Postgres, Oracle, Sybase and [[SQLite]] (built in PHP 5.0!) databases not just MySQL - strategic to integrate with some [[essential projects]]
    *developers [[eat their own dog food]] = run current beta as their live site for all development, so any problem is immediately obvious to every developer
    *developers [[eat their own dog food]] = run current beta as their live site for all development, so any problem is immediately obvious to every developer
    </td>
    </td>
    <td>
    <td>
    *[[End user feedback]] directly solicited in a public wiki
    *[[End user feedback]] directly solicited in a public wiki
    *Python language
    *[[Python]] language, useful for possible future development of advanced [[UI]] and [[Consumer Agent]]-program(s) on mobile platforms
    *excellent architecture making extensibility very simple - [[Market Model]] separating [[ActionMarket]], [[ProcessorMarket]], [[SkinMarket]] and [[ParserMarket]] - each of which runs in strict [[Request and Offer form]].
    *excellent architecture making extensibility very simple - [[Market Model]] separating [[ActionMarket]], [[ProcessorMarket]], [[SkinMarket]] and [[ParserMarket]] - each of which runs in strict [[Request and Offer form]].
    *thanks to [[ParserMarket]], it's easy to write parsers to meet [[wikitext standard]] or read [[MediaWiki]] or [[TikiWiki]] formats
    *thanks to [[ParserMarket]], it's easy to write parsers to meet [[wikitext standard]] or read [[MediaWiki]] or [[TikiWiki]] formats
    Line 42: Line 74:
    *[[troll]] in the logo
    *[[troll]] in the logo
    *no need for *any* SQL - relies on [[Unix file system]] only - fewer glitches, fewer reports (most of which are turned off in the heavy-load wikis anyway)
    *no need for *any* SQL - relies on [[Unix file system]] only - fewer glitches, fewer reports (most of which are turned off in the heavy-load wikis anyway)
    *thanks to Python, easy [[mobile device code]] integration (11 lines of Python does what 1000 lines of C++ does, according to some [[mobile device vendor]]s)
    </td>
    </td>
    </tr>
    </tr>
    </table>
    </table>


    Dark horses include [[VeryQuickWiki]] (a [[Java wiki]]), [[UseMod]] (only advantage is that it dumps [[XML output]], very very very important until there is a real [[wikitext standard]]).   
    Dark horses include [[VeryQuickWiki]] (a [[Java wiki]] very easy to set up and run without problems), [[UseMod]] (only advantage is that it dumps [[XML output]], very very very important until there is a real [[wikitext standard]]), and [[Zope]] (also dumps XML, and is in use at other [[essential projects]] like [http://act.greenpeace.org ACT.Greenpeace.org]There is finally [[Drupal]] which has many advantages and includes XML output as well.


    Also [[Microsoft wiki]] will likely be out eventually, and some [[peer2peer]] options relying perhaps on [[XForms]] later.  [[Microsoft Internet Explorer XML Support]] is an important constraint on which of these features can be used at all.  It may be a wise tradeoff to support only MSIE for certain [[user role]]s, if these are ''always'' taken on by well-equipped well-supported people who can be far more easily supported by relying on IE's XML, than any other method.  By the same argument, if Opera or Netscape does something uniquely well and only two or three people need that capability, requiring those might also make sense for some roles.  For ordinary end users the [[APC Action Apps]] baseline browser capabilities should probably be adopted as Consumerium's own.
    Also [[Microsoft wiki]] will likely be out eventually, and some [[peer2peer]] options relying perhaps on [[XForms]] later.  [[Microsoft Internet Explorer XML Support]] is an important constraint on which of these features can be used at all.  It may be a wise tradeoff to support only MSIE for certain [[user role]]s, if these are ''always'' taken on by well-equipped well-supported people who can be far more easily supported by relying on IE's XML, than any other method.  By the same argument, if Opera or Netscape does something uniquely well and only two or three people need that capability, requiring those might also make sense for some roles.  For ordinary end users the [[APC Action Apps]] baseline browser capabilities should probably be adopted as Consumerium's own.
    Line 52: Line 86:
    ----
    ----
    '''See also:'''
    '''See also:'''
    *[[WikkiTikkiTavi]] -- http://tavi.sourceforge.net
    *[[TikiWiki]]
    *[[TikiWiki]]
    *[[Talk:MediaWiki modifications]]
    *[[Talk:MediaWiki modifications]]
    Line 57: Line 92:
    *[[Opinion Wiki]]
    *[[Opinion Wiki]]
    *[[The Consumerium Exchange]]
    *[[The Consumerium Exchange]]
    *[http://www.semioticpixels.com/cms/techmatrix.php detailed comparison of integration requirements of various LAMP CMS] including tikiwiki

    Latest revision as of 18:02, 16 August 2004

    Wiki code enables the Research Wiki and Publish Wiki. Choices we make about it will guide the Consumerium Software License and likely also the software development process - probably in ways we can't easily change or undo later. With so many alternate wiki implementations out there, it is important to sort through the advantages and disadvantages of each.

    This starts by considering the wikitext standard that our present text is in: Currently 3 out of 20 of our registered users are registered MediaWiki developers, which makes our percentage of developers among users 15%, which is likely the highest figure any public MediaWiki installation can boost so that is an good incentive to try to adapt MediaWiki for our use over other wikis. However they might just be here because we are using MediaWiki, so, it is important to make clear that one of the things the R&D Wiki is doing is choosing what technology best fits our hardware requirements later.

    Also, a good software development process requires shifting to a new development base when moving from R&D to production code - most studies show that it is very very bad to use the same platform and the same libraries, for instance, as one used in the R&D phase, in real production.

    So, there is ample reason to believe that we might move off MediaWiki later, or reserve it only for R&D use. There are three leading candidates, and a few dark horses listed afterwards. It seems likely that we'd ask those who want to be Consumerium developers to work on wikitext standards and on soliciting and forwarding end user feedback better, starting with our own MediaWiki modifications requests. Consumerium users should not have to do anything but list these here. Similar pages for TikiWiki modifications and MoinMoin extensions can be created, and which one meets our needs can be more of a competition. In most cases, the features that must be added are different for each package, since they start with different feature sets.

    Also APC Action Apps might become important to integrate, since they have broad use among nonprofits. One might for instance be written to support some common barcode readers, in cooperation with Adbusters or another of the essential projects which recognizes barcodes as being as critical as we think they are. Maximum cooperation and out-sourcing should be encouraged.


    MediaWikiGetWiki
    • Not humanly possible for end user feedback to reach developers reliably, though Meta-Wikipedia has some channels experienced trolls can exploit
    • PHP based
    • Proven to perform well under heavy load - but with hard limits
    • Only rational basis for wikitext standard given over one million articles in fifty languages
    • Working now for R&D purposes
    • Dedicated developers heavily involved in content problems, although they are in general Wikipedia content problems
    • Readable documentation, thanks to the above
    • supports MySQL only
    • already converted into the TomeRaider format for off-line browsing on many handheld devices

    GetWiki is a fork of MediaWiki under CC-nc-sa

    • same de facto wikitext standard
    • Auto-import of Wikipedia articles via XML using PHP's Expat Library
    • Well-formed XHTML, replacing deprecated HTML 4.0 versions
    • Improved use of CSS styles (colours, positioning)
    • Cleaner output to the browser, PHP code underneath
    • More integrated and effective use of CSS2, beyond font colours
    • More intuitive User Preferences page
    • Clearer labeling and checkbox placements
    • Fixed user login retention and other fixes
    • Better use of licensing notices on pages
    • Image thumbnail display
    TikiWikiMoinMoin

    Dark horses include VeryQuickWiki (a Java wiki very easy to set up and run without problems), UseMod (only advantage is that it dumps XML output, very very very important until there is a real wikitext standard), and Zope (also dumps XML, and is in use at other essential projects like ACT.Greenpeace.org. There is finally Drupal which has many advantages and includes XML output as well.

    Also Microsoft wiki will likely be out eventually, and some peer2peer options relying perhaps on XForms later. Microsoft Internet Explorer XML Support is an important constraint on which of these features can be used at all. It may be a wise tradeoff to support only MSIE for certain user roles, if these are always taken on by well-equipped well-supported people who can be far more easily supported by relying on IE's XML, than any other method. By the same argument, if Opera or Netscape does something uniquely well and only two or three people need that capability, requiring those might also make sense for some roles. For ordinary end users the APC Action Apps baseline browser capabilities should probably be adopted as Consumerium's own.


    See also: