I've been doing some brainstorming on how the Mollom interface could be easier to use.

Idea #1:
1. Create a 'protected forms' table in admin/settings/mollom that shows the current protected forms, protection level, and links to edit protection or unprotect the form.
2. Users would go to a separate admin/settings/mollom/add in order to add/edit protection to a form.
3. The add/edit form screen would allow the user to change the protection level (CAPTCHA/Text analysis) and the fields to send for text analysis.

I've attached some very basic mockup screenshots to show how this might work. This would require a major rework of the form integration code, but it might just be worth it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

danielb’s picture

One thing I am thinking is that if you wanted to create the exact same rule for every form on your website, you would have to do it one at a time. What if each form protection row could apply to more than one form? So you could have a multiselect for the form choice, or some way to choose a 'type' of form, like the user forms, or the node forms - this would ensure future forms in these groups (like if you create a new content type) would be protected automatically.

akahn’s picture

I like the direction here. This isn't just making it easier to use but also adding more fine grained control to how Mollom integrates with a Drupal site. I also like danielb's suggestion, but wonder if this would get more complicated when you select multiple forms, and some of the forms have different fields (CCK, etc.).

Dave Reid’s picture

If we were to go in this direction, it wouldn't make sense to be able to add multiple forms at a time this way, since they could have many different fields. Maybe on the form table listing we could have an 'enable captcha protection'. If users want to add textual analysis, they must go through the field selection.

akahn’s picture

That makes sense. Maybe you are trying to move away from this direction, but what if there was a page that had each form and next to each form was a form element (multi-select? checkboxes?) to choose fields? Or maybe this is just overboard.

Do you think in this redesign phase there could be an option to not submit certain fields' text to Mollom's "self-learning" data? I'd be willing to try out a patch if it's possible. I haven't looked into the module at all yet, so I'm not sure at this point.

Dries’s picture

Interesting approach. Webforms and/or complex CCK-types are probably a good use-case to consider in this redesign.

- Webform integration is probably the number one feature request for Mollom.

- For privacy reasons people might want to exclude certain fields; if you're collecting social security numbers through a CCK employee node, you could choose not to send these to Mollom.

I think both would become possible with this approach.

Benjamin Schrauwen’s picture

Very cool idea. Here are some comments on the mockups:

- All available form/node types should be shown in the "form protection" table
- If a user presses the "Protect" link, the site should be instantly (ajax?) protected using some sensible default setting (text analysis + CAPTCHA), without going to the edit page. When people want more elaborate settings, they can press the edit link afterwards.
- The protection settings should be in this order: "text analysis with captcha", and next "captcha only". "Only text analysis" is not possible.
- It should not be possible to change the form type when editing the settings.

You got my go-ahead :)

nielt’s picture

@Benjamin One would have to go to an edit page immediately for webforms/cck forms, because fields need to be mapped to the relevant data type for text analysis to work.

nielt’s picture

I combined some of the patch ideas from http://drupal.org/node/259488 (webform support) with some ugly (read: not thoroughly tested) hacks to select CCK (text area and text field only) fields for the text analysis body (I don't know if this will hold up outside of my dev setup of CCK, Webform, Mollom and Core.

This patch is meant as a demonstration of ideas for the interface brainstorming, and must not be applied in a production environment (database changes are made - the old variables are left in place, and a new one is added for the field mapping - also, I am an absolute Drupal/PHP newbie and the code is a bit of a mess).

What it does:
- Interface close to that of idea#1 by Dave Reid. Add/Edit forms are combined.
- Ability to map CCK text fields to $data['body'] for node creation forms (highly experimental, still includes unnecessary html that always triggers the "unsure" state)
- Webform support with improved interface
- Adds "Mollom Settings" fieldset to protectable forms for Mollom administrators. Could actually be in the wrong place (create/edit node is not really the place for links to settings pages)

This is brainstorming, not a patch submission.

Dave Reid’s picture

Status: Active » Closed (duplicate)