Re: Feature sets [was Re: Templating System]

[Jonathan Swartz <sw...@transbay.net>]

Drew Taylor wrote: 
>Ken Williams wrote:
>> 
>> I suggest having not just a simple checkmark, but a 3-way check.  A
>> system either supports a feature, or it doesn't, or it *optionally*
>> supports it (can be switched on and off).  This is often very helpful to
>> know, and might let one get a good sense of the differences between
>> various systems at a glance.
>Another great idea! Should we go one farther and have a checkbox for
>"coming in next version", or is that going to far? I'm thinking it is
>too easy to get wrapped up in "forward looking statements" by having
>"coming soon".

Although I feel that Mason would do adequately in a feature
comparison, I have to say that feature checklists scare me. The reason
that they're most often seen in ads and back-of-the-box marketing
blurbs is their potential for deception:

(1) the set of features you choose, no matter how impartial,
bias the results
(2) a binary check value (even three or four check values)
conveys way too little information
(3) in software especially there is a fine distinction between a
feature being "built into" versus "supported by" a product

Case in point: session handling. I grind my teeth everytime I hear that 
"Mason doesn't have built-in session handling".  Right, and it doesn't have 
built-in arithmetic processing either. It relies on Apache::Session and the 
Perl interpreter, respectively, for these features.

Yet I've often been tempted, for marketing purposes, to add a 
"use_session" option to Mason that simply brings in Apache::Session with 
a few lines of glue code, so I could boast built-in session handling. If I 
were selling a product I'm sure I'd do this. One of the reasons I like the 
open source world is that I don't have to resort to this level of chicanery.

I guess I'm just cautioning the makers of this feature list to choose
the display format carefully so as to minimize information loss.

Maybe each template package should get one page with standardized
format and questions (what features do you have, what are your system
and memory requirements, what does a sample page look like, etc.). 
That way people could flip back and forth through the pages and get a
sense of comparison, and the authors would get to focus on what they
consider most important.

Jon

Re: Feature sets [was Re: Templating System]

[Ken Williams <ke...@forum.swarthmore.edu>]

gunther@extropia.com (Gunther Birznieks) wrote:
>I am afraid that while I agree, a check system is really quite useful to 
>me. Some things do need more quantification, but that can be done later.
>
>eg lightweight vs heavyweight is subjective. But it can be broken up into 
>saying something like how much code needs to be loaded at start time (an 
>issue for CGI/Perl). eg I think people would agree that the startup of 
>CGI.pm is different from CGI::Lite which is different from cgi-lib.pl. Of 
>course, there are many other features that you get from them that can make 
>a difference in your program.
>
>Anyway, that is why this checklist is being designed by all of you and 
>handled by an independent 3rd party. It's not a marketing tool. So if you 
>complain about session support being a checkbox, I am sure that the feature 
>name could be refined.

I agree.  I came up with an initial set of checkboxes (posted here last
week), but I'd have no qualms about some author wanting to ditch some of
those.  I think a useful comparison would use feature comparisons only
as a means of revealing the comparitive philosophies of the systems.

Gunther, has anyone found a good home for such a comparison to be
hosted?  It would be cool if it were at perl.apache.org, or even better
at www.perl.com or something (since it's not mod_perl specific).  As
long as it's easily updatable by its maintainers (and who are they?).

Re: Feature sets [was Re: Templating System]

[Gunther Birznieks <gu...@extropia.com>]

I am afraid that while I agree, a check system is really quite useful to 
me. Some things do need more quantification, but that can be done later.

eg lightweight vs heavyweight is subjective. But it can be broken up into 
saying something like how much code needs to be loaded at start time (an 
issue for CGI/Perl). eg I think people would agree that the startup of 
CGI.pm is different from CGI::Lite which is different from cgi-lib.pl. Of 
course, there are many other features that you get from them that can make 
a difference in your program.

Anyway, that is why this checklist is being designed by all of you and 
handled by an independent 3rd party. It's not a marketing tool. So if you 
complain about session support being a checkbox, I am sure that the feature 
name could be refined.

Later,
    Gunther

At 08:26 AM 8/2/00 -0700, Jonathan Swartz wrote:
>Drew Taylor wrote:
> >Ken Williams wrote:
> >>
> >> I suggest having not just a simple checkmark, but a 3-way check.  A
> >> system either supports a feature, or it doesn't, or it *optionally*
> >> supports it (can be switched on and off).  This is often very helpful to
> >> know, and might let one get a good sense of the differences between
> >> various systems at a glance.
> >Another great idea! Should we go one farther and have a checkbox for
> >"coming in next version", or is that going to far? I'm thinking it is
> >too easy to get wrapped up in "forward looking statements" by having
> >"coming soon".
>
>Although I feel that Mason would do adequately in a feature
>comparison, I have to say that feature checklists scare me. The reason
>that they're most often seen in ads and back-of-the-box marketing
>blurbs is their potential for deception:
>
>(1) the set of features you choose, no matter how impartial,
>bias the results
>(2) a binary check value (even three or four check values)
>conveys way too little information
>(3) in software especially there is a fine distinction between a
>feature being "built into" versus "supported by" a product
>
>Case in point: session handling. I grind my teeth everytime I hear that
>"Mason doesn't have built-in session handling".  Right, and it doesn't have
>built-in arithmetic processing either. It relies on Apache::Session and the
>Perl interpreter, respectively, for these features.
>
>Yet I've often been tempted, for marketing purposes, to add a
>"use_session" option to Mason that simply brings in Apache::Session with
>a few lines of glue code, so I could boast built-in session handling. If I
>were selling a product I'm sure I'd do this. One of the reasons I like the
>open source world is that I don't have to resort to this level of chicanery.
>
>I guess I'm just cautioning the makers of this feature list to choose
>the display format carefully so as to minimize information loss.
>
>Maybe each template package should get one page with standardized
>format and questions (what features do you have, what are your system
>and memory requirements, what does a sample page look like, etc.).
>That way people could flip back and forth through the pages and get a
>sense of comparison, and the authors would get to focus on what they
>consider most important.
>
>Jon
>