Ross wrote
I will make this point one last time and then keep quiet about it.
I'd rather you didn't keep quiet. Your opinion is critical in this.
OK, since you asked for it :-)
1. End users
...
So why not make it easier for these people (and win broader support) as long as it doesn't mean making compromises on quality.
I'm all for making it easier, but I disagree with *how* it is made easier. I would prefer it if an end-user could pick up forrest and build a simple, standard site *without* looking at *any* docs other than a 3 line install and run description.
To achieve this we need helper tools, not different documentation (of course, it is not as clearly separated as this, *some* documentation will always be needed for the end-user).
2. Technical users
I question the fact that Forrest is currently easy to understand for technical users. I think it is only easy to understand for people with a cocoon background!
Without an understanding of Cocoon pipelines, generators, transformers, serialisers, matchers, etc. etc. they won't get very far in Forrest. It is possible to do some skin customisation without Cocoon knowledge, but you can't do anything else. If you can find a way around this then that is great.
Sure, (non-technical) end-users have been empowered by the plugins, but why bother explaining to them how to configure forrest.properties, or forrest.xml or forrest.conf.xml or whatever we name it. Wouldn't it be better to have a script or gui that said "this plugin does XYZ, do you wnat to use it?" Then they don't care what the file is called.
3. GUI
...
However I would really like working towards making Forrest a system where non-technical power users have a chance to throw away their gui-crutches at some point and work with the whole flexibility of Forrest below.
This blurs the distinction between non-technical end-users and technical users. What is a "power" user? How do we define one? What will they be doing with Forrest?
If they simply want to configure the way Forrest works by employing verious plugins and perhaps configuring their skin then a set of scripts/guis are what are need, coupled with clear documentation about the skinning system.
If they want to make Forrest do something that it can't already do they will have to learn about the Cocoon way of doing things because Forrest is a Cocoon app. That makes them a technical user - or at least someone willing to become a technical user. They will then need to read Cocoon docs as well as our own.
---
I am still +1 on anything that makes it easier for end-users. This includes, but is not limited to, renaming build targets to enable clearer docs to be written, or (preferably) building helper scripts that remove the need for the end-user to know the target names. These scipts can then be written from the perspective of an end user and the underlying framework can stick with the terminology used by the devs. Furthermore these scripts can be used in the Eclipse plugin (which, incidentally, already has a basic wizard for creating a new site).
I'm still -1 on changing the names of the configu files etc. we need to stay close to the nearest thing we have to "standards", that is we need to see the underlying structure of Forrest continuing to look like a Cocoon application. I pick on "a Cocoon appication" as our standard because that is what Forrest is, and very often we find ourselves referring technical users to Cocoon docs. It would therefore make sense for files to be named the same and located in the same locations as documented in those docs.
P.S.
All this does not mean that all the changes I suggested serve that goal. That I'm happy to discuss and question any time.
Yes, I'll return to those threads when we are agreed on who we are targetting and what our aims in the resturcuting is.
Ross
