Recommend a note taking wiki-like "super" application [closed] - wiki

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I need a note taking wiki-like "super" application. I'll start with a rundown of applications that I've already evaluated and/or used:
Wikidpad
Pros:
fast switching between the edit and view modes;
nice syntax (especially for pasting code snippets or just raw ASCII text, nice indenting visual clues);
it is standalone application that don't require server;
the wiki pages can be kept in flat text database;
easy drag-and-drop of file attachments (especially for image files).
Cons:
doesn't have history/version control of the pages and the state of the wiki database as a whole;
doesn't have the concept of namespaces for the wiki pages;
MoinMoin wiki
Pros:
nice syntax;
have standalone server (Python based) which makes it truly portable and standalone;
keeps the pages in flat files;
have a lots of nice plugins;
Cons:
its a wiki == slow iterations of editing/taking notes, viewing, rince-repeat...
doesn't have version control integration
Trac
Pros:
All of the features of the MoinMoin wiki, except the flat file database;
Version control integration: I can use the wiki changeset feature and the wiki pages as metadata of my personal codebase;
Cons:
All of the general drawbacks of the wikis;
Not truly portable;
todolist2 (by AbstractSpoon)
Pros:
fast, standalone todolist manager;
the tasks have this really nice and important for me feature of having an rich edit box for taking notes associated with the task with flipping between the task and the notes with a single key;
time tracking for the tasks;
Cons:
doesn't have version control built-in (it has "simple" version control by just making an automatic backup copies of the project/data file with time stamp embedded in its name).
it's hard to filter the tasks by urgency (in the GTD terms, it doesn't have the concept of the containers of tasks: Inbox, Maybe, Next action for each project, etc).
it doesn't have cross-referencing/linking between the tasks in wiki-like fashion.
Thinking Rock
Pros:
implements GTD almost perfectly;
it has notes for every action;
portable;
Cons:
(Maybe because of the Java GUI) doesn't have simple Undo when editing text notes;
it's clunky when switching between the projects/actions tree and the editable notes editbox;
doesn't have version control;
MonkeyGTD/TiddlyWiki
Pros:
truly standalone
almost 100% wiki
nice GTD implementation
Cons:
it's little confusing when there is no easy or user-friendly way to see an overview of the current structure of the wiki pages
I'm not sure if it scales well when there is a lots of pages/data/text/attachments.
doesn't have source control integration;
I'm not sure about version control/pages history...
I want an application that has the following:
the speed and the ease of edit/preview iteration cycle of wikidpad.
the wiki pages and the associated attachments as they are (like wikidpad and MoinMoin).
version control for the wiki pages (like MoinMoin or Trac).
source control integration (like Trac).
time tracking like todolist2 and the task/project nesting like todolist2 and ThinkingRock.
the almost perfect GTD implementation of ThinkingRock or MonkeyGTD.
It's obvious that I haven't decided which one to use because for some reason my requirements are somehow orthogonal in the terms of the features that the aforementioned applications provide... not that the features are orthogonal or it is impossible or impractical... actually, I think that maybe wikidpad is the closest to my ideal, which means that I could:
implement the features that I need (to add version control, GTD-life features/properties for the wiki pages themselves, source control integration), or
continue to search and evaluate, or
get some interesting and valuable opinions here.

Try ConnectedText: http://www.connectedtext.com/

ConnectedText has all the pros of Wikidpad and none of the cons. ConnectedText has a much superior query engine and contains semantic extensions not available in Wikidpad, and is much more stable.

Try KNote http://www.smartgoldfish.com/download.html.

