TikiIntegration2

I been using Tiki sporadically for some months now, and tikiwiki.org since creation, and there are some things that jump into ligth about Tiki after using it.

Mixed content

For one thing, a Tiki site is specially good for doing one task, talk about one kind of topic. In example, if there be a tikiwikidocumentation.org site, where all content is about documentation, all registered users are documentation maintainers, and all features are pointing to that goal, is good, but if some other content is mixed with it, things are not so clear.

To have some examples, the listing of last modified wiki pages module list all pages, not just modified documentation pages, there user pages, tests, content like this very page is mixed around and blur a little one of the goals of this site. Blogs, forums, templates, and even permissions are not directed to this only goal, a lot of features are system wide, not task/category oriented. The same could apply for other ways to use this site, be for development, showing latest features, having a user base, or plain test.

A way to combine content, but also be able to see the site as one-content-type system, could help a lot, i.e. having something like http://tikiwiki.org/tiki-index.php/Documentation?page=TikiIntegration2 (not that it should be that way, is just an idea) as URL will show that page but the site around is buit centered in the category Documentation, i.e. last wiki pages are the last modified pages in the Documentation category, the forums and blogs are the ones in that category, and the same for the other objects that can fit in a category... the only other hint the user have about more content in the site is a listing of more categories or see the site categoryless.

Related content

Ok, we have categories, we can put a lot of different objects, with certain granularity, in them. But this is enough? is enough to have a box with things or what we could want is the puzzle already resolved?

One of the advantages of Tiki is the different ways to put content that it have. As a personal point of view, I see wiki pages for "static" content (ok, you can see changes, but a wiki page by itself, in the normal way you look at it in a visit, is very static), discussions (forums, comment system), evolutions (blogs show how something or someone evolves, changes thru time), images (image galleries, illustrations, links from outside, etc), files (file galleries, attachments), some kind of structured data (trackers, more?), and a lot more of things.

But, how they are related? For documentation, what links conceptually the wiki pages of documentation with a gallery containing the images, or a blog that could talk about changes, or a forum to discuss how to follow? A lot of things are very distant to each other even when they talk about the same thing. This runs not only for categories, also runs for users, individual wiki pages, forums, blogs, etc. We have "natural" ways to discuss, to show the evolution of something, to have some static content, to have a table with information, but if I make a wiki page, I must go to another country to discuss properly about the content (the comment system is very limited) and to another to show how it changed, what I thinked when I made those changes, what I learn about it and fixed about it (history of changes don't says a lot), and trackers are another country also, or I link a tracker with all the interface, or I put at hand all the info.

Then how I can put some integrated content, something that takes advantage of existing Tiki features? I would like to have some possible content holders for each object I create. In example, I create a wiki page? then I can "attach" to it a forum to discuss it (not just comments), a file gallery (not just plain attachments) , a blog, an image gallery (where will be all the images I put in that wiki page)., a poll, quiz, some trackers for displaying from or putting into info on them. Hey! Even I could want to define my own user groups and related permissions for this particular page and content. The same runs for the other kind of content of the system (attach a FAQ to a forum seems to be in the cover of the book, or a wiki page that explain the mission of the forum, or a wiki summary for a blog).

Some interesting side effect of this are users. If users can have its own user (wiki) page, then they could create its own blog attached to it, its own image gallery (not just system gallery), with this kind of approach we can even combine this with the previous section here, and have http://tikiwiki.org/tiki-index.php/gmuslera?page=TikiIntegration2 where you see "my" site, my content, what I have generated from my own personal page, and even my own view on how interact with my content (my own permission system).

Namespaces

With all of this we will have a potentially large content base, a lot of forums, file galleries, blogs, etc, created in a very dinamic way. Conflicts with names will be problematic at the very least.

A solution for this is having namespaces in a similar way that is described in TikiNameSystem. Categories and users creates objects with a full name related to the owner, i.e. mycategory.mywikipage or myuser.myblog. But what with descending objects, like a forum attached to a wiki page? well, it could be named applying the same scheme, like mycategory.mywikipage.blog (as reserved word, for "anonymous" attached blogs) or mycategory.mywikipage.myblog (a choosen name for a blog when more than just one exist).

Presentation of related content

The effect of having "unified" content in very different ways to present it will be not as strong as having them in a unified look. Having special templates for attached info (i.e. instead of a full page file gallery, to have a simplified version to be put in the bottom of whatever thing is attached to), or be able to have as attachable content some kind of templates (not need to be Smarty) could be very helpful. For trackers and maybe for other, some kind of form or template designer to show or edit the info will be in the same line. Maybe some of the integration I talking here could be solved with wiki plugins, i.e. some for displaying or entering info in trackers, or showing the last N posts of a named blog or embedding a poll)

Also could be a side effect on site layout. A related content could be a menu? a topic map (thanks pacoit 😉 ) ? a poll? Where will be the right place to display them? Could be in one of the side columns, behind the last "fixed position" module. If a module need to be on top could have some fixed position or priority (i.e. the site logo, or the login box or the system menu), and the others just stack up, and between them, could be inserted the content specific modules.

Core/Architecture/External Modules

How all this integration relates or conflicts with the idea of having a microtikicore and most actual features are external modules? If something of what is discussed here is desirable, then having the API, the architecture specification and even the example modules contemplating the possibility of not being stand alone information but integrated to a bigger information structure, and maybe be able to integrate the other kind of contents of wiki. If I made an e-commerce module, is somewhat reasonable that I could want to integrate to my own logic an image gallery of products, a wiki page about each product, a forum to discuss each one of them, some polls or charts, etc, and in the other direction in my wiki pages about products I could want to sell it thru my ecommerce module