Dave wrote:
I've done a little more thinking about this and I've take a look at
Blojsom (Java) and Serendipity (PHP), which was suggested by Sean
Gilligan. I didn't see anything of interest in Blojsom, but
Serendipity had a couple of nice ideas.
First of all, they provide a default theme CSS file, which includes
all CSS classes generated by the system and includes comments that
explain the purpose of each class. I'm planning on doing this for
Roller next week.
Default theme stylesheet commented
http://www.s9y.org/122.html
For templates, Serendipity uses the Smarty template engine and they
put a bunch of variables into context, no surprises here.
Smarty
http://smarty.php.net/
CSS classes / Variable Documentation
http://www.s9y.org/102.html
They also allow the configuration of theme options, which is very
similar to the theme properties approach I am proposing -- except they
don't have a property definition fine that defines the types and
allowed values necessary to present a slick config UI.
Configuration of Theme options
http://www.s9y.org/137.html
And to respond to Allen's last email on the topic...
On 12/5/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I am glad to hear that there is already a Widgets proposal on the way
because I am far more interested in seeing us accomplish that.
But about the theme properties again, you said twice below that you
think it's a good thing that theme authors get to decide what properties
are configurable and that they don't have to provide properties if they
don't want to, but I don't fully agree with that. To me the point of
this proposal is to provide some way of ensuring that the themes people
will develop for Roller in the future will be user friendly such that
they can be customized to some degree without having to edit their
templates directly.
I disagree with that. We need to keep theme creation simple and no put
an undue burden on theme developers who just want to throw together a
simple theme with no configurable parts.
Okay, but you can't deny that a theme with none of these theme
properties is no different then what we have now. I didn't say we need
to force theme authors to make their themes customizable, I merely said
that I think we should be trying to find a solution which makes it easy
enough for theme authors to make their theme customizable that there is
no reason not to do so and I don't think that theme properties will
accomplish that.
The point of the proposal is to put in place a system that can enables
the creation of customizable themes that can be customized very easily
with a nice web UI with "pickers" for colors, fonts and images. Theme
authors can choose to use this system or not. The themes that provide
the best appearance and appropriate level of configurability will win
out.
A big site like blogs.sun.com could choose to develop a family of
themes that all use the same CSS classes and for consistency the same
configuration properties. But other sites could choose to build themes
that use a different set of properties. We can't imagine all the ways
that theme authors might want to make their themes configurable, so we
shouldn't mandate configurabilty.
But when you talk about a "site like blogs.sun.com" who are you talking
about? You are probably talking about me and you, which are the main
programmers for this application and obviously we can properly develop
themes given the technology that we designed.
What I am saying is that I don't believe that from the point of view of
non-technical users and theme authors that these theme properties will
actually make anything that much easier. As I said previously, I think
that casual theme authors will struggle with using these theme
properties and properly putting them into themes.
In fact, we saw this just recently when a couple people tried to create
new themes for Roller to be used on BSC and they were good designers
from an HTML/css/js point of view, but they struggled with the Roller
templating system and needed a fair amount of help. Adding in theme
properties will only make that experience even more difficult and error
prone.
IMO there is no real incentive to get theme
developers to develop these theme properties into their themes and if
they aren't doing it then we have gained almost nothing. I will agree
that theme properties do solve the technical problem of how to maintain
some configurable data to be used in a theme, but it does not really
encourage themes to be easily built for configurability.
No. We will have gained "system that can enables the creation of
customizable themes that can be customized..." -- that is not nothing.
And the cool configuration UI will most definitely encourage theme
authors to expose configuration properties. All they have to do is
define a couple of properties in an XML file and then use them in the
theme.
I had already agreed that technically theme properties will accomplish
what you want, but I also said that they come with a number of problems
and ultimately I don't think they solve the problem in a way that is
convincingly easy for users and theme authors.
You say "all they have to do ..." but those are dangerous words. I was
just reminded a couple days ago of exactly how confusing some of the
things we do can be to non-technical users when someone asked me, "how
can i put a link in my blog entry?". We are talking about the most
simple thing in the world in our eyes, adding an <a></a> anchor to a bit
of text, but this user wasn't able to figure that out on their own using
our interface. So to me the prospect of ...
1. using xml to define XX number of properties in a theme config file
2. developing your theme templates to use the specific variable names
that you defined in #1 throughout your templates
3. testing that all the properties show up correctly on the Roller UI
for modifying theme properties
4. testing that if each property is given a custom value that it does
the right thing on the theme
is not as simple as "all they have to do ..."
I *know* that some level of complexity will be required, but I have been
of the opinion that this proposal offers a solution which is more
complex than is desirable.
Another reason why I am still very hesitant to do theme properties is
that once we introduce this feature there is no turning back. We will
likely never have a way to go back and remove this feature if we decide
it didn't work out as well as we wanted because peoples themes will be
reliant on the properties. So I want to make absolutely sure that this
is the very best way to solve this problem before we introduce it, and
so far I am not convinced.
That's going to be true of pretty much any solution to this problem.
With APIs, page models and macros we need to step very carefully as
you suggest.
And that is the main point I am trying to make. This proposal has not
convinced me that this is the best solution we can come up with.
I believe there are alternatives out there
that we may not have considered yet which will solve this in a more
robust way.
The only one we've discussed thus far is Sidebar Widgets, which
combined with theme properties solve the problem IMHO but alone they
don't come close. Have you come up with any other alternatives since
we last corresponded?
The sidebar widgets is a different problem from this one IMO. They are
related, but different enough that they don't need to be considered
together. I still suggest we do the widgets work first, for all the
reasons I had listed previously. While we are doing that we can
continue investigating solutions to this problem.
No, I haven't come up with any specific alternatives.
One thing I have thought about which is probably a separate discussion
but I'll throw it out anyways, is that IMO Velocity is not a good fit to
be our templating engine. The more I use Velocity the less I like it
and it's become quite clear to me that Velocity is not well suited for
our users. I think it works fine for developers and people with simple
technical skills, but for truly non-technical end users we could be
making things a lot easier with a better templating language.
So one suggestion I have is to look into the idea of replacing Velocity
with something better. IMO Roller will probably never be on the same
level as the other big blog software out there until our usability
increases dramatically, and one major component of that will be to have
a better templating language for non-technical users to be able to make
some sense out of.
-- Allen
- Dave
