[pmwiki-users] New PmWiki Features Page . . .

[Ben Wilson]

This email is a bit long, but I respond to three fellows. Better than
three emails, methinks.

On 5/25/06, Neil Herber <nospam at eton.ca> wrote:
> First of all, the red-yellow-green color coding is fraught with
> cultural baggage. Seeing all of the reds and yellows makes me think
> that PmWiki is not doing a very good job - but in fact, the yellow
> items are all things it can do via recipes, many of which are so
> trivial to implement that they should not give the negative
> impression that the yellow provides.

Which is why I said I needed icons. Pm raised virtually the same issue
when I first showed him. This is especially true when we get to
"yellow," which really means PmWiki provides a solution with a wee bit
of work. I would gladly substitute icons for the color coding. It also
raises an issue of color blindness. So, we have culture and color
blindness as reasons to rid ourselves of the coding system. However,
I'd like to have icons or something. Do we stay with "Yes," "Plug-in,"
"No" only?

(I once designed a system using red stop signs and green circles. In a
pinch, I printed in B&W. At the release presentation I pointed out
that seeing the pages in B&W indicated a problem as it would be
less-than-useful to red-green color blind people. After the
presentation, my boss told me he was red-green color bind--and that it
was good that I caught that issue.)

> There are places I have tried to introduce PmWiki where the local
> nay-sayers are ready to leap in with comments like "But it can't do
> CAPTCHAs and they are our corporate standard!" These guys don't need
> any extra ammunition.

Guys like that will lob grenades always. If you gave a solution and
they don't like it, they will lob another grenade. Sometimes they do
it just to see you dance. Having had to do the dance, I learn to love
those guys.

As a consultant, wouldn't you rather have all the information so you
can respond? What if they said, "but we _must_ have the wiki pages
stored in Oracle," and PmWiki does not support Oracle. As a
consultant, I don't think you'd offer a product that does not meet the
client's requirements--especially a "shall" requirement. And, if they
need Oracle, or CAPTCHAs, then there's need for a recipe. I'd rather
give a consultant a "CAPTCHAS-No" than have him shrug when asked.

Why do I love those guys? Because when I'm well prepared, I shut them
down. They start looking like bullies, and I start looking like the
guy who has all the answers. Sometimes, those guys are your supporters
who are trying to address the concerns of others in the room--but as
your supporter they frame in a more positive way.

On 5/25/06, Chris Cox <ccox at airmail.net> wrote:
>
> I sorta like it.   I sometimes think the feature list is
> slanted.... it's more of a you-who-use-the-other-wiki
> here's what PmWiki can/can't do list.
>
> Which I suppose is ok.  Just didn't seem like a
> PmWiki feature list as much as it seemed to be somewhat
> of a PmWiki critique (both positive AND negative).

This may be owing to my using Wiki Matrix(.org) as a source of
information. I wanted to give PmWiki full treatment "warts and all"
for the prospective new member to our Community. A prospect will want
to know what PmWiki does not do. That said, I believe all the "NO"
elements should link to a page that explains _why_. For example, there
is a well-worded page on why PmWiki prefers a file-based data storage
system as opposed to a database solution. I'll warrant that in many
cases there's a good reason. In other cases, such as Textile support,
there may not have been an interest. In still other cases, we see a
gap in what PmWiki offers so those among us who write recipes may
provide.

Notice that the language of the page uses "plug-in," rather than
recipe. This gives some indication that my target audience is not the
Community. We have already "drunk the Kool-Aid," so-to-speak.

I suppose my goal is "objective honesty." PmWiki is among the best
wikis, IMO. However, when a prospect is trying to sell PmWiki to his
organization, he's going to need ammunition. This is sort of like the
fellow last week who was trying to justify PmWiki over MediaWiki--and
one issue was about searches. Turned out not to be a major issue
because we had a solution. When we know our blind spots and can better
support our prospects and the community.

My professional approach has always been to show candor (most of the
time). I showcase what's best and mention what's wrong, why its wrong,
and what to do about it. People seem to appreciate that much candor.
Others have used it against me from time to time, but not always to my
detriment.

I also noticed that we could provide a list of recipes by feature.

Anyway, because the focus of this Features page is objective honesty,
it is a critique in part. However, a critique is not all bad. I think
it is intellectually dishonest to ignore what PmWiki does not provide.
Please note, I am not saying "can't provide" or "can't do." In almost
every area where there is a "No," a recipe could readily fill in the
blank. See below for more on this.

On 26 May 2006 17:33:26 +1200, John Rankin <john.rankin at affinity.co.nz> wrote:
> "A garden is finished when there is nothing left to remove."
> (Zen proverb)
> . . .
> Any kind of feature list and feature comparison tends to imply
> that more features = better product. My own view is that I would
> rather have a product with a well-thought-out but limited set of
> features than one full of bells and whistles.
>
> So I think the very best feature of PmWiki is that it has a
> deliberately limited set of core features, with the ability to
> add whatever local customisations you need for your particular
> application.

That is one of the things I am hoping to bring out in the Features
page. That is, that PmWiki does a lot right out of the box without
being subject to the ravages of feature creap. I've also railed from
time to time about a feature that I thought was in the opposite
direction of "nothing left to remove" approach.

I think explaining this is possible using the rough form put together
thus far. Right now the Features page is nine printed pages, with the
At a Glance charts. That fit into my 8-12 page range. However, it
lacks a top-page coversheet that gives the BLUF (Bottom Linu Up
Front). It's sort of like giving a report to a senior manager knowing
he'll only read the first page. I'd like to give a concise summary at
the beginning while keeping the page count within my target: one page
for the high level, many pages for more technical detail, and links to
find more information for those who need to delve in an area.

As I said above, most "No" issues lack only a recipe to fill in the
gap. This is where I think PmWiki is close to its best. If we as a
Community _could_ answer yes via recipes to everything on that list, I
think PmWiki's core is developed. That is, because we can give an
answer to those No issues by plug-in, PmWiki's core has served its
purpose by enabling the site administrator to do about anything he
would want, while at the same time remaining "minimal," and with a sub
1M footprint.

-- 
Ben Wilson
" Mundus vult decipi, ergo decipiatur"