Loading...
 
 Error
  • The search index could not be updated. The site is misconfigured. Contact an administrator.
    SQLSTATE[42000]: Syntax error or access violation: 1064 unknown table 'themes_tiki_org_main_6621fe297452d' in delete request
Tiki Design

Tiki Design

Forum List Topic List

Forums » Tiki Design » Flexibility, originality, modularization and simplification
 
Thread actions
PDF Print this page
  • Print all pages

    • Flexibility, originality, modularization and simplification

    Posted by cgc0202 on Tue 02 of May, 2006 14:39 GMT-0000 posts: 11

    Flexibility, originality, modularization and simplification

    To an extent, I agree with many of the points already raised by marclaporte, Griebel, as well as the direction that Gary was doing with the ideas that he tried to develop in Zukakakina. I hope that those ideas will migrate in this forum.

    Flexibility

    What attracted me with the experimentations of Gary in Zukakakina is the concept of flexibility. Personally, I consider the way the layout developed for Tikiwiki to be too rigid — some stuff have to be at the top, left-mid-right in the main section and stuff at the bottom. These rigidity were then encoded in the Admin. Deviate a little and you may be better of starting from scratch.

    Gary was trying to present alternatives with his experiments in his layout design. As Griebel also pointed out, there must be separation between layout and content.

    The content must be adaptable to any layout format, rather than the format dictating how the content must be presented. I will present more ideas on this, if there is any interest to explore this issue.

    Originality

    The goal of every serious webdeveloper is to do what Rick did — create a unique layout for a site to further distinguish a site from any other site. If I have to use any templated theme, it is more because I do not have the expertise like Rick or Gary to create a unique layout that will be exclusive for my site, right now.

    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.

    Afterall, how many themes does a good site need? The answer is "1", and perhaps a few, as pointed by marclaporte, to give the visitor some choices apart from the preference of the web developer. There are many sites that are popular that are quite plain in fact but are popular because of the quality of the content. If a good layout can make the experience better for the visitor then so much the better.

    This brings the issue back then to flexibility, if originality is to be encouraged. In the end, an attractive layout must not be the main attraction of a page.

    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.

    This is very important for a number of reasons. Aside from serving as landmarks and guideposts, most users of Tikiwiki — if they are like me — are likely to use only a few of the gazillion features of the Tikiwiki CMS. I bet the size of each theme CSS can be reduced to a third or even much less if the unique specifications of each module can be removed, when they are not used.

    [The entire "styles" directory is several megabytes — not so much because of the text in the CSS specifications, but I think more because of the gazillion icons that go with some of the themes. I am not too fond of icons either. In this regard, just imagine how many megabytes may be saved, if the same is done with the modularizing the actual php and template files and directories, and if possible in each of the actual script itself. Just imagine the reduction in the size of the resulting Tikiwiki and how this would translate in the speed.]

    Perhaps 50-70% of the posts and threads — dealing with layout clarifications and modifications — in the Tikiwiki forums could have been avoided if each CSS has been well annotated, e.g., /* - Module block borders specifications - */

    The annotations for the specifications may increase the text size but will make it easier for users to find and make changes in the specifications.

    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.

    Why not a very basic specifications for sizes: 100% for most text, 120% for main headings and 70% for footnotes, etc. Limit bold only to those that require emphasis. The same could be said with the text and background colors. [A good example of this is this forum layout.]

    This will reduce the number of specifications drastically, irregardless of how many features are created. Having said this, there are webdevelopers who prefer all colors of the rainbow and whistles and bells for their website. This can be accomodated quite easily, if each specification has been annotated, as indicated above, so that modifications (customizations) can be done quite readily.

    It is much easier to create complexity from a basic layout than the other way around.

    cgc0202

    Reads: 20741
    Link
    Posted by Gary Cunningham-Lee on Wed 03 of May, 2006 10:16 GMT-0000 posts: 254 Japan

    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.

    I bet the size of each theme CSS can be reduced to a third or even much less if the unique specifications of each module can be removed, when they are not used.


    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.

    [The entire "styles" directory is several megabytes — not so much because of the text in the CSS specifications, but I think more because of the gazillion icons that go with some of the themes. I am not too fond of icons either. In this regard, just imagine how many megabytes may be saved, if the same is done with the modularizing the actual php and template files and directories, and if possible in each of the actual script itself. Just imagine the reduction in the size of the resulting Tikiwiki and how this would translate in the speed.]


    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.

    Perhaps 50-70% of the posts and threads — dealing with layout clarifications and modifications — in the Tikiwiki forums could have been avoided if each CSS has been well annotated, e.g., /* - Module block borders specifications - */


    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.

    Why not a very basic specifications for sizes: 100% for most text, 120% for main headings and 70% for footnotes, etc. Limit bold only to those that require emphasis. The same could be said with the text and background colors. [A good example of this is this forum layout.]


    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.

    Link

    Layout

    Subscribe to Tiki Newsletters!

    Delivered fresh to your email inbox!
    Newsletter subscribe icon
    Don't miss major announcements and other big news!
    Contribute to Tiki

    Site Config