Proposal: Theme XML Descriptor

[Allen Gilliland <al...@sun.com>]

I'd like to continue down the road towards improving Roller's theme 
support and I think the next step that needs to be taken is to create 
and XML theme descriptor for themes.  This will allow packaged themes to 
do many more interesting things and ultimately make it possible for 
themes to be more shared and imported/exported directly from weblogs.

Proposal is on this wiki ...

http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Theme+XML+Descriptor

comments?  this would be scheduled for addition in Roller 4.0.

-- Allen

Re: Proposal: Theme XML Descriptor

[Dave <sn...@gmail.com>]

On 2/22/07, Allen Gilliland <al...@sun.com> wrote:
>
>
> Dave wrote:
> > On 2/22/07, Allen Gilliland <al...@sun.com> wrote:
> >> Dave wrote:
> >> I would add that the only thing that kind of sucks about that is that
> >> expecting most users to understand content types is a bit of a stretch
> >> in my mind.  So the benefit of the current solution where we just lookup
> >> the content type based on the file extension used in the "link" value of
> >> the template is that it keeps things simple for users.
> >>
> >> Having to see a field marked "Content Type" with a value of "text/css"
> >> on the template editing form for a css template may cause more problems
> >> than it will solve.  If people start to hack at it without knowing what
> >> they are doing then they can break things.
> >
> > That's true and so we'll have to be careful how we expose it in the
> > UI. For example we might want a combobox with options like:
> >
> >   Web page (text/html)
> >   CSS file (text/css)
> >   Custom...
> >
> > Where custom leads to popup that allows a custom content-type. That
> > could even be hidden away in an advanced settings area similar to
> > those on the edit-entry page.
>
> yep, those both sound like good ways to deal with it.
>
>
> >
> >
> >> So we may want to ask how often we think people need to create custom
> >> templates where they need to set a custom content type which can't be
> >> accomplished by using a file extension?
> >
> > Content-type is the standard and "right thing" to do here. You can't
> > rely of file extensions in general and I've got specific problems with
> > them. I'm creating pages that generate feeds so I need
> > application/xml+rss and application/xml+atom. And I need
> > application/json for JSON. My ISP controlled server is not setup to
> > map .atom, .rss or .json so file extensions are useless to me and I
> > think that's a pretty common situation for bloggers.
>
> gotcha.  i agree that content types are the right thing to do, i just
> want to make sure we are thinking about the right way to introduce them.
>
> in the past i think we have all been guilty ( me included :/ ) of just
> dumping features into the app without developing good UX around them and
> i think that Roller is mature enough now that we really need to be
> better about that kind of stuff.  there are still lots of good features
> to be added to Roller, but one of the things i know i want to focus on
> in the 4.x series (and hopefully others do to) is to really refine what
> we have now and make it as complete and mature as possible, and a lot of
> that will mean focusing on UX.

I agree. We need to focus on UI and 4.0 is the starting point for that
now that we have Struts2 in place. There are way too many places where
the UI is partial, inconsistent, ugly or all of the above.

If you add in content-type, I'm willing to do the UI work to support it.

- Dave

Re: Proposal: Theme XML Descriptor

[Robert Yates <ro...@gmail.com>]

One of the things that came up in our user testing was the rather
confusing "home" templates.  i.e. those templates that really only
work on the front page blog.

A lot of our users would choose them and then get horribly confused
when nothing worked.  Could we somehow seperate them so that they only
show up for admins?  We are going to implement a solution here prior
to ship and the best we can think of at the moment is a seperate
directory, thoughts?

Rob

p.s. while we are on the topic of UX :)  Can we get rid of the summary
text box when entering the blog post.  It confused the heck out of
most users and I have yet to meet an expert user that actually types a
summary that is different from the one generated by Roller
p.p.s. this is what we have done for our Dojo editor (which again,
once we get this danged approval you are welcome to)

Re: Proposal: Theme XML Descriptor

[Allen Gilliland <al...@sun.com>]

Dave wrote:
> On 2/22/07, Allen Gilliland <al...@sun.com> wrote:
>> Dave wrote:
>> I would add that the only thing that kind of sucks about that is that
>> expecting most users to understand content types is a bit of a stretch
>> in my mind.  So the benefit of the current solution where we just lookup
>> the content type based on the file extension used in the "link" value of
>> the template is that it keeps things simple for users.
>>
>> Having to see a field marked "Content Type" with a value of "text/css"
>> on the template editing form for a css template may cause more problems
>> than it will solve.  If people start to hack at it without knowing what
>> they are doing then they can break things.
> 
> That's true and so we'll have to be careful how we expose it in the
> UI. For example we might want a combobox with options like:
> 
>   Web page (text/html)
>   CSS file (text/css)
>   Custom...
> 
> Where custom leads to popup that allows a custom content-type. That
> could even be hidden away in an advanced settings area similar to
> those on the edit-entry page.

