WikiMatrix
  • Forum
  •  » General
  •  » Market Void - No advanced commercial wiki in PHP

#1 2006-02-23 10:10:18

ryank
Member
Registered: 2006-01-04
Posts: 15

Market Void - No advanced commercial wiki in PHP

It's obvious to see the commercial success of Atlassian's Confluence with prices ranging from USD $1,200 - $8,000, and being named the fastest growing software company in Australia.  Being written in (j2ee and requires tomcat), you can't even change the text displayed or customize a template without Java programming knowledge.  It has a very polished front end and very intuitive design, but just enough to be noticeable nicer looking that most any other wiki software.  Hosting the app is fairly tough from what I've heard and Confluence uses so much memory 512mb+ that you really need a dedicated server, so you'll be spending over $100 for decent hosting.  Using Confluence with a 25 user license and hosting by an experienced Confluence host would have cost about $4,000/yr.  I'd rather pay $500 for the software, and then host it on any cheap server, which you can't do with big j2ee apps but you can with PHP, perl , python, ruby, etc.

I am really surprised that there is not a commercial wiki written in PHP selling for about $500 that has the typical advanced features - slick WYSIWYG editor so no wiki markup if users don't want to see it, tags/labels, easy categorization, character level diffs with or without wiki markup, or forced wikiwords if you don't want to use it, some AJAX thrown in to give it the Web 2.0 feel.  These features are not that difficult to duplicate, and add in Microsoft Word import for good measure and you'll be able to sell a decent amount of licenses.  Look at Writely.com, with 2 or 3 people they put together the most advanced looking and functioning wiki editing interface (virtually no group functions yet) in about 1/2 a year.

I'd pay about $300-$500 for a good PHP wiki, or a similar Confluence clone in PHP. 

I've tried just about all the major wikis out there, and hears my opinion on their potiential as of Feb 2006:


* TWiki - 4.0 = Leads all opensource wikis in the features department but perl is a tough for non-perl guys like me.  I gave up on a TWiki install on Debian after literally 8 straight hours of frustration, install docs have no exact verbatim step-by-step.  Though I know this is my fault because others have installed it fine, cgi is a tough environment to work in if you're not experienced.
>>> update: 3/7/06 - I've installed TWiki fine on a Debian server. After following the directions on the site, I did a "chmod 700 -R www-data:" at the top level of the TWiki installation and it seemed to cure the permission problems.

Other have great potential but need a fulltime programmer to make the interface more intuitive and add the features I mentioned above for corporate users.  A lot of the feature are semi-there but not polished enough to be easily usable by newbies.

* Dokuwiki - development version =  I love many things about it, and would be perfect base for a commercial wiki, but many essential compenents aren't there like WYSIWYG, ridding of _ and other overly wiki-ish displays, and easy categorization, more intuitive grouping of links and buttons

* MoinMoin - 1.5.2 = has a lot of potential too but would rather have PHP than python.  The WYSIWYG if saved with Word paste will often create an error so severe that the wiki page is no longer visible, it only shows an error. Also, there are too many dumb 1998 layout choices like bookmarks shown in a textarea box instead of hyperlinked with a "delete bookmark" button.

The hosted wikis like Jot and Socialtext are close, but they are way too branded by the companies and tend to be organized for a small number of documents, not hundreds of pages with many categories, plus custimization of layout is virtually nonexistent.  Installing the code on your servers or, at a minumum, having it hosted using your domain is expected by most businesses.

It seems the most important core functions for corporate customers are (1) easily importing existing documents (import Word docs), (2) editing them in a WYSIWYG interface mirroring as much as possible traditional word processing programs, and then (3) displaying and grouping the information in a logical way.  Other things are nice but that is what will sell and people will pay for.

Invision Power Services (InvisionBoard makers) is coming out with a wiki this year, and they're excellent in user interface department, so I have high hopes for the PHP realm still.  We shall see...

Last edited by ryank (2006-03-08 01:10:47)

Offline

 

#2 2006-02-23 23:04:54

harry
Member
From: VA
Registered: 2006-02-08
Posts: 5

Re: Market Void - No advanced commercial wiki in PHP

PmWiki and Dokuwiki are pretty well developed, in my opinion, although I would agree that one thing many open source wikis lack is a usable, bug-free WYSIWYG editor.

Maybe another open source like FCK editor can create a universal wiki WYSIWYG editor with their existing tool. I wonder how difficult that would be, aside from accomodating for all the different formatting rules that come with each wiki?