I'm not sure you'll be able to find any application that meets all your requirements, but here is my shameless plug for a note-taking desktop application for Windows that works like a personal wiki:
- http://www.ppcsoft.com/blog/personal-wiki.asp
If you specify which feature(s) that is most important it is easier to tell which is more suitable ?
Any of the tools that save files as text can be added to your own version control system (which is better than using each tools' version control) that you could use for all your important documents.

Related

Use a html renderer in an embedded environment [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm working on a project where I will design a GUI for an embedded device and would love to go with HTML for this. I hope you guys can help me find a render engine that suits my needs.
Requirements:
The web-page must be rendered into a memory buffer. I will then transfer the memory buffer to the display.
I must be notified though callback or event that the render engine need to fetch a new item. HTML page, image, etc. The reason for this is that I must fetch the resource and feed it to the render engine (the reason is that the device does not have TCP/IP in all configurations and will then need to fetch the item over serial line, and also for security I need to validate that the request is allowed).
I must be able to inject mouse and keyboard events into the rendering engine.
Only C and/or C++
Must be easily portable and lack dependencies to libraries that only exist for win/linux/mac. The device I have runs a custom OS...
Small footprint and memory consumption, I can probably get away with 10MB footprint and 5-10 MB allocated memory during rendering. But not much more.
Both open source as well as commercial solutions are welcome
I do NOT need full HTML5 and CSS3 support, I mean if I can use "basic HTML and some CSS" I'm more than happy.
I have looked at some WebKit, chromium, gecko, berkelium and awesomium but not really found that they fit my needs.
Is there anything out there that comes close to what I need? Or should I just give up this idea and build the GUI in some other way? I appreciate any help!
Good question! It turns out there are a few options within this space, and as you've surmised, many of them are based on Webkit. Some of them aren't, though, and those are the ones that I believe you're most interested in.
Links
The simplest, 0th-level browser that's going to meet your needs is the graphical version of the Links web browser. It's suitably cross-platform (admittedly, you will require some of the libraries from Cygwin for Windows environments), open source, carries a small memory footprint, and in some of its forked or enhanced incarnations (for example, Elinks), has enhanced functionality like Javascript support, full mouse functionality, and the bells and whistles that you desire in your problem statement.
Of course, it's written in C.
Konqueror/Embedded
Exploring some of the other options within this space, Konqueror/Embedded is something to consider and watch in the future. Yes, it is based on Qt/Embedded and Webkit (mumble mumble), but they're aiming to provide a slimmed down version of both their browser and their library stack to meet this need specifically. Once again, Windows is going to be the odd child out here, but it's workable.
Fennec
One last cross-platform option to explore is the slim version of Mozilla Firefox, Fennec. While providing a much larger code base, Mozilla is working on its embedded version very aggressively, and any help you can provide here would be greatly appreciated. From what I understand, the slimmed version is still pre-alpha (Fennec, however, lives on), but it should become a workable option in the future.
And a Gamut of Others to Explore
In addition to the gamut of web browsers currently competing in this space, proprietary options like ANT Galio may also meet your needs. It seems there are many other proprietary solutions out there, but the majority of them (for example, Internet Explorer Mobile, Mobile Safari) only service a small number of platforms. Good, proprietary, cross-platform solutions that aren't based on Webkit seem to be quite rare.
SpliFF also offered an excellent suggestion in his answer: try libRocket. As he recommends, it's lightweight, cross-platform, currently and actively maintained, easy for you to hook into, and provides for the automation cases that you seek. In this case, it's programmed in C++, with Python bindings for additional convenience.
In conclusion, given your needs, you'll still need to evaluate the strengths, weaknesses, and API specifications for the options listed above.
I recommend starting with Links, because it's the most feature-rich and robust option while optimizing on a very small memory footprint and codebase. Its biggest strength is that this was a design goal from the outset, and the entire code tree is built with this design philosophy in mind.
Do let us know what you go for. This is a common enough need in the community that I'm sure others will benefit from your experience.
Have a look at librocket. It meets your requirements of being HTML+CSS, lightweight, handling events and rendering to a buffer. I looked though a bunch of projects recently looking for basically what you asked and this was the match I found.
libRocket is the C++ user interface middleware package based on the HTML and CSS standards. It is designed as a complete solution for any project's interface needs.
libRocket uses the time-tested open standards XHTML1.0 and CSS2.0
(while borrowing features from HTML5 and CSS3), and extends them with
features suited towards real-time applications. Because of this, you
don't have to learn a whole new proprietary technology like other
packages in this middleware space.
Cross platform architecture (Windows, Mac, Linux, iPhone, ...).
Dynamic layout system.
Efficient application-wide styling, with a custom-built templating engine.
Fully featured user control set: buttons, sliders, drop-downs, etc.
Runtime visual debugging suite.
Easily integrated and extensible with Python scripting.
Abstracted interfaces for plugging in to any game engine (samples for OpenGL, DirectX and Ogre3d).
Decorator engine allowing custom application-specific effects that can be applied to any element.
Generic event system that binds seamlessly into existing projects.
Have a look at DS Organize, a homebrew DS browser, and also ES Operating System by Google (for an OS originally developed by Nintendo).
I have suggested looking at DS Organize as the Nintendo DS has only 4MB of RAM (8MB with the memory extension that most DS browsers use). And you might also be able to get away with rendering directly to VRAM, saving you a few 100kb, depending on your memory model and how much freedom you have with VRAM writes outside of VBlank.

language and database suitable for data driven game like football manager [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I have a Cricket management game (like Football Manager) written in VB 6.0 long back. It uses MS-Access as it's back-end and win-32 API calls to draw UI screens. It's a reasonably big game with 90,000+ lines of code.
Now, I want to re-write the game using other technologies like Java, Python, C++ etc. Basically I want to get out of Microsoft technologies (and preferably move to technologies that are available for free).
So, please help me out in choosing right technologies for Application-Logic, UI and Database. Below are my broader requirements regarding the three layers.
Application-Logic:
The game needs to make 1000s of calculations on in-memory data and constantly write that data to text files (Save game files). It also needs to do very fast database operations.
UI:
The UI need not be very robust. The only requirement is to be able to develop good looking screens with minimal animation effects. Below are the links to current screen images for your reference.
http://imageshack.us/g/148/89832593.png/
I might also add 2D graphics in the future.
Database:
The database contains around 20 tables with the larger tables containing up to 300000 records. Again, I want to use a free database like MySQL or flat text files. I am very curious to know about the database used by games like "Football Manager" or "Cricket Coach 2011"
Note: Please don't consider the efforts required to learn the proposed technologies. I will take care of them.
Update:
Now that I have decided to go ahead with C++ and SQLite, please direct me regarding the IDE and basic Tools/Libraries I should be using to start with.
I am already experienced in working with "Visual Studio" and "Eclipse". Can I use one of them? or can I go with QT (I read that QT is cross platform, but, is it just for mobile development or can I use it for desktop apps too)?
And,
How critical is the IDE selection initially?
Can I move to a different IDE at a later stage?
If I use Visual Studio, am I getting bound to Microsoft technologies?
If possible, please give me links to any examples to develop screens as in the links I provided above.
[I see now that an "online game" was an assumption on my part. So keep that in mind as you read this.]
I would take into consideration your hosting options. If you want to open-source this or operate it on a shoe-string budget, and run it on the widest array of available hosting services, then you probably want to go with LAMP technologies. This would rule out my favorite language, Java, as the underlying choice of language. PHP is almost always available on inexpensive hosting options. Perl and then Python are also available on many hosts, but PHP is practically guaranteed these days.
If however, you'll be hosting this in a "whatever it takes" environment, I'm a big fan of Java, Tomcat, JBoss, etc. But those technologies, while powerful, take a lot of time to ramp up to use, but more importantly, to use effectively and efficiently.
MySQL is a great choice these days for databases. Postgresql is another free option (in some ways, maybe free-er than MySQL, given MySQL's Oracle connection.) But MySQL is likely to be more readily available on a lot of inexpensive hosts. MySQL also qualifies under "very fast operation."
Regardless of database choice, do what you can to abstract your database code so that should you want to change (or need to change) you can do it with minimal fuss. PHP and Java both have well worn ORMs to help you in this regard.
It'd be interesting to see what kind of data models are used in a game like a * Manager title. I suspect it maps well to a relational database. But I'm personally on the lookout for a good reason to dabble with a NoSQL solution.
HTML and CSS for the client to start.
For a database, I would recommend SQLite: http://sqlite.org/
It's free, fast, and serverless. Serverless being key. There are some drawbacks that you can read about on their website, but for a stand-alone application, it should be much better than using text files.

Online Flowchart Diagram Tool (run from private wiki) [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is there some flowchart diagram tool that would (or could be made to) integrate with a self-hosted wiki?
Requirements:
basic functionality (e.g., drawing some boxes and some arrows)
would strongly prefer it to be visual (i.e., not written out in text that then gets converted)
allows for dynamic editing
it is important that the tool can be integrated into the wiki (e.g., as an extra panel somewhere)
can be run from a personal server
free
I've looked around at other threads here concerning a diagram tool, but they are either desktop applications, online ones which reside on third-party servers, or cost money.
[Edit] Thanks for the responses, but I would like them to be dynamically editable (I've added this to the requirements). What I mean is that I would like to integrate (or run it from a private server) some online collaborative diagramming tool. While I could create a JPG of something made in Graphviz and upload it, this is not easily editable. I would have to upload the source file somewhere, which someone would have to download and edit, then upload the new JPG.
Graphviz dot diagrams can be embedded in some wikis. Unfortunately for your requirements, it's text that gets converted. It's fairly simple to learn and use though.
http://www.graphviz.org/
EDIT: It's free / open source.
I've been looking for something similar - collaborative flowcharts in a wiki. The most interesting so far is this Mediawiki extension: http://www.flowchartwiki.org/wiki/index.php/Main_Page
Balsamiq Mockups for XWiki is the closest thing I've seen. It's more of a previsualization tool however for application mockups, though I'm not sure if this is the kind of tool you're looking for.
It is free if you qualify under their licensing.
Another option would be using Mediawiki with the Dia extension.
I like using the svgedit plugin in dokuwiki for quick diagramming on the run. It produces standard SVG text files and has an always up to the date javascript wysiwyg editor. And, I submitted a bug/feature request on github and the requested functionality was added post haste.
Edit: FOSS!
i understand this question is old enough. but you could try Origramy. it's a Flash-based visual tool. and XML as the result can be get from the component. alas integration to wiki must be made separately
Not sure of the technology you have on your server, but Open Diagram can create a jpg image file on the server which can then be referenced as a normal image in your wiki. Its open source.
I've enjoyed the simplicity of UMLet for a while as a desktop app. Don't let the name fool you! There is more than just UML - it has a lot of basic charting elements in it. It's not pretty, and it can be awkward sometimes, but it works. Has basic visual items in a template/toolbox that you double-click on to reproduce on your canvas. You can then move it about, resize it, or edit the item and modify it via text.
There isn't an existing online integration method (that I've seen), but being that it's good old fashioned java, you might be able to make it happen.
It's free and distributed under the GNU General Public Licence.
honestly i think you are going to have to use Java and code an applet. there are wondrous advancements in javascript libraries (AJAX, JQuery) that also might assist in this...
cheers my friend.

Which wiki to use after MediaWiki? [closed]

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!

What Features Should Tomorrow's Wiki Include? [closed]

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