You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave <sn...@gmail.com> on 2006/12/04 23:02:20 UTC
Proposal_ThemeProperties
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
Re: Proposal_ThemeProperties
Posted by Allen Gilliland <al...@sun.com>.
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 <al...@sun.com> 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
Re: Proposal_ThemeProperties
Posted by Dave <sn...@gmail.com>.
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 <al...@sun.com> 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.
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.
> 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.
> 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.
> 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?
- Dave
Re: Proposal_ThemeProperties
Posted by Allen Gilliland <al...@sun.com>.
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. 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.
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. I believe there are alternatives out there
that we may not have considered yet which will solve this in a more
robust way.
-- Allen
Dave wrote:
> Thanks for the thoughtful response. Comments below...
>
>
> On 12/4/06, Allen Gilliland <al...@sun.com> 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
>>
Re: Proposal_ThemeProperties
Posted by Dave <sn...@gmail.com>.
Thanks for the thoughtful response. Comments below...
On 12/4/06, Allen Gilliland <al...@sun.com> 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
>
Re: Proposal_ThemeProperties
Posted by Allen Gilliland <al...@sun.com>.
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 ...
1. CSS - this could be as simple as some color changes and maybe font
types, or as complex as allowing full css customization. i consider
this to represent a moderate portion of the customizations. i also
think this one is the most tricky because there are a *lot* of potential
items worth customizing when it comes to css and hard to ensure we are
capturing all the right ones.
2. Images - places where people want to insert their own image to be
used in a specific place in a theme, like in the header or sidebar, or
maybe an icon posted next to each entry title, etc. i would consider
this to represent a small part of the customizations. there are
probably a handful of situations for this one which will make up 95% of
the use cases.
3. Widgets - these are more complex components which add some kind of
new element to the page, like a flickr photos section, or technorati
info, del.icio.us tag cloud, blogroll, music selections, recent books
read, etc, etc. i think this represents the largest set of desired
customizations and represents for the most part what users are looking for.
4. Layout - this is technically CSS and is dependent on how the html is
setup, but basically represents the scenario where someone has a theme
that they basically like but want to change it from a 2 col to 3 col
layout, or move the sidebar from one side to the other, etc. i think
this represents a very small section of desired customizations.
As you said in the proposal, using theme properties will not solve the
situation for Widgets (#3) and I would also say that it would be very
hard to solve the Layout customizations (#4), so I would claim this
proposal is for solving the CSS and Image customizations.
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.
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.
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?"
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.
5. Theme properties don't solve for Widgets, which I believe is
something that users are more interested in.
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.
-- Allen
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