Wedge

Been thinking a lot about this over the last few days and discarded more UI designs than I can think of for it (eek), but I want to share how I envisage post moderation working from a configuration point of view, and on a related note, why it needs to be changed.

I'm not looking at the mechanics of how approval itself is managed, simply at how one configures what the rules for placing posts on moderation are.

So, what's wrong with SMF's post moderation configuration? Firstly, Core Features. Regular readers will know that I loathe and detest that page. It's nice enough but it's illogical for a regular user to deal with. The number of people who, in the last couple of years, have asked how to turn it on should be proof enough of that.

Then, assuming you turn it on, post moderation shares one dubious award with the calendar, in being the only areas of SMF whose access permissions are configured in three different interfaces (that all do the same job). Yes, that's right, there are three different ways you can set permissions for post moderation - the simple and the classic permissions interfaces, and its own custom page.[1]

And notwithstanding the fact that you have to actually then configure it. It would take a genius of Vizzini's stature[2] to configure post moderation right first time unless you know how it's implemented, since it's *really* not clear from the permissions page.

Here's the problem: nowhere in the permissions does it ever tell you that if the user, for any reason, has 'post... without requiring approval', that overrides 'post... but hide until approved'. Unless you farted around, you'd never come to that conclusion on your own. It's almost broken enough that I'd call it a bug but it was as designed, seemingly. (It's designed by programmers, rather than *for* users.)

Let me explain the problem of doing this on a fresh SMF install, and you're welcome to join in at home. Today's challenge: configure it so that regular users don't have moderation but new users with up to and including 5 posts are moderated.

There are, in fact, two ways to do this, both of which are convoluted.

1. Turn on post moderation in Core Features.
2. Making sure that the 0-post count group is left alone, create a new post count group that requires 5 posts, so that once a user has successfully posted 5 posts (and until they're approved, it won't affect their post count), they can have different permissions attached.
3. Admin > Members > Permissions > Settings > Enable permissions for post count based groups (tick) > save

Here's where the paths diverge. Here's path A:
A4: On the same page as above (Admin > Members > Permissions > Settings) also enable Enable the option to deny permissions
A5: Go to Admin > Members > Permissions > Board Permissions and for each profile (that allows posting) set the permissions up as follows: Regular members should have "Post new topics, without requiring approval" and "Post replies to topics, without requiring approval" enabled, while the 0-post count group should have those permissions *denied* and "Post new topics, but hide until approved" and "Post replies to topics, but hide until approved" in their place. Once the user leaves the 0-post count group for the 5-post count group, the other permissions are no longer denied.[3]

Or, path B. It doesn't require deny permissions but it does things another way.
B4: Go to Admin > Members > Permissions > Board Permissions. For Regular Members, set all the posting permissions to disallow. Then in the 0-post count group, give them "Post new topics, but hide until approved" and "Post replies to topics, but hide until approved" and for every other post count group, give them "Post new topics, without requiring approval" and "Post replies to topics, without requiring approval".[4]

Either way, banal and frustrating (and in fact, you still have to do the same thing using the other interface but it's actually slightly *more* confusing, not less there).


So, here's what I think instead. I haven't quite found a UI I'm happy with which is why there haven't been any screenshots or commits on it yet.

Post moderation is one of those things that you're going to be setting rules for. Think about it; every time you actually want to set post moderation, it's going to be because you want it for specific situations. Some of those will be rather broad but specifically defined (all users with under 5 posts), some will be very specific (all new topics in a certain board)

Doing that last one in SMF is a brainfuck, in fact.[5] So instead, why not some kind of interface that lets you set those rules?

In fact, you can boil down almost every single kind of post moderation situation to rules. Some of them are simple rules, some of them are rules with conditions, and some are rules with exceptions, some with both conditions and exceptions.

But really, that's what's needed. Something to construct rules like:

* moderate all posts "where the user has less than 5 approved posts"
* moderate all new topics in "board x"

Then you can get more fancy:
* moderate all new topics in "board x" where "user has less than 100 posts"
* moderate all new topics in "boards x, y and z" where "user has been registered less than a week"

Or even:
* moderate all posts in "all boards" where "user has less than 10 posts" except "board x" (maybe it's a chit chat board where spamming is allowed, I dunno)

That's the core ruleset, creating rules about the user, but there's no reason why it couldn't be extended to other things like creating conditions or exceptions based on groups, or other user characteristics.

Then, just for fun, I want to introduce non-member-based rules. For example, I want to have it able to moderate posts that automatically contain certain words. I also want it able to moderate posts if they contain a certain number of links. (And have exclusions for all those things based on members etc. If a member has 200 posts, I don't think they should be limited from posting three or four links in a page for example)


I don't think any of this is over the top, I just think this is complicated to get right in a UI context and I'm more conscious of doing that than I ever used to be.

It's interesting to note that there are circumstances which could 'theoretically' be simpler to construct in SMF's environment but the reality is that they're pretty few and far between.


Thoughts?

Also as a footnote, let me add that I would be ditching the core features setup, and simply base it on whether there are any rules defined - no rules = post moderation is off.

1.	It actually gets its own page, template and images, while the calendar has to make do with using internal routines. But still, three places, and it's unique in how far the third page goes, elevating it in a class all of its own.
2.	Vizzini: Let me put it this way. Have you ever heard of Plato, Aristotle, Socrates? Morons. (If you don't recognise the line, do yourself a favour and look the film up. You won't regret it.)
3.	But now we have an extra membergroup that does absolutely nothing other than allow another group's permissions to expire.
4.	This means you still have the extra group, but at least the extra group is now doing something. This is also very fractionally faster, but harder to maintain as you have to set the new permission up on any new post count group you create.
5.	New board profile and everything. Notice I skipped over that small detail in the above, but it's true.