Features / Usability

Hi Gary,

I agree with you, a plugin is the way to go. For example, I was able to insert a java script plugin of flickr into a demo site that I am experimenting with in Tikiwiki because there is already a javascript plug-in I thinki in Tikiwiki. However, even in that case, I was only able to insert the flickr random photo viewer, in a global manner.

I am sorry for the delay in responding. It was intended. I was trying to find a solution to the issue I raised here but has not found a suitable one yet.

In regard to further details, the photos in the Test php page are based from Coppermine Photo Gallery website. If you click on any of the photos, it will revert back to the actual photo, but also lead you systematically to the related photos as well as to the systematized arrangement, classification or grouping of the photos in the entire gallery.

The photos are "randomized" but also in a systematic way. For example, it is possible non-only to access the entire Gallery, but also specific albums, by photographer, or all sorts of permutations. At least that is what the developer of the module claims — and from what I have read others have accomplished.

Correct me if I am mistaken, but to my knowledge, the image gallery of Tikiwiki has not reached that level yet — at least the time when I investigated it. The Tikiwiki image gallery also doe not have many features that are standard in many dedicated photogallery software. In the case of Coppermine, it is actually a multimedia gallery accepting various options — photos, movies, pdf, audio, etc.

We also discussed the features of randomization that is possible through the Tikiwiki, as demonstrated in the "banner" random presentation in your website.

As I stated previous, what would have been ideal is if this could be done with the DCS because that is the only way I know where photos could be inserted on a page-by-page basis. You stated that it could be done. Maybe it is indeed the case. But so far, with my trial-and-error, I have been unsuccessful to do that with Tikiwiki. A great part of it is that there are no instructions.

While I have no scripting background, with adequate show-and-tell type of instructions, or detailed manual, I usually can make something work. This should be evident with the "Test Page" I showed in the previous post was quite rudimentary — as it is mainly meant as a discussion demonstration that I had to show to the guy who developed the mod in order to clarify some features of the mod.

Unfortunately, I could not do that with many features of Tikiwiki because there is practically nothing to begin with — based from documents sections. Even the absence of instructions would not faze me if it is simple enough.

For example, I was able to hack the default layout of Joomla, also a CMs like Tikiwiki, last night within a few hours — mainly because the index.php, CSS, and other related files to understand the entire architecture of their page is quite simple. I have been trying to do that with Tikiwiki for ages and my customized webpage is still not good enough for my taste.

I get overwhelmed and lost with the complexity of what should be a simple thing like a Tikiwiki CSS. And, with each upgrade, it seems the size of Tikiwiki keeps getting larger and larger. It is now almost 50MB???

It is the slowest among all the softwares I have used. You would think that a photo-rich site would be slow but I never encountered that with Coppermine or other photogalleries I have tried so far. In contrast, no one in my family would view the photos that are loaded in our Tikiwiki based album because it would take several minutes for a single photo to appear — when using a dial up (common in poorer countries).

Please understand that I am not frustrated with the you or any of the core developers of Tikiwiki. In fact, I am amazed how much effort they are placing into the creation of Tikiwiki.

I am frustrated because there are many key features of Tikiwiki that I like. And, I have looked at many CMS that do not have the advances that Tikiwiki has achieved, for example in its permissions features — a very critical issue for me. Unfortunately, they remain inaccessible for me, for reasons I already outlined above.

A more important consideration is the increasing bulkiness of Tikiwiki — it has become the Microsoft of CMS. 😀

cgc0202

N.B.

I am rethinking the whole issue of php script itself in a tikiwiki environment because of the potential security risk. Maybe this could be minimized by locking a wiki page if it has php scripts but I am not sure how robust Tikiwiki security even in such locked setup.