What are your visions with the Wiki-system?#

There are many different ways to use the wiki-system, and this chaotic element of the wiki-system is actually one its main features. This page is meant as a place for wild ideas about what it must be possible to do with this wiki-system in the future, and what effects this might have on the concepts behind the wiki-philosophy. Maybe its time to make separate versions of the wiki, or to make different versions of it, that make different things possible.
Write down your wild vision of how you want this wiki to evolve, and how you want to use it in the future.

Contributions#

Local Wiki Used as Web Publishing Tool#

Here's a variation on the following. Our company allows employees to have access to web folders so that we may use them for file sharing. Html files, of course, are perfectly legitimate kinds of files that can be put in a web folder. This allows each employee to have their own mini web page. However, the current web authoring tools are not the most friendly for MereMortals. What if JSPWiki could be run locally and used to author an entire web site. We could then simply copy the content to the web folder. Basically, we are talking about an html export for a local wiki. The exported site would not function like a wiki. Instead it would look like a web page, have no access to previous versions, have no search, and have no access to edit capabilities. Are we anywhere near being able to do this? -- MatthewSimpson

Yes. See WikiRPCInterface and Hula. It should be quite easy to make a piece of software that grabs all of the rendered WikiPages using XML-RPC, and construct a web site out of them.

You could probably do it dynamically as well; just use OSCache to cache the HTML results for a while, and otherwise write a PHP, or Perl, or JSP page that fetches the contents from the Wiki.

-- JanneJalkanen

Local Wikis Integrated with Online Wikis#

Most people will not go through the hassle of installing a server on their local PCs. For the most part, this is the kind of thing required for running a wiki locally. There's only one exception to this I know, EddiesWiki a.k.a. WikiServer. When this thing runs, it launches its own server. Because it runs locally, it's great because you don't have to be online to use it. However, in no time, you realize that no one else can author material with you in it. It would be great if there was some kind of way to synchronize the local wiki with an online one. Plus, if you want to use the information in some kind of other format (e.g. Word or other RTF), you are kinda stuck. Online wikis suffer this latter limitation too.

So my vision of a wiki is one that can run locally and online, one which will synchronize the local and online edits... And one which will export into some alternative file format so that you can get your information out once you put it in. -- MatthewSimpson

You can use Wikiserver as a "public" wiki. It was the first wiki we used for team collaboration on our intranet.

Another "wiki-in-a-box" product is FitNesse. This product provides a sub-wiki capability and the ability to integrate wiki pages hosted locally on a machine with those on a server. -- PaulDownes

Actually, SnipSnap also contains its own server. For JSPWiki, there has been talk about making a StandaloneWiki, but we would need someone who would package JSPWiki with LiteWebServer. Also, the AntCvsFileProvider is a first step towards synchronizing servers. --JanneJalkanen

My Vision of a Wiki ...#

is structure. are people who create structute .. is content ...

and a discussion of the possibilities of a this wiki to create a structure.

Take a Hint from Wikipedia#

The way Wikipedia has a Discuss tab for every page is a good idea for hiding the messy details of pages that have content under dispute. Could that work without a human editor enforcing it?

--PaulBaclace

Radical Improvements for Small Group Communications #

Use of a wiki for rapidly changing content for a small group which has no dedicated human editor would be improved greatly by adding these features:

  • display list of users who viewed a page since the last edit
    • rationale: allows writers to know who is reading (the current alternatives are inaccurate and inefficient)
    • simple implementation: keep a view history tuple like {pageName, pageRevision, date, userId} ; possibly remove tuples when they get old.
    • only show the first 10 or 20 readers of a page.
  • display changebars (any kind of glyph clue) for each viewer to indicate what changed since the last time the page was viewed.
    • rationale: fast way to see what changed since last time a page was viewed (something people are not very good at doing).
    • simple implementation: keep a view history tuple like {pageName, pageRevision, date, userId} ; only need to keep the most recent pageName,userId combination.
    • could render this on demand as a what-is-new view of any page.

I set up JSPWiki for internal use at jaxtr.com right from the beginning, and that multi-year experience informed this suggestion. Both of these features use a common tuple and improve upon the wiki experience when a small (less than 20) group is involved. It would be cool if JSPWiki tried this first.

