Dave wrote:
On 3/6/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Dave wrote:
> On 3/1/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>> new 4.0 proposal to provide stylesheet overrides for weblogs
...http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Stylesheet+Overrides+for+Weblogs
>
> -1 on this proposal as written.
> I don't think editing a CSS style sheet is the UI we want to enabling
> theme customization. We can't expect users to know CSS. And there is
> no standard set of CSS styles for each theme, so users will have to
> examine HTML to figure out what styles can be set.
Okay, that's a valid point and on some level I agree that we can't
expect users to be CSS wizards, but lets step back for a second and at
least agree that we need some sort of strategy for allowing styling
customizations of themes. And by styling customizations I mainly mean
choosing a different color palette and possibly some font changes.
"We can't expect users to know CSS."
To be honest I don't think that is true, and to an even larger degree I
don't think that users will need to know CSS. First off, in my mind
this is a proven approach when you consider that very large and popular
sites like WordPress and even MySpace allow custom styling in this exact
way, so if it works for them then I think it can work for us. Second,
and like the WordPress and MySpace examples, users wouldn't necessarily
have to code CSS themselves, they could share it, and that's a large
part of the benefit.
In fact, we have this exact use case in development right now. Some
members of the sun.com design team have offered to develop some new
themes for Roller and we specifically took the approach that each theme
would have a default design and then provide various alternate versions
simply by plugging in a new stylesheet. This was much more useful than
actually creating XX themes which are effectively the same but with
different styling. It would then be very easy to have users simply copy
and paste the alternate stylesheets into their custom stylesheet to
allow them to change to a new palette if they wanted.
Good points and I agree that with cut-and-paste sharing among users
the requirement to know CSS is lessened.
"there is no standard set of CSS styles for each theme"
True, but this is just a ramification of the way that Roller is
designed, we will never be able to enforce something like that in our
themes. However, the truth is that anyone running a Roller installation
could very easily enforce a standard set of CSS styles on all themes if
they wanted to. All you have to do is disable custom themes and then
make sure that the themes you provide do conform to any standards you
want to set. From James' response to this thread in another email it
sounds like he is planning to do this exact thing ...
"For a variety of reasons (e.g. security, accessibility standards,
branding, etc), we intend to lock down a users ability to reskin their
blog template and instead focus on the selection of customizations from
a preselected catalog."
And finally, I think it is also important to remember that this solution
is not mutually exclusive. This can be one part of multiple options the
user may have for customizing a shared theme and it does not preclude
other options from being present.
Good. My main object that I would not want this to be the one and only
solution to the ease of blog customization problem.
"-1 on this proposal as written."
So based on my response, what is it that you think needs to change in
the proposal to make it valid?
You've pretty much convinced me that this is a good thing, but you
should mention that this approach does not preclude other blog
customization improvements, such as theme properties and other things.
yep, i can add that to the proposal.
And ome more explanation of how the UI works would be good. You say
the override is just another page template, so I'm wondering:
- Can a user set a style override for a non-custom theme?
That is exactly what the proposal is supposed to be addressing, so
either I didn't explain things well in the proposal, or you may have
gotten a different idea of what I meant. In any case, the short answer
is "yes", that's the main purpose for the proposal.
The idea is that as a user I could select a shared theme from the
library, such as the "basic" theme, then modify the styling of that
theme by simply adding my own stylesheet. I wouldn't have to
"customize" the theme the way we do now and effectively copy the theme
templates. Instead I would continue to use the shared theme as usual,
but I would be capable of inserting my own styling decisions via the
stylesheet override. And I am proposing that by standardizing the way
this is done allows us to improve the usability for users by tailoring
the UI.
- What if theme customization is turned off and the Templates page is
hidden?
Well, that's not really a scenario I had considered since we don't
provide that as an option right now, but technically there is nothing
that would preclude us from doing that. What I meant by saying that the
override is just another page template was referring more to the
object/data model than to the UI. In the data model this stylesheet
override would be stored and accessed the same way that custom page
templates are done today, via the WeblogTemplate object and webpage
table, so we don't need to do any special work on the backend to support
this feature.
On the UI we can provide an entirely new page/form if we want, but it
would still be storing the custom stylesheet the same way we do with all
templates.
I'll add some more detail to the proposal and try and work up some
mockups of the way the UI could work as well, so there is more to look at.
-- Allen
I do agree with James Snell's comments about looking at the big
picture, but I guess we'll see that when you complete your other
proposals.
- Dave