I decided to stick with dokuwiki because I really like a lot of features... the beyond compare-like feel comparing files, the intuitive linking/categorizing, easy use of uploading (although some sort of file manager would be nice.. if we start uploading hundreds of documents, pictures, etc.. I can see it getting messy), ease of installation and adding plugins, etc.. just to name a few.  In the coming weeks, as we incorporate more of our documentation with dokuwiki, I'm planning on developing a .doc-import tool which I'll probably end up posting on their site, unless it's already available.

In terms of categorization, I think dokuwiki has a great categorization/namespacing system.  It's organized in a folder-like manner, which I think is really nice.  If you go into the configuration php file and allow the character '/' to be used as a namespace classifier, it helps more visual users get the hang of it more.  You can do insane things like


  [ [ :home/user/friends/2006/vacation/summer/cancun] ]. 

They have the indexing view which allows you to see the structuring, also.

My question is how secure is the login functionality?  Is it robust enough?  If I were to decide to put sensitive information out there, I'm afraid that if it's too easy to hack, it would be a disaster. I'm pretty new to php, but apparently there are a number of different ways to secure your login information, prevent session stealing, etc.  Anyone know how dokuwiki's security stands up to the challenge, potential security risks, etc?

Also...along the lines of users in the wiki...I haven't tried exporting my wiki, but I'm assuming it's pretty clean.  If we have certain logins that can have read-only privelages to certain pages, but no access whatsoever to other pages.. are those rules applied in the export?

Last edited by harry (2006-02-23 23:08:54)

Offline

 

#3 2006-02-23 23:42:02

ryank
Member
Registered: 2006-01-04
Posts: 15

Re: Market Void - No advanced commercial wiki in PHP

harry wrote:

PmWiki and Dokuwiki are pretty well developed, in my opinion, although I would agree that one thing many open source wikis lack is a usable, bug-free WYSIWYG editor.

Maybe another open source like FCK editor can create a universal wiki WYSIWYG editor with their existing tool. I wonder how difficult that would be, aside from accomodating for all the different formatting rules that come with each wiki?

I decided to stick with dokuwiki because I really like a lot of features... the beyond compare-like feel comparing files, the intuitive linking/categorizing, easy use of uploading (although some sort of file manager would be nice.. if we start uploading hundreds of documents, pictures, etc.. I can see it getting messy), ease of installation and adding plugins, etc.. just to name a few.  In the coming weeks, as we incorporate more of our documentation with dokuwiki, I'm planning on developing a .doc-import tool which I'll probably end up posting on their site, unless it's already available.

In terms of categorization, I think dokuwiki has a great categorization/namespacing system.  It's organized in a folder-like manner, which I think is really nice.  If you go into the configuration php file and allow the character '/' to be used as a namespace classifier, it helps more visual users get the hang of it more.  You can do insane things like


  [ [ :home/user/friends/2006/vacation/summer/cancun] ]. 

They have the indexing view which allows you to see the structuring, also.

My question is how secure is the login functionality?  Is it robust enough?  If I were to decide to put sensitive information out there, I'm afraid that if it's too easy to hack, it would be a disaster. I'm pretty new to php, but apparently there are a number of different ways to secure your login information, prevent session stealing, etc.  Anyone know how dokuwiki's security stands up to the challenge, potential security risks, etc?

Also...along the lines of users in the wiki...I haven't tried exporting my wiki, but I'm assuming it's pretty clean.  If we have certain logins that can have read-only privelages to certain pages, but no access whatsoever to other pages.. are those rules applied in the export?

I agree, I think Dokuwiki is the best of the bunch so far with the most potential.  The Esther's tag plugin works pretty good too.  The tag plugin would be more intuitive if it was placed outside the main editor window, maybe create a small text area below the main text next to the comment textbox that says "Page plugins and settings".

My main concern is getting NEW users who will not use it if it is intimidating with you must learn "three spaces and a * will create a bulleted list" or other basic syntax...probably 99% of people only have experience with webmail and word processors, coding or ability to understanding even the basics like closing a tag.  That is who I and I think most people want to help contribute to wikis.  Therefore, learning wiki syntax is not really an option, nor should it be required given the WYSIWYG technlogoy today.  How many regular people would rather handcode an Rich Text Format (RTF) or just use a gui editor like OpenOffice, AbiWord or Word?

