Problem

  • The Mollom settings page is (1) too wordy and (2) contains too many links.

Proposed solution

Comments

eshta’s picture

Regarding the privacy policy link, there is a big difference between being required to inform visitors of data privacy and "you should inform visitors". The Mollom service agreement makes it sound pretty clear that users do need to be informed of data privacy. I would think this wording should be keep stricter.
http://mollom.com/service-agreement-free-subscriptions

sun’s picture

While that is true, I intentionally decreased the "severity" of that note.

Mollom's ToS only instruct you to do it, because if your site operates in a legal territory that has strict(er) data privacy laws (such as in the EU), then you're legally required to inform your visitors about the privacy of their data anyway.

At the same time, no such data privacy laws exist in e.g. the US.

In the end, failure to educate your site visitors about how their data will be used or processed is not Mollom's problem. As a site owner who accepts user input in any way (including any other third-party services), it is your own responsibility to educate site visitors about the privacy of their data, not Mollom's.

It starts with trivial things like Cookies, and it ends in (all) third-party web services that may process your data (in any way).

In short, all Mollom's ToS are doing is to "remind" you of a legal detail that is (too) often overlooked by site owners. Since that legalese vastly depends on the territory that your website operates in, it is safe to weaken the language from "you are required" to "you should".

Lastly, also note that this entire privacy policy output + option was introduced only ~2 years ago, and since it's a theme-affecting change, we had to disable it by default for all existing sites.

Bojhan’s picture

This looks like a good improvement, I don't see much opportunity to cut it further, perhaps the last checkbox doesn't need the description if you mix it in with the label.

sun’s picture

Thanks for your UX review, @Bojhan! :)

Regarding the last checkbox, I agree that the description appears to be unnecessary.

I explored some rewordings already, but ultimately wondered whether we need to negate that checkbox...? E.g.:

[ ] Mute normal Mollom operations in log messages

...or perhaps even negate its technical meaning (and default it to off instead of on):

[ ] Record all Mollom interactions in log messages

The default value is to only log warnings and errors.

The intended optional value proposition is to allow users (rather developers) to see all of Mollom's interactions in Drupal's log messages (as opposed to errors only).


To perhaps clarify, I refused to add that [advanced] option in the past. But as of ~2013, the general need for having this data for debugging purposes vastly decreased, as the Mollom service became much more accurate; only warnings and errors are of interest now.

The option only exists to "increase trust" for technically versed users, allowing them to inspect what Mollom is or was doing. By default, only warnings and errors are logged. When testing mode is enabled (the checkbox right above), all messages are logged by default.

eshta’s picture

I think the use of "only" without any context above is what makes it sound difficult. What about something like:

[ ] Limit logs to warnings and errors
Disable to see all Mollom interactions in logs

Similarly, Sun, your suggestion also makes sense and I think the description is actually less confusing as well:

[ ] Record all Mollom interactions in log messages
The default value is to only log warnings and errors.

Or perhaps a combination of the two?

eshta’s picture

StatusFileSize
new15.66 KB
new84.57 KB

I've combined these UX ideas with the concept of an advanced configuration screen. A number of features in development (and some ready) for the next tagged release merit the addition of such an area.

  • Enabling flag as inappropriate by entity type
  • Selecting an integrated dialog option for flag as inappropriate
  • Enabling form behavior analysis
  • Enabling/disabling audio captcha (specifically for non-English language sites

I should also add some test cases for these new configuration parameters to make sure they work as advertised. Will be adding that in soon, but wanted to see if there were opinions/feedback on this approach first.

Also adding a screenshot. Note that the random quote in the last option is no longer there in the code....

The last submitted patch, 6: mollom.settingsux.6.patch, failed testing.

eshta’s picture

StatusFileSize
new15.68 KB

OK - should at least pass the existing tests now....

eshta’s picture

Actually - test cases are added in with the functionality for the specific features so no need to add them here on the UX patch.

eshta’s picture

StatusFileSize
new15.59 KB

Just made a few minor fixes found when working on the version 6 backport.

eshta’s picture

Version: 7.x-2.x-dev » 6.x-2.x-dev
StatusFileSize
new10.95 KB

Updating to include backport to D6.

eshta’s picture

Status: Needs review » Fixed

In development branches for next release.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

  • Commit ef7e7db on 7.x-2.x by eshta:
    Issue #2132701 by eshta: Fixed fba enabled setting for consistency.
    

  • Commit ef7e7db on 7.x-2.x, fbajs by eshta:
    Issue #2132701 by eshta: Fixed fba enabled setting for consistency.