History: Roadmap

Source of version: 16 (current)

{maketoc} This is a big picture roadmap of where Tiki themes are going. Not for individual bug reports. !! General goals * Make it easier both for theme designers with ((Skeleton)) and for power users with ((Site identity)) ** Seek feedback about Skeleton ***Ok have two themes to do this month. You have 1 guinea pig. (MLP) *** There are no reports so far about if this is actually being used. It would be good to know if anyone has actually done a Tiki theme and/or site by starting with Skeleton. Also, it would be good to know what could be improved in the Skeleton idea. *** I've been using it for testing & investigations and find it useful - i'd like some options, like: *lite only, *lite & layout, *lite, layout and design maybe. (jonnyB) * Tiki themes are much easier to do now ** IMO (Gary), it isn't really very hard to do a Tiki theme these days. Someone can easily modify a theme by using a theme option, or can start with an existing theme as a base (the new stylesheets are actually not very big files) and change the CSS properties to quickly come up with a totally new look. * Why so few themes being offered? ** Which leads to the question of why so few people are making themes and offering them to the community. IMO (Gary), it isn't because it is hard to make a Tiki theme. I suspect there are some fundamental differences between the Tiki userbase/"market" and those of, say, Joomla or Wordpress or Xoops that are behind this situation. ***For me it was a pain that the transitions from 2 to 4 broke most custom themes. ***lite didn't have all the flexibility i wanted, but now it seems you are mostly forced to use it. I bet this is confusing for would be developers. [[Just to clarify, lite.css (which creates Tiki's basic page column layout of floated divs) is imported by the theme stylesheet. If the designer doesn't want to use lite.css and instead handle laying out the columns some other way, just leave out the import statement, so it's trivial to avoid lite.css. Same is true for layout.css and design.css.-Gary] ***a well documented version of skeleton would probably do the most to enable new themers. **** More comments in its tiki.tpl would be good, along with a wiki page describing the difference between this .tpl and the default tiki.tpl, so the designer can know what site functionality will be missing by using the Skeleton tiki.tpl, for one thing. ***the architecture of tiki "where does that code come from" is difficult to figure. [[The CSS can be identified using Firebug, etc., and the .tpls can be identified if the .tpl file start/end comment tags are turned on. ] ***tiki is complicated (full stop). [[True, it will never be a simple as a single-purpose application. -Gary] * Still, ease the path ** Not to say that things shouldn't be as easy as possible, the docs improved, the methods improved, etc. This is important for the people who ''are'' making the themes, whether for the Tiki package or one-offs for specific sites (not for distribution), at least. ** How about making themes be contained in a single directory? Seems extra work to have to have theme.css and theme/ dir separately (getting the templates accessible inside the styles dir might be tricky, but possible i think - jb). *** It'd be nice if a theme option could have its own templates, too, so if the work was done to put theme .tpl files in styles/, it'd be nice if the extra step(s) could be taken to make theme option .tpls accessible. !! To do * Find a better way to handle ((dev:print)) !! Questions * We have duplicate css just for print, are they different? If they are the same, shall we delete? * Can we reduce the number of css files? ** lite.css instructions could be moved to layout.css or design.css to reduce the number of css files to maintain and learn ** why is fixed_width a separate css? *** Apparently the logic that applies fixed_width includes fixed_width.css when the option is selected, but when the option is selected, body gets a fixedwidth class, so adding body.fixedwidth to all fixed_width CSS rules and putting the rules in layout.css and theme stylesheets as needed would enable the fixed_width.css file to be removed. ** Is admin.css going to be kept and stuff from design moved there? * A question also is whether multiple CSS files is really a problem, since they can be minified as one file with the Performance option. !! Long term dream goals * ((Tiki Theme Generator)) I (mlp) would say gradual improvements to site identity (and the addition of theme options) are best for non-web designers. for those who know css / graphic design a well documented css would be better than some complicated gadget thingy that did half of what you needed to do. !! Won't do What has been ruled out, and why?