forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <>
Subject Re: Selective PDF
Date Mon, 15 Nov 2004 07:02:10 GMT
On Sunday 14 November 2004 23:58, Ross Gardler wrote:
> Sean Wheller wrote:
> > On Sunday 14 November 2004 19:39, Ross Gardler wrote:
> >>Sean Wheller wrote:
> >>>Is it not easier to define an attribute such as "output" and add it to
> >>>elements in site.xml and tabs.xml. The values can be on error more of
> >>> the following: output="all,ps,rtfpdf,pod"
> >>
> >>Yes, this is a good idea, this is similar to the meta-data idea but it
> >>feels like a more logical place to put it.
> >>
> >>The only problem I see is that it requires us to specify when we *do*
> >>want something, rather than when we *don't*. This is a problem for two
> >>reasons, firstly it is more likely that we will want the various output
> >>forms (and so we are increasing the typing required in most cases),
> >>secondly, it requires us to know in advance what output formats will be
> >>available.
> >
> > <element>
> >       Applied to all siblings. No output formats
> > </element>
> <snip what="other examples"/>
> These break backwards computability, something we cannot do (unless
> absolutely necessary). Any solution we implment must be compatable with
> existing behavior. Here you are ignoring what is defined in skinconf.xml
> thus forcing all existing sites to edit both their skinconf.xml files
> and thiir site.xml files.

I don't think this is breaking backwards computability. At present, site.xml 
is sans any output and my proposal is to enable the user to add it. Since 
this feature is optional, there can be no breaking backwards computability. 
The site.xml is the same as it is now.

As for existing behavior. I feel that behavior should be replace by better 
behavior. If we cannot replace existing behavior with improved solutions then 
what's the point.

I've said in the past that Forrest is good, but that it lacks the ability to 
be a flexible and robust solution. This is one more example.

> > I think the level of control far out weighs the overhead of some extra
> > typing.
> I'm not sure about that, we have to think of the average user, I should
> really have said something like "we are making the learning curve
> steeper for new users", mentioing the amount of typing was perhaps a bit
> of a red-herring (although still a consideration).
> We need to switch focus, rather than specify what we *do* want we simply
> specify what we *don't* want and assume everything else is wanted...

Can we define the user profile that is considered "average user?"

My experience with the average user is that they will not use forrest. The 
current system is way past the average user. If the average user could use 
forrest then we would have many more example sites. The user that I belive 
uses forrest is normally from a web admin or net admin background. Authors 
such as myself are here because we have knowledge of XML and XSLT. These 
people are not average.

Much of the documentation does not profile the average user, 90% of the tasks 
explained in documentation are way beyond what the average user wants to get 
involved with. The average user profile ends on the first page. The average 
user wants install, copy files, and forrest run.

Now don't get me wrong, I am all for making things as simple possible, but I 
don't feel that attaining this goal should come at the cost of reduced 

The solution today requires a person to edit both site.xml and tab.xml. This 
is because a person wants their own tabs and menus. In fact, I have yet to 
find an instance where the structures of these files have not been either 
modified or completely rewritten.

The main place where an "average user" spends their time is in site.xml, then 
comes tabs.xml. I say this because each time they add content, these files 
may be modified.

> > We may also consider
> >
> > <site output="all">
> > ...
> > </site>
> >
> > <site output="pdf">
> > <element output="rtf">
> >       Inherit value of parent and do rtf to all siblings
> >       <sibling output="pod"/>
> >       Inherit value of parent and ancestor and do pod
> > </element>
> > </site>
> The <site output="pdf"> portion is already defined in skinconf.xml, that
> is the properties in skinconf should define the default behaviour for
> the site, i.e. what we *do* want. This is working well in a great many
> users sites already so we cannot break it (without good reason).

Yes, this is in skinconf.xml. I just wanted to show that it does not have to 
be there.

IMHO, skinning has to do with look and feel and not to do with deciding what 
target outputs are delivered. The skin does not need to know this 

Now site.xml is also not about target formats, but it is the place where the 
most structure is defined. If we want to be exact then it should be, but hey .... who wants to duplicate data to when we don't want to do so for skinconf.xml. As you say, 
the most logical point is site.xml.

As I say, since people are going to edit it anyway, it makes sense. I don't 
believe it is making things more complex. The file will be edited anyway. I 
your average user can edit this file, then the average user can add, modify 
or remove an attribute. I actually think it is easier and provides granular 

> Now we are back at square one - it is no longer possible to exclude
> certain files from having pdf generated. Is there another way? I think
> there is, if we look at it the other way around - specify what we don't
> want we get:
> <site>
>   <main nooutput="pod">
>     ...
>   </main>
>   <docs>
>     <index nooutput="pdf"/>
>     <howto/>
>   </docs>
> </site>
> The above would create all skinconf.xml defined output formats for the
> howto element, but would not create pdf output for the docs index, nor
> would it create pod output for the items in main.
> This minimises the learning curve (user doesn't need to do anything
> unless they want to configure things), we maintain backward
> compatability (skinconf.xml still defines the default behaviour) and we
> maintain the flexibility you create in your proposal.

The natural brain thinks in terms of what it wants. Usability studies show 
this. In addition, now I must open skinconf.xml see the settings and go 
remove their result in site.xml by adding to the file. That's reverse 
thinking. Do you believe this is the way an average user thinks?

In many cases comments in the files tell you to add this attribute to do this 
if the skins supports it. Why not here?

"To enable output formats add the output attribute to any element. Values for 
output formats include pdf, rtf, ps, txt, xml, pod. You may specify any 
number of values as a comma-separated list. Elements inherit the output value 
of their ancestors. output="pdf,rtf,ps,txt,xml,pod"."

The average user can see the outline of their site, the implied directory 
structures, target links and the target outputs, in one place. + they can 
customize what comes in what format.

Sean Wheller
Technical Author

View raw message