--PaulBaclace

Make wiki THE WAY of writing documents#

The normal way of writing documents today is by using a WYSIWYG editor No, it might be normal for you, but intelligent people use either a wiki or an intelligent textprocessor like LaTeX2e! that requires that the client runs on a rather big machine, and where the document is saved locally making it difficult to edit it remotely. The main advantages of using a wiki-alike system to make documents are:

  • The document can be edited from every machine that is online,
  • The document can be edited by different people,
  • The system has build in version control, so that older version can be restored,
  • ...

To make the wiki-system really good for document-editing it must be possible to:

  • Create a new document.
  • Edit the document parts (chapters) easily.
  • Print out an entire document including "Table of contents", chapters, index and bibliography.
  • Make access control for a document, so that the ideas presented in the document are not stolen.

All in all, this way of using the wiki-system is a long way from the total chaos that exists in normal wiki-systems, but technologically the number of new features are limited, so a version where this is possible could be made as a side project to this JSPWiki.

--Mortena


Please comment:

Project development documentation#

  • Specifications
  • Use Cases
  • User Stories
  • UML
  • Ongoing documentation (todo,issues,user testing...)
  • Javadoc
  • Scheduling, Project Management
  • Reports
  • Import/Export documents (word,xml)

The only thing thats really missing to use wiki for good project documentation is printing, can be implemented simply with print media style sheets or more advanced pdf generation.

Actually, WikiMarkup is sort of similar to good old TeX in many ways, so this idea is not really that far-fetched. Doing paper-publishable stuff may be a bit hard, though, since simple things like paging may be a bit difficult.

--JanneJalkanen

I've seen somewhere on these pages that a guy mentioned the docbook project, that combined with this wiki, could be what we are looking for. This could be accomplished by letting the wiki-engine spit out some XML-that can be translated with the docbook features. It probably requires that there must be added some new tags to the wiki-language, both that can be done.

The WYSIWYG could be implemented by making a XML-RPC interface, that is used by a stand-alone WYSIWYG editor client.
--Mortena

Alternatively, I think one could make a pretty decent WYSIWYG Wiki editor with Mozilla's XUL or perhaps XWT. That would remove one of the barriers to entry for using a Wiki. --MahlenMorris


Develop software by the use of a wiki-system#

Many of the features of a wiki-system makes it ideal as a software development tool:
  • more people can work on the same project,
  • errors (bugs) can easily be corrected by the end users,
  • its extremely easy to use, so the concept of Mob-development can actually be made possible.

Todays open-source projects are developed by very few volunteers, because the only way to contribute is through "difficult" systems like CVS, or like this project, through email-contributions. The chaos this would bring is maybe what is needed to bring the software development just a step forward. (See Feyerabend)

To implement this the following features must be added:

  • Possibility of correcting code,
  • Possibility of testing the implemented code.

I admit that this idea is way out, but just look at how fast and bugfree things like WikiPedia has been developed. Maybe the concepts of that can be used in software engineering to.
This idea has got its own page named Goofy.

--Mortena

Comments

I think that this is probably the wackiest idea anyone has yet given in this forum. I love it. Let's do it. :-)