Name spaces are ok, so long as there is a GUI frontend interface to do the linking.  People can't remember an 8 layer nested namespace.

Offline

 

#4 2006-03-03 19:04:10

esther
Member
From: Zurich, Switzerland
Registered: 2005-11-30
Posts: 9
Website

Re: Market Void - No advanced commercial wiki in PHP

ryank wrote:

I agree, I think Dokuwiki is the best of the bunch so far with the most potential.  The Esther's tag plugin works pretty good too.  The tag plugin would be more intuitive if it was placed outside the main editor window, maybe create a small text area below the main text next to the comment textbox that says "Page plugins and settings".

Tags are meta-content, but visible meta-content – and that's why I think tags should be entered in the main editor window. Like that, users are free where to place the tags, before, inside or after the regular content.

ryank wrote:

My main concern is getting NEW users who will not use it if it is intimidating with you must learn "three spaces and a * will create a bulleted list" or other basic syntax...probably 99% of people only have experience with webmail and word processors, coding or ability to understanding even the basics like closing a tag.  That is who I and I think most people want to help contribute to wikis.  Therefore, learning wiki syntax is not really an option, nor should it be required given the WYSIWYG technlogoy today.  How many regular people would rather handcode an Rich Text Format (RTF) or just use a gui editor like OpenOffice, AbiWord or Word?

I agree with you that WYSIWYG would be real cool and that wikis could attract a lot more people who are now intimidated by the wiki syntax. On the other hand, WYSIWYG is limiting to syntax commands with a clear visual representation. With current browser technologies, this is possible for basic formatting, but not for more complex things like including one page within another. Or at least I don't know how that could be achieved in a sensible way.

And after all: Wiki syntax is not harder to learn than BBCode. BBCode is quite common in forums (this one as well) and has not deterred people from using forums. For most wiki contributors who begin working with wikis it might be enough if they can enter raw text and understand what's the effect of the markup used. Only later they begin using the syntax markup on their own, that's a natural learning process.


DokuWiki plugin developer and operator of Qwik!

Offline

 

#5 2006-03-04 11:38:47

ryank
Member
Registered: 2006-01-04
Posts: 15

Re: Market Void - No advanced commercial wiki in PHP

esther -

re: tags inside the main textarea

Play around with Confluence's tagging (they call it labels) on one of their sandbox pages:
http://confluence.atlassian.com/display/TEST/MotoTest

For newbies, Confluence's implementation is awesome, it's immediately intuitive and kinda fun to use with nice javascript actions.

Seperating metacontent from the wiki page is purely for intuitive reasons...who wants to learn what the brackets and less-than sign mean with {{tag>wiki tagging animals}}?.  All tagging sites like del.icio.us have a seperate (ajax smart) text box for url, notes, and tags because it is more intuitive for the masses.

re: WYSIWYG

I understand your reasoning, but I'm looking at this from a new users perspective, like a 55-year-old non-programmer  who can barely use their own computer and MS Word, let alone learn a new syntax or understand the concept of closing formatting tags or .  They'll simply avoid the wiki.  And I'd rather them feel comfortable contributing content from the start with little or no learning curve.   I've tried to implement wikis with groups, mostly young adults and students, and I couldn't get anyone to use Dokuwiki (my favorite), but had some acceptance and useage with Jot entirely because of the WYSIWYG editing.

Invision and vBulletin have both moved to WYSIWYG commenting, probably for the same reasons I mentioned above.  It's what people are accustomed to from word processing programs, and going to an all text with markup solution seems like a step backward to most.  Again, I'm in an environment where most people's experience with the web is just web-based email and yahoo searching.  It's the same reasons why Frontpage was so popular for non-coders even though you can get more precise and accurate by hand coding HTML.

Confluence, TWiki, Jot, MoinMoin and others have nice WYSIWYG and text editing, and permit various wiki variables and code to not be parsed out on save.

I suppose Dokuwiki could alter the link toolbar button so clicking on the internal link button pop up the existing ajax search box, and clicking on the page title would insert the proper page name and linking syntax.  I'm comfortable with wiki syntax and linking but I often forget page titles, so a page finder in the toolbar makes sense especially since the ajax search code is already used in the search box.

Last edited by ryank (2006-03-04 11:49:21)

Offline

 
  • Forum
  •  » General
  •  » Market Void - No advanced commercial wiki in PHP

You are not logged in.


Board footer

Powered by PunBB
© Copyright 2002–2008 PunBB