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


Reply via email to