Re: Flexibility, originality, modularization and simplification
Flexibility, originality, modularization and simplification
...
Originality
As good and popular are such themes as Kubricki, etc., we will not make any real progress here if the goal is just to create more "clones" simply because they are popular.
That's correct. I did "clones" — or adaptations of themes of other CMSs and blogs — as a kind of challenge. Both for me personally and as something suggested by Marc, the idea of showcasing Tiki's design flexibility was/is appealing. But I agree that this shouldn't be considered a final goal. I think it's only one step along the way, so people can say "Wow, Tiki can look like these other CMSs/blogs and it also has these other unique themes."
One of my ideas is to try making something like "base" themes that are designed to be easily modified by the end user. This could be done by making the stylesheet, maybe in a "light" and "dark" version, and offering sets of graphics so a whole range of site looks could be derived from a basic starting point.
Along these lines, I want to do more themes that are not replicas or unique one-offs, but will lend themselves to easy customization.
And I want to put together a tutorial on how a theme like Snow can be totally transformed just by using different background images.
Modularization
I am sure there is an order or even modularization in the way the specifications in the CSS are presented by the various developers. However, each CSS is as complicated as the road maps of cities, a novice like me who has no sense of orientation gets lost so easily.
There is a simple way to avoid this: Include landmarks and guidelines. For example, each section must have something like this: /*- Begin Forum specifications -*/ and /*- End Forum specifications -*/. There should be a section for core specifications too, i.e., shared by all sections.
I've been trying to do this and improve it with each theme I do. I started adding a lot of comments in the CSS file as my own learning tool, and realizing it can be valuable for others. Many selectors in these files are completely mysterious without some comment about them.
Yes, it's pretty easy to get the file size down to half of the typical Tiki style sheet size. But there won't be a dramatic reduction until changes are made in the template and lib files where style selectors are identified.
I don't think icons are actually a significant factor. The image files are tiny and, once downloaded, are just displayed from the browser's cache so subsequent displays are very quick.
The php and template files are, in fact, already compiled by the Smarty template engine so they don't have to be reassembled with every request.
I hope to get some better docs put together as time goes on. Tikipedia in particular was very time-consuming. Like everything else with Tiki, better docs will mean less need to answer questions in forums and IRC. I've got quite a few ideas about this, and will put pages together as I can.
Simplification
Let me add a further twist on what Griebel about separation of the parts and colors. Is there really need to have unique font sizes, spacings, bold or not bold, for every different feature, in every different section? The resulting permutations contribute to the bloated sizes of all the various themes.
There's been talk about simplifying/refactoring the templates and CSS selectors for a long time, and I think this is supposed to happen at some glorious point in the future when decisions about Tiki's backward compatibility will have to be faced. After all, a significant shift like that will mean a lot of people's customizations may be broken.
I guess CSS has gotten a lot of overly-explicit selectors because different people have coded different Tiki features, and have used feature-specific names for the items. It wouldn't be rocket science to unify the specs, but this will have to be done in a coordinated way, with warning given to long-time users about the need to adapt customizations to subsequent Tiki versions.
Actually I think this particular suggestion elbows into the designer's realm too far. I think a better approach would just be to replace feature-specific identifiers with global ones, but let each theme designer decide how to style them. This would enable unity throughout a particular theme, but would allow themes to diverge as much as the designers want.
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}