entry points [was:Re: Ok, I give up]

[Diana Shannon <te...@mac.com>]

Robert:

> How about defining different entry points to cocoon. Example tracks:
> 1. total newbie - very basic stuff to get them started
> 2. experienced web developer but inexperienced at java or XSLT
> 3. experienced web developer with java but inexperienced with XSLT
> 4. inexperienced (serious) web developer that knows XSLT well
> 5. ???

Very good idea. We could develop audience profiles for these groups that 
include assumptions about concepts most likely to need reinforcement, 
based on pre-Cocoon preconceptions. This stuff pops up all the time on 
the user list, like folks wanting to override a serialization 
configuration from a stylesheet's xml:output method.

> Everybody seems to be coming from cocoon at different angles. Define 
> what is common to all and then split out to the entry points.

Couldn't agree with you more. However, Cocoon as "glue technology" has 
an extremely varied potential user base. Also, think about how many 
flavors of experienced web developer types there are. I'm not saying it 
shouldn't/couldn't be done, but the audience comes with a lot of 
potential "baggage."

> For something like #4, speaking from experience, I would like to see 
> how you take an app that uses the XSLT/XPath document function to 
> aggregate content and turn that into a cocoon app that aggregates 
> content before the final transformation.  I could provide the XSLT/XML 
> that aggregates content in the final transform using document(), but I 
> would not trust myself to give the best cocoon conversion :(

So how does that translate, ideally, into documents that fill up a 
learning path? Is this a tutorial directed specifically at audience #4? 
Or a combination of documents? If so, what types of documents?

Diana

Re: entry points [was:Re: Ok, I give up]

[Stefano Mazzocchi <st...@apache.org>]

Robert Koberg wrote:

> > Couldn't agree with you more. However, Cocoon as "glue technology" has
> > an extremely varied potential user base.
> 
> Yes, that was what I was trying to address.

Ehm, people: this list is supposed to talk to an instrstructure system
about documents, *not* about some 'cocoon' specific documentation
contents.

Please, let's move this over to Cocoon-dev, thanks.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

Re: entry points [was:Re: Ok, I give up]

[Robert Koberg <ro...@koberg.com>]

Diana Shannon wrote:

> Robert:
>
>> How about defining different entry points to cocoon. Example tracks:
>> 1. total newbie - very basic stuff to get them started
>> 2. experienced web developer but inexperienced at java or XSLT
>> 3. experienced web developer with java but inexperienced with XSLT
>> 4. inexperienced (serious) web developer that knows XSLT well
>> 5. ???
>
>
> Very good idea. We could develop audience profiles for these groups 
> that include assumptions about concepts most likely to need 
> reinforcement, based on pre-Cocoon preconceptions. This stuff pops up 
> all the time on the user list, like folks wanting to override a 
> serialization configuration from a stylesheet's xml:output method.
>
>> Everybody seems to be coming from cocoon at different angles. Define 
>> what is common to all and then split out to the entry points.
>
>
> Couldn't agree with you more. However, Cocoon as "glue technology" has 
> an extremely varied potential user base. 

Yes, that was what I was trying to address.

> Also, think about how many flavors of experienced web developer types 
> there are. I'm not saying it shouldn't/couldn't be done, but the 
> audience comes with a lot of potential "baggage."


I would keep #2 as generic as possible. Over time, the users can fill in 
the bulk of the specifics for a particular way in. I personally f�,�
this level of involvement would need a hierarchical organization of 
contributors - not common ownership... hence some type of user 
management. But that could be put off well into the future, I guess, 
until there is a solid system in place.

>
>
>> For something like #4, speaking from experience, I would like to see 
>> how you take an app that uses the XSLT/XPath document function to 
>> aggregate content and turn that into a cocoon app that aggregates 
>> content before the final transformation.  I could provide the 
>> XSLT/XML that aggregates content in the final transform using 
>> document(), but I would not trust myself to give the best cocoon 
>> conversion :(
>
>
> So how does that translate, ideally, into documents that fill up a 
> learning path? Is this a tutorial directed specifically at audience 
> #4? Or a combination of documents? If so, what types of documents?

I tried to use that as an example of - "here's how you do it with XYZ 
technology" - "and here is how we would optimize it for/with cocoon." I 
guess it would be a tutorial/philosophy thing.

Perhaps there is a page - "What do you want to do with Cocoon?" That 
page is set up to look like a well organized FAQ that strings the user 
out to something that they recognize. The path explores how they would 
normally do things and compares that to how it should be done in cocoon 
(always linking to more details). After they get exposed to cocoon in a 
light that allows them to see, the path takes them into the common 
cocoon learning/docs. That path brings them to the central idea of 
cocoon with respect to their needs.

best,
-Rob