yep, those both sound like good ways to deal with it.


> 
> 
>> So we may want to ask how often we think people need to create custom
>> templates where they need to set a custom content type which can't be
>> accomplished by using a file extension?
> 
> Content-type is the standard and "right thing" to do here. You can't
> rely of file extensions in general and I've got specific problems with
> them. I'm creating pages that generate feeds so I need
> application/xml+rss and application/xml+atom. And I need
> application/json for JSON. My ISP controlled server is not setup to
> map .atom, .rss or .json so file extensions are useless to me and I
> think that's a pretty common situation for bloggers.

gotcha.  i agree that content types are the right thing to do, i just 
want to make sure we are thinking about the right way to introduce them.

in the past i think we have all been guilty ( me included :/ ) of just 
dumping features into the app without developing good UX around them and 
i think that Roller is mature enough now that we really need to be 
better about that kind of stuff.  there are still lots of good features 
to be added to Roller, but one of the things i know i want to focus on 
in the 4.x series (and hopefully others do to) is to really refine what 
we have now and make it as complete and mature as possible, and a lot of 
that will mean focusing on UX.

-- Allen


> 
> - Dave

Re: Proposal: Theme XML Descriptor

[Dave <sn...@gmail.com>]

On 2/22/07, Allen Gilliland <al...@sun.com> wrote:
> Dave wrote:
> I would add that the only thing that kind of sucks about that is that
> expecting most users to understand content types is a bit of a stretch
> in my mind.  So the benefit of the current solution where we just lookup
> the content type based on the file extension used in the "link" value of
> the template is that it keeps things simple for users.
>
> Having to see a field marked "Content Type" with a value of "text/css"
> on the template editing form for a css template may cause more problems
> than it will solve.  If people start to hack at it without knowing what
> they are doing then they can break things.

That's true and so we'll have to be careful how we expose it in the
UI. For example we might want a combobox with options like:

   Web page (text/html)
   CSS file (text/css)
   Custom...

Where custom leads to popup that allows a custom content-type. That
could even be hidden away in an advanced settings area similar to
those on the edit-entry page.


> So we may want to ask how often we think people need to create custom
> templates where they need to set a custom content type which can't be
> accomplished by using a file extension?

Content-type is the standard and "right thing" to do here. You can't
rely of file extensions in general and I've got specific problems with
them. I'm creating pages that generate feeds so I need
application/xml+rss and application/xml+atom. And I need
application/json for JSON. My ISP controlled server is not setup to
map .atom, .rss or .json so file extensions are useless to me and I
think that's a pretty common situation for bloggers.

- Dave

Re: Proposal: Theme XML Descriptor

[Allen Gilliland <al...@sun.com>]

Dave wrote:
> On 2/22/07, Allen Gilliland <al...@sun.com> wrote:
>> I'd like to continue down the road towards improving Roller's theme
>> support and I think the next step that needs to be taken is to create
>> and XML theme descriptor for themes.  This will allow packaged themes to
>> do many more interesting things and ultimately make it possible for
>> themes to be more shared and imported/exported directly from weblogs.
>>
>> Proposal is on this wiki ...
>>
>> http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Theme+XML+Descriptor 
>>
>>
>> comments?  this would be scheduled for addition in Roller 4.0.
> 
> I like it, but I'd like to propose that we add a contentType field to
> the Template object. We need to know what content type is to be
> generated by the template and we should have to rely on a a file
> extension or web server setup to provide that info.

makes sense.

I would add that the only thing that kind of sucks about that is that 
expecting most users to understand content types is a bit of a stretch 
in my mind.  So the benefit of the current solution where we just lookup 
the content type based on the file extension used in the "link" value of 
the template is that it keeps things simple for users.

Having to see a field marked "Content Type" with a value of "text/css" 
on the template editing form for a css template may cause more problems 
than it will solve.  If people start to hack at it without knowing what 
they are doing then they can break things.

So we may want to ask how often we think people need to create custom 
templates where they need to set a custom content type which can't be 
accomplished by using a file extension?

-- Allen


> 
> - Dave

Re: Proposal: Theme XML Descriptor

[Dave <sn...@gmail.com>]

On 2/22/07, Allen Gilliland <al...@sun.com> wrote:
> I'd like to continue down the road towards improving Roller's theme
> support and I think the next step that needs to be taken is to create
> and XML theme descriptor for themes.  This will allow packaged themes to
> do many more interesting things and ultimately make it possible for
> themes to be more shared and imported/exported directly from weblogs.
>
> Proposal is on this wiki ...
>
> http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Theme+XML+Descriptor
>
> comments?  this would be scheduled for addition in Roller 4.0.

I like it, but I'd like to propose that we add a contentType field to
the Template object. We need to know what content type is to be
generated by the template and we should have to rely on a a file
extension or web server setup to provide that info.

- Dave