Loading...
 

UserPagewatson

I love(d) Tikiwiki when I first came across it. Let me count the ways:

1) It is just so freaking cool!!

2) It is soooo well documented (girlfriend at the time was pissed at me when I had the docs sent to me on out vacation in New Hampshire, and read it in one weekend — oh well)

3) It is an entirely self contained, ready to run "out of the box" (so to speak) Content Management System — no shell installations, no servers, just install and go!

4) It has ALL the major components an organization that wants to put some processes on the web would need — message boards, categories, a workflow system (even when it wasn't explicitly defined as one — via the access control system), calenders, articles, news .... makes my head spin.

5) The fact that all Tiki's features are BUILT IN!! No plugins — yay!! Other CMSes seem to try to work on the *Nuke plugin model, and it is frankly annoying — it is much easier to turn off a feature you don't need, rather have to hunt through the 'Net for a feature that you do need. I love having everything at my fingertips, one mouse click away.

6) The absolutely fabulous user / group access control system — NO OTHER CMS I have tested even comes close — the fact that access control was BUILT IN from the beginning is a testament to foresight.

.... However, Tikiwiki has a MAJOR issue that precludes me from using it sadmadcryexclaim — the lack of a built in (access controlled) MS Word-like HTML editor (like HTMLArea) for ALL of the documents Tikiwiki can create (articles, forum posts, etc.).

Why is this such a problem for me?

As much as I hate MS (and Word), one has to admit that the way of editing it has spawned, is the de facto standard (Open Office, which I use, even looks like Word, to some degree).

As a result of it being the standard, most business people know how to use that type of interface, or can help others use it.

For a collaborative business website, it is far easier to teach people how to use a Word interface (with familiar icons etc), than it is to retrain them in how to use (and remember) all the Wiki codes and their associated options.

Ease of use is paramount, not to mention reduced costs for a Web Developer like me, who would not have to charge a company (as much) for training on how to use a system that should be esy to use "out of the box".

I consider myself a fairly technical person, (I am currently updating the PHP ImageMagick extension — look for it soon biggrin) but I have to admit that the Wiki way of doing things had me stumped for a while.

So imagine the hell I would have to gone through in order to explain the "Wiki way" of editing — most people just never get it, or find it too annoying to use.

I REALLLLLLLLLLLLLY want to use Tiki (instead of MamboServer, which is what I currently use), because of all it's attributes, epecially that killer access control system, and the self-contained, ready to run way it was built.

However, even though Mambo has it's shortcomings, it allows my customers to update the website THEMSELVES (although far too much input is needed from me, since it currently does not have admin definable groups), with minimum training, and that is worth more, unfortunately (sigh), than all of the other absolutely whizbang features of TikiWiki.

Tikiwiki needs to be a wiki in name only (or only in a particular section, like the Wiki biggrin), and step up to being the God of All CMSes that it knows it is twisted.

Keep the name, drop the paradigm.


Page last modified on Tuesday 27 April 2004 15:08:56 GMT-0000

Upcoming Events

1)  Thu 21 Nov 2019 14:00 GMT-0000
Roundtable Meeting 2019 11

Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.