Prospects for a complex wiki
Let's face it: for most users in the world, the standard wiki is Mediawiki. That is not because Mediawiki is particularly superior, it is clearly because Wikipedia is the reference wiki in the world. Average webmasters today will install Mediawiki when they need a wiki, average users will think "this is not a wiki" when they don't see the default Wikipedia interface, and they will say it's wrong and boring to learn when it is not Mediawiki syntax.
It is important in the world of software not to be one year late. It doesn't make sense to compete with Mediawiki, and it doesn't make sense to propose Bitweaver as yet another wiki system. Bitweaver must find another share of the market, in assuming the role of a "complex wiki".
I am not particularly happy with the term "complex wiki", but I needed a phrase that was not "superior wiki", because having more features is not always a superiority, and plain wikis are superior when you want plain documents.
The first and foremost, most requested feature that a complex wiki must have is registered oriented publication. Indeed most plain wikis now offer user rights, but their whole architecture is still pervaded by the philosophy of total openness. I think that the sign that a system becomes a complex wiki is that the display to anonymous of who wrote what and when can be inhibited. More than a precise technological step, this sign marks a change of philosophy. Visitors who are not meant to participate must be relieved of such unnecessary information.
A second feature is the ability to link pages in structures and menus, content tables... Bitweaver is already well equipped with that, but this does not mean further improvements are not necessary. In order to be fully books, wiki books must be exportable, exchangeable and importable, in pdf and other formats. But the real change of philosophy will be marked by the possibility of adding bibliographical footnotes, just like in a word processor. Students must chose Bitweaver for their thesis.
The third feature that seems to me advisable is the ability to import chronological content into the wiki. What I mean by that is that so many cms publish articles and blogs easily, but more and more intelligent people are regretting that many posts of excellent and lastingly relevant content get lost in the archives. More and more people want websites for knowledge, and worthy knowledge doesn't lose its interest because new posts have been published. In that sense many people regret the old days of static html.
It makes little sense to just add packages to a wiki, if that means a mere juxtaposition of separated features. You might as well want to install specialized systems in subfolders, and specialist developpers of blogs, galleries... will always do better than you at blogs, galleries.... A wiki oriented system must find a way to orient the content... towards the wiki. This needs discussion for each type of content, of course.
Last, a "complex" wiki shouldn't compell the users to learn any wiki syntax at all, and the editor should be fully wysiwyg. That can be interpreted as a sign of inferiority by many programmers, because, precisely, their professional ability consists in writing code. But we are not talking about intellectually inferior users here, we are talking about content providers who are ophtalmologists, botanists, historians, geographers... who are all largely superior to programmers in their own fields, and who are legitimate in wanting to concentrate fully on content. Of course this will be a transgression for many programmers, but who will be ashamed of making a cms that scientific professions will like to use?
Here were my few ideas of the month for the future development of Bitweaver. I am not sure it is what the others want, but I am sure there is a market niche for it, and the market of average wikis is already taken.
It is important in the world of software not to be one year late. It doesn't make sense to compete with Mediawiki, and it doesn't make sense to propose Bitweaver as yet another wiki system. Bitweaver must find another share of the market, in assuming the role of a "complex wiki".
I am not particularly happy with the term "complex wiki", but I needed a phrase that was not "superior wiki", because having more features is not always a superiority, and plain wikis are superior when you want plain documents.
The first and foremost, most requested feature that a complex wiki must have is registered oriented publication. Indeed most plain wikis now offer user rights, but their whole architecture is still pervaded by the philosophy of total openness. I think that the sign that a system becomes a complex wiki is that the display to anonymous of who wrote what and when can be inhibited. More than a precise technological step, this sign marks a change of philosophy. Visitors who are not meant to participate must be relieved of such unnecessary information.
A second feature is the ability to link pages in structures and menus, content tables... Bitweaver is already well equipped with that, but this does not mean further improvements are not necessary. In order to be fully books, wiki books must be exportable, exchangeable and importable, in pdf and other formats. But the real change of philosophy will be marked by the possibility of adding bibliographical footnotes, just like in a word processor. Students must chose Bitweaver for their thesis.
The third feature that seems to me advisable is the ability to import chronological content into the wiki. What I mean by that is that so many cms publish articles and blogs easily, but more and more intelligent people are regretting that many posts of excellent and lastingly relevant content get lost in the archives. More and more people want websites for knowledge, and worthy knowledge doesn't lose its interest because new posts have been published. In that sense many people regret the old days of static html.
It makes little sense to just add packages to a wiki, if that means a mere juxtaposition of separated features. You might as well want to install specialized systems in subfolders, and specialist developpers of blogs, galleries... will always do better than you at blogs, galleries.... A wiki oriented system must find a way to orient the content... towards the wiki. This needs discussion for each type of content, of course.
Last, a "complex" wiki shouldn't compell the users to learn any wiki syntax at all, and the editor should be fully wysiwyg. That can be interpreted as a sign of inferiority by many programmers, because, precisely, their professional ability consists in writing code. But we are not talking about intellectually inferior users here, we are talking about content providers who are ophtalmologists, botanists, historians, geographers... who are all largely superior to programmers in their own fields, and who are legitimate in wanting to concentrate fully on content. Of course this will be a transgression for many programmers, but who will be ashamed of making a cms that scientific professions will like to use?
Here were my few ideas of the month for the future development of Bitweaver. I am not sure it is what the others want, but I am sure there is a market niche for it, and the market of average wikis is already taken.