Thanks for the thoughtful response. Comments below...
On 12/4/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I have actually been thinking about this quite a bit and have a number
of thoughts, so I apologize in advance for how long winded this is ...
I think it would be good to get a little more discussion of exactly what
we think people want to be able to customize in a theme without having
to edit templates. I think you gave all the right examples, but I'll
try and group them into categories and add a little more detail ...
...
...
So if we consider that refined problem set I would say that I agree that
theme properties would solve the custom Images (#2) well and would be
adequate at solving for CSS customizations (#1). However, even though
theme properties would solve both of these situations I think there are
a number of potential pitfalls ...
1. There is nothing built-in to help ensure that themes are property
designed for customization. Since it's entirely up to the theme author
to define the set of available customizations then the potential
customization for the theme is up to the theme author. This seems risky
to me because if someone designs a really nice theme but doesn't offer
much in the way of customization then we are right back where we started
with users having to edit the templates to accomplish what they want.
Granted, that this may not actually happen that much, but it's an issue
of control. We have no way of ensuring that themes are built with an
adequate set of customizations.
I think leaving the set of configurables up to the theme author is a
very good thing. Let's not force complexity on theme authors or users.
If a theme developer wants to create a theme that is un-configurable,
then that's up to them. It's a free market for themes and if you
create a theme that sucks or is not sufficiently configurable, then
people won't use it.
2. Increased complexity in design and maintenance of themes. Creating a
theme for proper customization now takes a reasonable amount of
additional effort, especially for simple designers who aren't interested
in maintaining large sets of customization variables throughout their
templates. So theme designers are now taking on the additional
complexity of having to break down their designs and identify all the
potential customizations, convert them into variables, and that makes it
harder to work on themes. So as a designer you are no longer setting
colors, fonts, etc, in the templates but instead in the property
definition file. To me this sounds like a discouraging influence for
theme authors.
No. As a theme developer, you don't have to define properties unless
you want to make your theme configurable. You can still define a theme
that is un-configurable if that's what you want. Or, you might come up
with 50 configuration properties and make them all standard across all
of the themes you develop. If your themes become popular, then others
might even adopt or expect your properties as a standardized set.
We shouldn't dictate up-front what properties themes must support,
instead let's put the property infrastructure in-place to allow theme
developers to determine the best set of properties to use.
3. Duplicate properties. There is a potential for a theme author to
create a property which is either already provided as a built-in part of
Roller, or will become a built-in part of Roller in the future. For
example, the user profile picture. Right now, Roller doesn't manage
that as a built-in attribute of a user or weblog, so a theme author may
create a property for "user.image". But then in a future version of
Roller we add in that data as part of the set of built-in data and now
we have duplication. I think this becomes a point of confusion for
users because they then have 2 places to manage the same data and often
times that leads to questions like "well, i set XXX here, so why isn't
it showing up on my blog?"
That should be managed by the theme developer. In that case, users of
a theme will complain to the theme developer and ask him to use the
new Roller "user.image" property instead of the theme.userImage
property that he defined in his theme.
We do have do decide what happens when a new theme is installed or the
current theme is "re-applied" -- are all properties cleared or are
some subset of the settings imported into the new theme.
4. Limited control/validation of property input. Because the theme
properties are defined by the theme authors then we have a fairly
limited ability to do any kind of validation on data input for
properties. So for example, if a property takes a simple String value
then we have no way to A) ensure that the user inputs something valid
and useful to the them and B) we have no way to ensure that users don't
input something malicious for some reason.
That's why we must define some new types and create property editors
for those types. I proposed image, color and font. If the property
type "font" then the UI will show a nice font-picker. If the type of
"color" then a color picker will be shown. If the type is "image" with
constraints of 600x50, then an image picker UI will ensure that they
pick an appropriately sized image from the blog's resource directory.
5. Theme properties don't solve for Widgets, which I believe is
something that users are more interested in.
A little bird tells me that a separate proposal is on the way for
sidebar widgets ;-)
So, while I think that this proposal would work to solve part of the
problem of easing template customization, in general I am not really
sold on this specific approach. The biggest cons for me being that we
are making theme design more complicated yet still not ensuring that we
are providing all the customizations that users want, and that this
doesn't solve for Widgets at all, which I think is what I think users
want most of all.
I really like the breakdown on approaches to customization that you
blogged about and I would say that IMO we would be better off working on
the Widgets thing first. I think that is something that would have a
much higher value for most users and would also provide an immediate
benefit to all Roller blogs, even existing ones. So I might suggest
that we think about focusing this effort more on solving that part of
the problem first, before doing the theme properties or other ways of
solving for images/css customizations.
I believe that theme properties + widgets can solve 95% of the problem.
- Dave
Dave wrote:
> One of the things that new bloggers tend to complain about is theme
> customization. It's just too hard to customize the look and feel of
> your blog. And that's true even if you just want to make a couple of
> minor tweaks like changing a banner image, changing a background color
> or adding a "widget" to your sidebar (e.g. a Flickr badge of most
> recent photos or an RSS listing of recent links from del.icio.us).
>
> With Roller and most other blog servers I've used, you can configure
> some aspects of your blog's layout and appearance via a web UI with no
> HTML, CSS or template coding.
>
> With Roller and others, you can configure these things:
>
> * Change blog title and description
> * Configure the number of posts displayed on main page
> * Change from one stock theme to another
> * Add links to your blogroll
> * Add new categories to your blog
>
> For everything else, you must customize, i.e. edit templates and deal
> with HTML, CSS and a specialized template language. For non-geeks,
> that can be pretty daunting. We should improve this situation by
> making it possible for theme designers to make common customizations
> easy -- i.e. to allow a user to configure a theme via a nice friendly
> UI rather than customizing it via template editing.
>
> Read the rest here:
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ThemeProperties
>
> Please respond with comments here on the list.
>
> - Dave
