History: Roadmap

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.
    • a well documented version of skeleton would probably do the most to enable new themers.
    • the architecture of tiki "where does that code come from" is difficult to figure.
    • tiki is complicated (full stop).

• 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 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?
    • Probably this is an artifact that should be corrected.
  • 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

• TikiThemeGenerator

I (mlp) would say gradual improvements to site identity 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?