What you basically need is a Wiki whose default mode is not to translate stuff that seems to be source code: For example, a page starting with a comment sign or an "import"-statement would not be translated; or better yet, all text between the { { {-signs would be considered code.

You would need a custom plugin, servlet, or a specific program that would compile and package your code when you click "save". You would need heavier concurrency control methods though...

Hm. I shall ponder on this... I have a small project brewing which we could try as a sample case.

--JanneJalkanen

This (everything between { { {) reminds me of ... argh, someone's documentation-as-code concept. In terms of object-oriented programming, a page would contain both the code and the documentation of a class. (Overlaps with e.g. JavaDoc, but then again, this doesn't need to be limited to a Java coding system - other developers might enjoy convenient documentation.=)

Separating code for compilation, source organization, project organization, versioning and tagging all need a bit of thought, since we don't have wiki subsections or file hierarchies now. Subsections is something we run into with Mortena's documentation system, too. Hm.. how about file hierarchies? They're pretty much necessary in a Java project.

Need to mull this more. I'm interesting in trying it out, definitely.

--ebu

I didn't think that the responses would be so positive and entusiastic. Thanks... Let's try to give this project its own page Goofy and see where we end up. --Mortena


I use Wiki as a personal knowledge base. I keep notes, journals, to-do lists, wish-lists, bookmarks, and plans for world domination in it. Because all my information is hyperlinked, I can easily create lists, and organize things as I please. Because there is no implied structure to the documents, I can easily organize and reorganize (or not organize) information as needs change. I got my inspiration for this idea from TheWikiWay by WardCunningham and BoLeuf. I used to use a program called PersonalBrain for this, but found it to be cumbersome and not easy to add notes to categories.

I hope to contribute code to make it possible to use the wiki in this capacity, while still allowing it to function according to the original wiki vision (collaboration).

--KenLiu
--- I've used jspwiki for more than 5 years everywhere. I've added about 10 existing plugins to the base product and find it can't be beat as a CMS, knowledge base and web-based workspace. Of the many plugins, the one I like for software development best is the Groovy plugin. Groovy and Grails are tremendous for dynamic Web application generation. I'm looking at integrating Grails, BIRT reporting dynamically into a version of jspwiki at some point. I need to use the right url model to make addressing work easily.
--jmason

Wiki as Database#

With the features proposed in the mentioned page, JspWiki would enable to build CRUD applications for simple models, like a Project Tracking Server, a Bug Database, a Student Grades System,...

The benefits would be integration of the Wiki ease-of-use and ubiquity in complex applications involving both document browsing and search/aggregation of data. Think of the "estimated completion percentage" or, more down-to-earth, the "estimated budget at completion", of a project. Think about the "average rating of this lesson". Think about the "Turnaround time for all bugs assigned to Janne"... All that available along with the usual "Specification", "RMI tutorial", "Bug XYZ" pages, from the same browser, in the same UI, with the same markup syntax...


RefactorMe From this point on, the rest seems to be a discussion on features rather than a vision of JspWiki application.

Knowledge cannot be Managed -- it grows and evolves. Wiki is the essence of this.

A great thing to do would be to make attachments accessable by WebDAV. That way when you post attachments you can edit them with Word (or whatever) easily later. This is just in recognition that there's a lot of Office documents out there and they contain information too - albeit imprisoned and confined in a proprietary file. This shouldn't be too hard since WebDAV is part of Tomcat...

--John O'Hara

Hm. WebDAV might be interesting, but I am trying to keep JSPWiki as container-agnostic as possible. Is there a proper standard that does not rely on a particular Tomcat API or something?

-- JanneJalkanen

Yep - the Apache Slide project has a pluggable WebDAV servlet for Java, there are others....

--John O'Hara

Just a thought: Is there any reason whatsoever why we couldn't make a WebDAV PageProvider? If JSPWiki got all its pages/attachments from WebDav, and anyone could also edit them through WebDav... This would fit in nicely with the current JSPWiki structure. It would also allow you to keep a remote repository, too, though you would probably need a local cache of sorts (but then again, we already have the CachingProvider). Problems solved? (Except for the fact that the ReferenceManager would still be confused, but that's a known problem and will be solved in the near future anyway).

-- JanneJalkanen, 23-Jun-2003

I think you are talking about two different things. John thinks about making JSPWiki a WebDAV-server, so to say making WebDAV an alternative API to XMLRPC. This way JSPWiki would still be in control of its content and could for example handle conflicting edits gracefully. There wouldn't be the inconsistencies you mention above. As a mere storage mechanism for pages it doesn't make that much sense to me, especially if you allow bypassing JSPWiki to modify content.

-- Torsten, 2003-07-09

Oh yes, kinda... My "leap of logic" was just a though on how to get WebDAV quickly integrated into JSPWiki.

You see, when JSPWiki functions as both a WebDAV server, AND has a WebDAV-compliant PageProvider, we can chain Wikis together, and form a collaborative WikiMetaSpace, where all pages belong to all wikis, and pages are nicely distributed around, and mumblemumblemumble...

-- JanneJalkanen, 09-Jul-2003

Hm, this is a very nice idea. But with Wikis acting as a WebDAV-server and using a WebDAV-PageProvider all pages would be stored on the machine(s) that use(s) a regular PageProvider. Though this is not a problem in itself, you get into trouble if any server along that chain becomes unavailable. A better way would be to have something like a ReplicationManager besides a normal PageProvider that could send changed pages to other servers or receive changes from other Wikis. There are probably lots of problems in such an effort, in fact we are trying to create some kind of distributed database and have to keep that in sync. So this WikiP2P or WikiMetaSpace how you called it is a lot of work with an open end. Another question is what would be the benefits of such a monster?

-- Torsten, 2003-07-09

Most Wikis I have used have problems with duplicate pages. Perhaps when you create a new page a box could come up with some simple check list of possible "snaps"? -- AndrewCates 13-5-04

-- JuhaPalomaki 2006-05-12

Wiki is a great thing because 1)because editing is simple 2)multiple people can edit same pages 3)stuff does not get lost since you have versioning. Current Wikis are not enough, since they concentrate just on text, but people need more. If you are doing software project, you don't want to write your class diagrams - you want to draw UML. If you are doing brainstorming, you might want to use a mindmapping tool. We need a nice clean way of integrating all this stuff to the Wiki model.

Simple attachments are not enough. Instead we need to have a model where the versioning system can be extended beyond simple text. For example I would like to have an applet version of ArgoUML (or similar tool) that is embedded on a wiki page, saves the UML model to the wiki and allows me see what changes others have made. A similar model would apply to the FreeMind mind mapping tool. All these use some sort of XML as their storage format. What would be needed is a "standard" storage API that would allow the applets (or Flash, or ...) to store the stuff to Wiki, access specific revisions and so on. - The next step would be to extend the storage model to allow real time collaboration between users. If two users had the same UML model open at the same time, they would immediately see the changes made and all this would go through Wiki.

This is not just about having external apps that use the Wiki as their storage. This is more like Microsoft's ideas, which allow you to do in-place editing of Visio pictures in Microsoft Word.

--DaveWolf 2007-04-12

I'd like to see

  1. Ratings of the users by their peers based upon the quality of the entries / comments added so that it would be easier to discern the geniuses from the idiots.
  2. More RSS functionality -- say the ability to subscribe to changes within a 'Category' of pages.

--

I see wiki as "model" which could be used to describe several kind of "aspects" concurrently. For example development effort purpose, let take some kind of requirement specification or regulation and copy paste it to properly named pages. Then we can add links to chapters referring else where in that doc (to complete cross referencing, and to increase understandability/readability).

Here it is great if !#1.2.3 paragraph syntax could be use to extend footnotes for local referencing capability (syntax sugar for ![1.2.3|#1.2.3] paragraph and ommit's annoying brackets at that context). Also named list items will be great *a) topic one to have *[a)|#1] topic one.

When analysis phase starts, domains substantives are marked as links and design notes/analysis observations could be recorded at those addressed pages.

Main idea is to use some page property style feature to annotate page like 'uml.analysis =class' and use special plugin to include class diagram drawing generated from those annotations to inline on wanted place. Also links should be annotated with classification of that relation, like [SpecialRegulation!uml.analysis#extends].

That way we can utilize JavaDoc style feature to describe structure of "thing" by it self's annotations, or ability to produce alternate "view"(s) from it's primary representation and embed them (see Doxygen with Dot, example kdevelop).

When comparing to approach of Makna as semantic web application, this vision have more limited use scope but instead allows user define/discover ontology, mainly because it probably isn't fully known before analysis ;) and describe it with UML formalization.

-- OlliKorhonen 2007-9-6

Mobile Wiki#

My vision is the mobilisation of wiki-pages to mobile devices. have you ever seen bLADE-Wiki? I use this on my PDA. It has an excellent performance and a nice synchronisation to an possible bLADE-instance on workstation or server. In my vision I can a) use this bLADE-wiki as mobile "offline-frontend" of a JspWiki-system or b) use an jspwiki-own (mobileJava?)-offline-client on my PDA. Authorization and change-synchronisation will be the best and also the most problematic issue of this topic. -- bZi 2008-11-30
See other existing an potential applications of JspWiki in Category Wiki Applications

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
jpg
Winter.jpg 105.5 kB 1 24-Feb-2006 09:23 62.159.193.155
« This page (revision-97) was last changed on 07-Jul-2011 17:56 by Jim Mason2