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
