Related
Not a programming question I'm afraid, so moderators do what you will, but it is a question specifically for self-employed programmers running their own ISV sites.
If you publish your own shareware or freeware, do you use any CMS or templating system to streamline maintaining the website? Would you recommend any?
Two most important features I'm looking for that I couldn't find in any popular CMS/blogging engine, from my favorite TextPattern to WordPress, Joomla and Drupal are:
a templating system to maintain structural consistency of xhtml page layout
a hash table of user-defined values that works with the templates to substitute these values for identifiers.
Explanation: If you publish more than one application, the site probably contains several classes of pages that are nearly identical for each product: "Features", "Screenshots", "What's new", "Download", etc. These pages have the same layout and differ mainly in product-specific data. I'd like to be able to define "CurrentVersion=2.2" for product A, and "CurrentVersion=3.3" for product B in a "dictionary", and have the system generate two "Download" pages from the same template, replacing the "CurrentVersion" identifier with each product's respective value.
Other than that, I am looking for good support for static pages (the example pages above do not yield themselves to blog-like timeline treatment) and for design templates (themes), since I can't do graphic design at all (no skills, no tools, no talent). A good search function, esp. for the FAQs, is important. Another nice-to-have is easy (preferably wiki-like) way of linking to pages within the site. Some CMS-es, such as Joomla, make this simple and common task surprisingly inconvenient.
LAMP, and preferably free, since mine is a freeware-only shop.
I need no collaboration features and no multi-user content editing at all. My ISP doesn't support Zope, so that excludes some candidates.
I'm asking this question having spent months trying to find a solution that would help me leave static html behind and reduce the maintenance chores, such as updating the current version number on several pages manually. So what do others use to publish their software?
(Please do not reply by just saying "Try X". At least please say what makes it suitable or how it is better than other possible solutions. I've already tried a number of CMS engines, and they all seem to require extensive modifications to suit this particular need. Since my programming experience is strictly desktop-side Windows, tweaking these products is well beyond my skills (and my skin crawls to think of potential security WTFs I could unwittingly commit). Time is also a factor, since between my day job and my late-night coding, there's little left for learning how to write my own CMS from scratch - just typing static html would be more efficient.)
Wordpress is quite nice. It has a big community behind it so you can leech some plugins, like for SEO optimization, PayPal integration, Google Analytics statistics tracking, etc. And you also have a full-featured administration backend to manage all your content.
I would recommend Joomla 3.2.x. I have the same sort of project based websites, and this provides the flexibility for all of the different requirements. While WordPress is great the simplicity of it gets the better of it, Joomla is far more flexible and has a huge support network and extensions library.
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!
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
Do you use a wiki in your company? Who uses it and what for. Do you share information between projects / teams / departments or not?
We use ours to store
Coding Style docs
Setup and Deployment procedures for web servers and sites
Network diagrams (what are all the servers in Dev, Staging, QA and Production called etc.)
Project docs (pdfs, visios, excel, docs, etc.) are stored in SVN. For the non-techies we have links to those docs in the wiki that point to an up-to-date share on my box. (tip: some wikis provide source control integration but ours doesn't)
Installation and Setup procedures for development tools
Howto's on things like using our bug tracking system, our unit testing philosophy
When doing research on a topic I often capture the important information in a wiki page for others to learn from
I've seen them used to keep seating charts in medium to large size organizations for the new people
At my previous company all of the emergency contacts and procedures for handling a critical outage where available on the front page of the wiki
The best part about a wiki is that it's searchable. Some wiki's support searching inside uploaded or linked docs as well.
If you setup a wiki and encourage or even require people to use it the amount of information that will accumulate can be amazing. It's definately worth the effort especially if you have someone in IT with some spare time on their hands to set it up.
Do you use a wiki in your company?
= We use it for the purpose of a Knowlede Based. Basically it is a wiki but many more functionalities intagrated.
Who uses it and what for
= Employees. Knowledge Sharing, Preparation of collaborative-documents, etc.
Do you share information between projects / teams / departments or not?
= Depends on the requirements. It is possible to set permissions between users.
We use a wiki, for documenting our systems. It's updated gradually as things update and evolve. It should go without saying that there's benefit in that, however whether you use a wiki or other methods is worth thinking about.
A wiki is great for collarborative editing. The information shouldn't go stale in theory, because as people use the systems they have the opportunity to keep it up to date.
However we have found in our organisation that people struggle a little with wiki markup. Especially tables. I think a solution that has wysiwyg editing would be better if you have non-highly-technical people editing it. Sharepoint springs to mind, but it's expensive.
I use a wiki as my virtual "story wall" for agile development. All of my stories are written and organized in the wiki. While my customers are reasonably local (we can have face-to-face meetings), they aren't co-located. To enable better customer interaction I've resorted to a wiki instead of a wall-based story tracking mechanism. It also works a little better for me due to the fact that I often have multiple, concurrent projects and limited wall space in my cube. In a larger team with more focused projects and more wall area, I'm not sure I'd make the same choice.
My company uses a wiki for project-planing but also for storing documentation and ideas.
I have found that a wiki is a great way to link the programmers in the company with the business-people.
When someone who are not on the programming-team comes up with an idea or finds a bug, it's a loot simpler to let that person document it in the wiki.
I think it's an important aspect for a small company like mine to easily synchronize the business-team with the development-team. A wiki helps with that, since it gives the feeling of being a part of the development process, instead of having to ask the programmer directly about every little detail.
we have MediaWiki to store technical information that is not ready to be published in other formats - specification drafts, diagrams (via GraphViz extension), results of short investigations, etc.
I also think this question is a wiki too :)
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.