Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When designing a wiki application, what things should I take into consideration?
So far I have:
revisions
parsing some sort of markup text
keeping track of links in wikis, and pages that link to other pages.
related wikis i.e. wikis are related to others.
What else goes into building a Wiki?
If it's helpful, here is the database schema for Wikipedia (actually MediaWiki, the engine behind Wikipedia):
http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png?
I have done a lot of research and work with wikis over the last several years, for my own use and to support technical teams for my various clients/employers.
I have concluded that the most important criteria for a wiki is to make it transparent, like the original wiki at http://c2.com/. It should be so easy to contribute that the user never questions whether they should bother to do so. The editor must be easily accessible, it should use a conventional text-only (NO WYSIWYG!!!) wiki format, it should be easy to add new pages, it should be easy to link to external pages (other wiki or regular web), and it should have backlinks. Imitate the original wiki, and you will be fine.
If a user ever questions whether they should bother to contribute because it is too painful, in one way or another, then the wiki will stall and fail. I have seen it happen over and over again. WYSIWYG is one common failure mode, mixing in "rich" content like lots of files, multimedia, etc., is another, not being able to backup/restore is a big one. If you want "fancy" content, use a standard web server hosted "nearby", to which wiki users can link. Remember, wiki is about communication, it is NOT about pretty.
Have a look at TiddlyWiki. I think it has the best combination of features I've seen in any wiki. (For "pages" below, read "items" since TiddlyWiki is a single-page wiki. But I think these features should apply to wikis with pages too):
List of all "missing" pages (WikiWords with no page)
List of orphaned pages (pages with no links to them)
Most formatting is done by editing wiki pages
You can't screw up formatting, because there's a default if you delete your custom formatting
You can tag pages
You can include a page in another page
And plenty more that I haven't mentioned. I think the formatting is possibly the best of many good features, because it's so easy to edit and so hard to screw up.
Often overlooked:
Good search
Hierarchies. One of the things I miss most in Redmine's wiki.
If you find a good way to implement a wiki that is easy to reorganize, that would also be great (i.e. rename a page, or join two pages into one and don't break a zillion wiki links).
User interface -- one of the most frustrating things for users is that they have to learn one user interface for MediaWiki, one for TikiWiki, and one for any of the other myriad of wiki's out there.
The most important part of wikis is not the technical feasibility -- it's getting users to contribute and edit in a convenient and effective way. You can have the most technically robust wiki in the world, but if it's not easy to use, it will be useless as the community tool that a wiki is supposed to be.
Either copy an existing and familiar wiki syntax (such as MediaWiki), or be prepared to invest heavily in creating a WYSIWYG editor.
I wouldn't start a new wiki engine with the same features that everybody has, there are so many of them out there.
I would only work on one that offers something different/unique, much more than a standard wiki.
Some ideas include (maybe some wikis already have this):
The ability to have the wiki merged with a VCS, to discuss revisions/changes and be able to do code reviews (anything that gets committed automatically creates a page for the revision), having it linked to the committer and anybody in the discussion and sending them email alerts would be nice.
An API for the wiki that allows 3rd party application to do mashup-style integration.
wiki-style multimedia (Text, Images, Audio, and Video) that contains links to other media.
multilingual side-by side editing and translation.
a client-side editor/viewer (not web based) for faster response and real WYSIWYG editing.
...
Make sure you nail Ward Cunningham's original Wiki Design Principles.
Make sure you perform input validation on all the edits people make to prevent XSS. Nothing would ruin a good wiki like people getting hacked.
Every time I've tried to get non-developers to use a wiki, the difficulty of writing text has been the biggest barrier. A WYSIWYG editor along the lines of what StackOverflow has seems like a great idea to me. It still shows the markup in the box, so motivated users will eventually learn to use it (thus becoming more efficient), but it also shows a live preview, so that users get instant feedback as to whether their text looks correct.
Along these same lines, another annoyance is that every wiki seems to use slightly different markup. I guess each designer thinks they can do it better than the ones before. I would suggest using either MediaWiki's syntax, or something like MarkDown that's sort of standard, so that power users will have an easier time of things.
Finally, consider what about your wiki will set it apart from the many many many many other wikis already out there, and how your design will impact this.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Oh, Collective Wisdom of the Crowd,
I've been handed the Task. My inclination is to go code but as I'm old and weary I'm aware of my total ignorance in Web coding, as well as my tendency to code instead of using off-the-shelf parts (a.k.a. NIH) and the similarity of the Task to the problems solves with Wikis and Content Management Systems. So, my question is: Solve the Task using a Wiki, A Content Management System or roll my own site?
The Task:
I've videoed a three-days sports event of my Ninjutsu club, and have created a set of three DVDs, containing many "chapters". Most chapters consist of an explanation and demonstration of a technique, followed by the instructor moving around and correcting people.
The big Honcho would like some of the senior students to review the DVDs prior to production.
One way would be to reproduce a few sets of the DVDs, mail said students, and have them e-mail me their comments. This, however, is low tech, not sexy, and I'm sure would not generate the desired involvement.
As an alternative I thought about creating a web site for this purpose, with the added value that the web site would later, upon release, serve as a companion to the DVD. First-draft requirements appear to be:
Allow each reviewer to pick up the part of the material he’s "the owner of" (i.e. responsible for).
Provide a web page for each DVD chapter, together with a navigation system.
Upon creation each page will contain and embedded video of that chapter.
Allow each owner to mark her sections as “OK”, “With Issues” or “Remove”.
Direct reviewers to pages with sections having problems, or not-yet-reviewed, or with high activity (i.e. interesting).
Allow reviewers to collectively document the techniques demonstrated in the video sequences, especially during the corrections when the instructor can’t be clearly heard as the speakers are turned off. Upond release this documentation will be "frozen" and provide additional insight into the technique, in addition to what was provided in the event.
Generate the basis for sub-titles.
In addition to above documentation, each such page will also contain discussions between the reviewers concerning the technique. These discussions will be visible on the page, below the video and the documentation, unlike Wikipedia where the discussions appear on different tabs.
When documenting the techniques, the instructors will be able to create and use a collection of terms – names for the techniques. These names will be collected into a central ontology, together with their translation, and will later be used to index the content.
Hebrew support of the content is mandatory
The site will have the ability to contain translated versions of the content where the
user can choose the language she will use. So after release a Spanish speaking student who have purchased the DVD and gone to the site would be able to look at a Spanish translation of the documentation.
I know, I know this is a tall order and I'm only an egg :(
Stick with the email for the review; ninjas <3 email. Enforce participation through intimidation. Focus on shortening the time-to-release, IMO.
Use the time to figure out if creating an online back-end is worth it for the release--even a good martial arts video doesn't sell a lot of copies; if you're not Hatsumi or Hayes, even less.
It looks like the biggest requirement is I18N and comments.
I'd go with a Wiki; its collaborative model of content creation is perfect for things like this, and many support translations--although keeping up with the translating can be problematic. Wiki gardening is time-consuming and non-trivial, adding a layer of translation...
Although it'd give a whole new meaning to ninja edits.
Potential revenue or the emotional investment will dictate the scope of the project, but here's a couple of ideas to consider:
Ticketing system to allocate the work to users, track progress, define state of completion. I recommend the open source Request Tracker. This would be the easier option to implement in terms of management of the project, but doesn't touch on the l18n or the web development.
OR
A Component Content Management System to act as database and publishing tool. I would suggest the open source Pressgang CCMS. This would take more effort to implement but offers the features of Request Tracker with the addition of publishing output functionality (especially in terms of the use of DocBook XML and Publican). It is also built to work with the open source translation tool Zanata.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I'm pretty handy with django and python but I'm terrible at the "visual" aspect of the web-design. Even after quite a bit of google-ing I haven't been able to find any sort of resource that has download-able templates complete with css, images, etc. that could be used to set up a basic website easily.
I'm looking for examples beyond the 5-line examples that you find in most tutorials ... I'm looking for something with the general nav-bar across the top, various content-blocks to over-ride through subclassing, footers, etc.
I've worked with others on django projects but always on the "coding side". I want to do my own project. I've set up all of the views, models, "business logic", I just cant get off the ground with the design section.
Any help would be appreciated.
Edit: Just to be a little more clear. I'm looking for designs (open licensed) ... akin to Wordpress themes. If you have a resource of just themes I can probably mung them into a django template but if you know of something that already provides them as templates I'd prefer that.
I've had some luck in the past with sites like OpenDesigns and FreeCSSTemplates -- they offer (mostly) CC-licensed HTML templates; you'll have to add the Django template stuff yourself. As James pointed out though, most of them will get you up and running, but you almost always want to take things a step further.
My advice: build up a small library of re-usable templates (using stuff from the above sites), get real comfortable editing HTML and CSS (because you will edit HTML and CSS), then find some kickass designers (preferably local) and get real friendly with them. Perhaps you can trade favors; you do some coding work for them, for free, and in return they do some design work for you. I've found that even if you have to pay, a good designer is well worth the money (seriously, who wants to spend their time testing sites in IE6?).
Good luck with your search though -- I, for one, would love to see your findings.
It seems like this is an area that is completely lacking. I've been looking for a django project, perhaps a meta-django project is a good way to go ;).
Maybe if designers could upload a set of templates against a simple and well defined set of models. They could upload a "main.html", "object_list.html", "object_detail.html", a css file and a few images. This would be something akin to the CSS Zen Garden project.
I've setup a github repository here: http://github.com/JudoWill/DjangoTemplateRepository. Feel free to log into the project and modify the wiki with requests.
The idea being to give newbies a starting point and a few examples for making their django website.
I suspect this has got nothing to do with django templates, your question sounds more of a design and markup. There are couple of css framework like Blueprint, 960, YAML.
I don't think you're going to be able to find what you're looking for unfortunately - I have the same problem.
Wordpress templates can assume a fairly well-known data model - every Wordpress installation uses the same predictable table names, every (say) blog page has a well-defined set of data that will be passed to the template - and even the plugins have only a limited number of plugin points to add extra data.
By contrast, your Django app could contain anything. I could provide you a pretty template, but unless the data I use in the template exactly matches your data model, it's not going to be useful. I could make the template very very generic - eg, just have it display the variable called 'form' if it's present, iterate over 'messages' if any are present at the top of the page, display a 'footer' at the bottom etc - but it will take you about 20 seconds before you want to customise the display of that form, and then you're back editing your own templates.
I think that the closest thing you're going to find are UI libraries like jQuery or YUI which can handle a lot of the work of making your UI look snazzy.
I'd like to be proven wrong though, it would save me going through the same trial as you're going through now.
Update: On re-reading this, it occurred to me that you're looking for a CMS, which Django is not. Two seconds of work with Google revealed django CMS. I haven't tried it, but maybe that's closer to what you're looking for? The django wiki has a comparison table of various django-based CMS solutions
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
We're thinking of moving from our existing installation of MediaWiki to something more feature-rich. I'm trying to find all the pains people have with MediaWiki today (mainly it's poor handling of external documents and less-than-perfect editing capabilities - compared to Word).
We are using a wiki for design, spec, process guidelines. We have several external documents (docs, powerpoints) that we are currently putting on a shared folder and linking to from the wiki (because uploading files is not very convenient in MediaWiki).
We are trying to make the friction minimum, so that nobody will have an excuse or reason for not using it.
Some options we're considering are Confluence, Trac & Sharepoint. Money is not a big concern, only ease of use (and maintenance) and feature-fullness. What would you use?
I would plug the details of my specific feature needs into the excellent WikiMatrix choice wizard and let it make recommendations.
I would advise either
Foswiki ( http://foswiki.org ), (forked by the whole developer community of TWiki to avoid trademark threats), for a feature-rich and fully open programmer's wiki. Drop on #foswiki on irc.freenode.net to chat with the community.
Mindtouch's Deki Wiki ( http://www.mindtouch.com/ ) clearly the most user-friendly advanced and innovative wiki out there, a modern commercial + open source offering. Great integration with Office docs.
I would avoid Confluence. Confluence made a design choice (forbidding mixing html in pages with Wiki syntax) that proves deadly to any attempt at wysiwyg, as it uses a standard HTML editor for WYSIWYG, and this converts it on save in a very limited subset of it, yielding frustrating surprises for the users (foswiki for instance keeps as html the parts the wiki syntax do not handle like bullet lists in table cells). Confluence have many great sides, notably its integration with atlassian great tools as their JIRA bugtracker, (we use it at work for this with good results) but do not plan to customize it.
There are many good choices on hosted wikis too (Google sites, based on the awesome jotspot engine is one).
Never use Sharepoint of course. Its wiki capabilities are a IE-only joke, and Sharepoint whole architecture is braindead (storing all data - even huge docs - in a non-distributed database goes against Microsoft own recommendations). If you want a DMS with good Office integration, have a look at KT (Knowledge Tree) instead. http://www.knowledgetree.com/ . For political reasons we were forced to use Sharepoint at work but we limited it to basic document managing (never use the MOSS higher layer, as it breaks compatibility between versions) and integrated a foswiki frontend to it (dumped document list & metadata in xml and provided navigation in foswiki, and search with a google box)
But my real advice would be to ... wait for Google wave, that promises to revolutionize the wiki concepts.
Disclaimer: I am part of the foswiki community.
Before you move away from Mediawiki I would urge you to consider the many extensions available. IMO there arent many wikis that offer more features that MW, especially when you consider the number of extensions. See http://www.mediawiki.org/wiki/Category:Extensions
For example, for editing there are browser based editors similar to Word. And there even macros for Word that allow you to export from MS Word to your Wiki, from within Word.
Also, check out the Semantic Mediawiki extensions. These give enormousness benefits in the area of Knowledge Management.
I would personally recommend against moving from Wiki to SharePoint. The huge problem there is SP's dreadful handling of images.
First of all I would stay away from Sharepoint. Period.
I would not consider switching to Trac either, since Trac has special focus on issue tracking, and poor support for external documents.
I would consider switching to Confluence, since:
Money is not an issue (as you said)
You want to minimise maintanance work (as you said)
You want to use wiki to handle external documents (as you said)
I'm typically a strong advocate of open source technology, but with the requirements you gave, I just don't think they would make you happy. For instance if you had personnel available for maintaining and providing customisations to your system, I would definitely suggest trying out Foswiki, which also would otherwise fit your needs very nicely. However, if you really want to stay away from any extra maintance work, Foswiki is not a good option.
I work on Tiki Wiki CMS Groupware and I'll share a few links. This question comes up quite a bit so we have a dedicated page: http://tiki.org/Tiki+vs+MediaWiki
We're thinking of moving from our existing installation of MediaWiki
Tiki & MediaWiki are both PHP/MySQL so you can use the same server.
Tiki has a built-in importer: http://doc.tiki.org/MediaWiki+importer
to something more feature-rich.
Tiki is the http://tiki.org/FOSS+Web+Application+with+the+most+built-in+features
We are using a wiki for design, spec, process guidelines. We have several external documents (docs, powerpoints) that we are currently putting on a shared folder and linking to from the wiki (because uploading files is not very convenient in MediaWiki). We are trying to make the friction minimum, so that nobody will have an excuse or reason for not using it.
http://doc.tiki.org/WYSIWYG
http://doc.tiki.org/File+Gallery (instead of your shared folder)
http://doc.tiki.org/Docs (web-based ODFs)
http://doc.tiki.org/Spreadsheet (web-based)
http://doc.tiki.org/Slideshow (web-based)
http://doc.tiki.org/Draw (web-based)
Some options we're considering are Confluence, Trac & Sharepoint. Money is not a big concern, only ease of use (and maintenance) and feature-fullness. What would you use?
Tiki is Free/Open Source. But if you have money burning your pockets :-)
http://tiki.org/Donation
You can also hire a consultant to provide training/support and to accelerate the implementation and/or sponsor feature development
http://info.tiki.org/Consultants
Have you considered sharing your Word documents with Google Docs? It has revision control and collaboration features like a wiki, as well as a rich text editor that can import and export plenty of formats.
It sounds like TWiki would be a great option for you as well. I haven't used it myself, but it also has a rich text editor, as well as tons of enterprisey project management features in it.
A lot of people seem to like Confluence. I personally don't know it. If you are not already at it and you want something feature-rich than xwiki could be something for you.
I'd add FCK Editor for WYSIWYG, get a decent document management system to run alongside the wiki and carry on with MediaWiki!
Currently our team is using MoinMoin as a wiki for IT and it's so nice.
We want to promote to use wiki for end-users because some of them are interested. On the wiki we'll share and edit requirements of aplications, for instance.
I think MoinMoin is not the more user-friendy (but I love to use it) that's why we are looking for the best user-friendly wiki for end-users/customers
For yourself MoinMoin is obviously user friendly. =) Seriously, consider all users and try to figure what kinds of usage patterns you have. MoinMoin is a reasonable choice since it's such a simple program. You can often help your non-programmer users by adding a feature or two to MoinMoin. Developers are up to speed with it and you have all the content there already.
That said. Mediawiki is used for lots of general wikis out there today. Including Wikipedia. An aspect of user friendliness is recognition. Mediawiki might feel more friendly because users are more familiar with how it works. And Mediawiki is widely adapted. Lots of extra features you might want to add to help your users are already written as extensions. And Mediawiki's extensions API is really good so you can easily automate your own verticals when the need arises. Mediawiki is reasonably feature rich without being totalluy overloaded. It has categories and templates which both come in handy for keeping things DRY and using the wiki in various processes. It shares lots of its syntax with MoinMoin since both have the same ancestor (syntax-wise).
I'd probably go with Mediawiki.
Visit Wikimatrix.org to determine what features you need and what tool is best for you. I often mention Foswiki.org as a very nice and userfriendly tool, but it really depends on the features that you need.
I have yet to see any Wiki that is more end-user friendly than Confluence.
Just the most important reasons:
While other Wikis say they have WYSIWYG editors, what they actually do is enclose selected text with markup when clicking an icon. That is not WYSIWYG, that's code injection! In Confluence 5 all editing is done from a visual editor (you actually DO see what you get right away straight within the editor). With the ability to add macros (markup) by powerusers.
In almost all other wikis the users are entirely responsible for creating and maintaining the link hierarchy. This means broken links and orphaned pages will be the norm. In Confluence all pages are automatically added to a page hierarchy and sorted by name. You can enable the tree browser via the Documentation theme to make browsing the wiki even without manually added links convenient. Lastly you have the ability to reorder pages in any order via drag & drop.
However, Confluence is rather costly for > 10 users. But well worth it if you can afford it, or you don't need more than 10 editors. Pure "readers" do not count towards users if anonymous viewing is enabled.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What features should "Tomorrow's" wikis include? How might they incorporate Web 2.0 features like AJAX? What other features are they currently missing? What do you want to see from the next release of your favorite Wiki?
Edit: How might a Wiki be integrated into other products? What "neat uses" could wikis have?
Preview-as-you-type works very nicely indeed here on Stack Overflow. Many wikis don't do that.
Make it really easy to link between pages, eg. that, as you type, the wiki finds likely pages you may be referring to. That way you can make links without having to know the exact title of a target page, and bouncing on the shift key to WriteInCamelCase, or throwing in square brackets. Make it very easy to link to other websites outside the wiki, too (and by "easy" I do not mean like wikisisters, which, if I remember correctly, is like foowiki:ALinkLikeThis).
Similarly, if you can generate links within text automatically, you could, for example, have a mail system that wikifies your email. You create a wiki page, say, for Joel Spolsky, and references to Joel emails in your inbox become links to that page, which you can find by clicking "what links here". (This probably needs something along the lines of Bayesian filtering to prune the stray references to other Joels... your Bayesian Classifier learns that if the context is smart and getting things done, it's Spolsky. If it's flying Viking kittens, it's morely likely Joel Veich).
A variety of RSS feeds for tracking changes would nice, too. (Diffs, full text, changes on pages I've edited, ...)
Wikipedia has grown a fairly colossal categorisation system ("Fictional Cats", anyone?); laying a taxonomy over a wiki's flat namespace could provide another way for users to find their way around. Wikipedia's doing this a little, but in fairly limited ways so far: there are links to the relevant category lists, but you can't, for example, look for a composer called "Smith".
Similarly, wikis give you this big graph of interconnected nodes, of how closely your community sees the relevant concepts as being. Is that interesting? Is that useful? Does anyone who isn't google want to think about this stuff?
PS. If you believe Paul Graham's definition of Web 2.0 as "Democracy, Don't Maltreat Users, and Javascript works now", wikis are two thirds Web 2.0 already.
I am personally already tired of wikis. Wiki as a software is outdated, now it is about wiki as a feature (like my favorite new website, stack overflow).
The main advantage of community wiki — more editing — came into existence when we introduced "Suggested Edits".
With "Suggested Edits", anyone, even an anonymous user, can edit anything — so long as another experienced user reviews and approves their edit.
I'm in the process of choosing a wiki tool, and have looked at numerous packages over the past week. I'm sure there are dozens I haven't even heard of yet, probably good ones. But in general, here's my "beginner's mind" take on the problem.
Wiki markup should be abandoned. A wiki that is limited to wiki markup will only be useful to 'nix hacks and others who get excited about doing things the hard way and insisting that everybody else is stupid. I mean, Morse code is fine with me personally; I don't get what was wrong with a nice, clean dash-dot-dash. Or smoke signals, they were nice, except for the carbon footprint. But times change, and we have to change with them.
Real users (business users, customers, clients) want rich text editing. Period. And when a wiki tries to support both rich text and wiki markup, the results are not pretty. The model is confusing and (apparently) difficult to implement. The fckeditor extension at wikiwiki is a nightmare, for example. It's just not worth it.
Wikis need better access control. The idea that all content should be open to everyone is fine for an open, public, non-profit wiki like this one. But in the business world, that's not how it works. Restricting access is not evil, it's reality. Wiki tools need to do a much better job of providing access control: access to pages and groups of pages based on role or group membership, where groups can be formed by anyone on an ad hoc basis and users can belong to multiple groups and pages can be accessible to multiple groups, at the whim of the page's creator.
Those are the two things that I want, above all else, and I haven't found it in open source, at least not out of the box. Which, of course, is why open source is open source.
There's been some interesting work using wikis for testing and software development. EG, movement towards literate programming -- allowing pages to exist as both code and documentation that is compiled down into one or the other (or, I suppose, both simultaneously).
They have a regular session about this at the annual WikiSym conference.
I think one direction of Wikis is going from open ended collections of documents to an "everyone can edit but with more structure" applications like SO.
Another direction that I've seen is more direct integration with other project support tools, so project planning, issue management, and all that stuff.
Personally, I think the next big direction is going to be some sort of multimedia based Wiki, not just a Wiki where multimedia can be embedded in the text.
I really like MediaWiki. It's widely used and free/Free. The markup syntax is straightforward and allows you to do enough basic styling that you don't need to use custom HTML or to use a WYSIWYG. I assume by "sexy web 2.0" you mean Flash/AJAX, but I like MediaWiki because it works cleanly with basic HTML/Javascript (you don't have to wait for custom widgets to load, etc...).
What makes wikis reach their potential of usefulness is the community that develops around them more than the software itself. You need to find a niche where people are both passionate about (but not criminally insane about) the central topic and have enough technical prowess to log on to a website and edit some text.
"Wiki" is ultimately just a pattern:
Open editing by all/most visitors
Integrated revision tracking and rollback to reduce the cost of mistakes
Simple syntax for cross-linking between articles, and auto-creation of stub articles when referenced
That's not a perfect description, but it's a combination that isn't particularly magic. Successful wikis combine those things with a critical mass of people creating and maintaining content.
The next step, IMO, is less about web 2.0 shininess and more about the integration of better structural information. Adding any metadata beyond "this points to that" is an exercise in brute force hand-markup. Maybe microformats? Maybe the development of more structured knowledgebase software that uses wiki-ish editing UI but a smarter backend? I'm not sure, but I think better handling of the structured data is really the next wave.
Extensibility.
Check out DekiWiki, they are doing an excellent job with this.
DekiWiki extensions
The wiki-of-the-future will be completely editable online, concurrently by everyone. Check out EtherPad for a demo of the techonology.
For me, in terms of Enterprise style uses for a wiki, I have a couple of thoughts;
An effective way to keep and synchronise a central, web based wiki with multiple, offline, desktop style wiki's for people on the go
To move towards wiki as a function as opposed to wiki as a system, so we can integrate the wiki collaborative system into other things