views:

371

answers:

12

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?

+2  A: 

I'm personally already tired of wikis. Wiki as a software is out-dated, now it's about wiki as a feature (like my favourite new website, stack overflow d-:)

elliottcable
A: 

My mistake I seemed to have forgotten to ask what other cool uses could wikis have ? In the end most wikis ( the software ) are just a rich text editor or text area which you type markup etc into followed by a translation step into HTML. Most wikis are standalone and don't attempt to integrate with other stuff but remain isolated - how else can the wiki idea be used ???

mP
This should be edited into the original question.
Michael Paulukonis
A: 

The wiki-of-the-future will be completely editable online, concurrently by everyone. Check out EtherPad for a demo of the techonology.

Avi
I guess EtherPad is a step forward and I can see collaborative / simultaneous editing to be valuable for small and large teams / communities. However other than concurrent editing it dies not have much else that's new... What other new ideas are there ?
mP
+1  A: 

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).

Michael Paulukonis
I guess this a step in the direction I thought might appear but is a bit high level - details , details !
mP
+1  A: 

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.

Uri
A: 

thanks for the replies so far ... However noone has actually mentioned with some detail ( features, why it's better than the status quo ) some real new ideas ...! It would be great to have something between a birds eye view and talking code...

mP
Stack Overflow is not a forum. Don't post an answer. Comment on the answer beneath it (using the 'add comment' feature). If you want to add to your question, click 'edit' right under your question.
George Stocker
A: 

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.

Wickethewok
+1  A: 

"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.

Eaton
I included web 2.0 more or less to mean a richer experience fir the end user , broadly ( badly ) categorizing current wikis as web 1.0 in that they are more like forms in a web page being editted rather than an application. Mediawiki is more webpagy than "app" IMHO...
mP
+4  A: 

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.

tims
Thanx for the reply and your ideas... do you have any other of your own ideas - be creative !
mP
Some of these ideas are implemented in XWiki (http://enterprise.xwiki.org/xwiki/bin/view/Main/)
DR
A: 

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
PaulHurleyuk
+1  A: 

Extensibility.

Check out DekiWiki, they are doing an excellent job with this.

DekiWiki extensions

pc1oad1etter
+2  A: 

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.

Gullbyrd