I was thinking about Captchas in plumi, particularly where and when we might want them. The collective.recaptcha (and captcha) products need a slug of code inside the form templates and validation scripts, so enabling them for a range of forms starts becoming tricky when you start considering that some plumi users might want lots of them (e.g. engagemedia.org) and other plumi users might want none at all (local archives). A setup option to enable/disable captchas (possibly in a range of different places) starts becoming a nice idea. At which point we started pondering what else might be nice to switch on and off easily - News, Call-outs, meta-data categories...
The plumi as we know it seems to have been built specifically for the needs of engagemedia.org. This was fine in the initial development, but I'm thinking for greater adoption, a more general, leaner product might be in order. Whether this involves splitting into more finely-grained products that provide different functions (e.g. plumi.video, plumi.news, etc, and a plumi.thewholeshebang which pulls in everything to make an engagemedia-like site), or various setup/configuration options in a single product, I don't know. In one sense, I don't entirely see why plumi should include captchas at all. That could be left for the site designer to decide on and implement. But that would assume a familiarity with plone, which it seems many of our users don't/won't have, so we make a 'turn-key' solution (as we do now). But if it's too big we get headaches from the implementation and maintenance, too small and it's not useful to non-plone implementors. So I guess the question at the end of the day is: what features does a plumi implementor want? What can be culled, what can be added easily by the implementor? vik _______________________________________________ Discuss mailing list [email protected] http://lists.plumi.org/listinfo/discuss
