Wedge

The problem of going down any kind of structured language for that kind of thing is support, in that it would add a support burden, when a good UI can do everything that a simple structured language do, and that way I also don't have to cope with trying to deal with the same problem that bbcode vs WYSIWYG or SQL vs QBE is, namely trying to represent code in a non-code way.

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.

I haven't had chance to try it but it's certainly something that needs investigation. You know, you could always try writing a plugin :whistle:No worries; I fully expected to be the one who would discover such fun things when writing plugins. It's a good way of debugging things, incidentally.*nods* This is also why I'm slack about updating my plugins until things settle down. I still, as it happens, have one plugin that uses loadBlock() from before wetem even existed.That's workable. The thing is, whenever doing anything like this, two sets of circumstances need to be borne in mind: firstly, how Wedge itself uses these, and secondly how plugins and themes will use it (but mostly plugins).

Wedge's use is almost entirely just dropping complete lists of templates into layers, but plugins may well want to insert individual things into layers, may want fallbacks, may want to do other things. To be honest, if I'm looking to insert into the sidebar and falling back to the default layer, I really won't want to do it like that, because the styling will be all wrong. I'll want to have separate templates for that job.

Consider any of the sidebar blocks that we have currently. Would they look right, style-wise, if simply dropped into the default layer? A few might get away with it but generally it'll look bad.Yeah, it's something to bear in mind. However, while there is little connection, it's going to be called together and used together ultimately, so there's little point in splitting it.

I think I might start this as a little daily column, ooh-err.

Anyway. Elsewhere on the interwebs, I got talking to someone about the relative interfaces in games; me thinking about DeathSpank's interface (both keyboard and gamepad) and my friend telling me about Skyrim.

The thing that I got from the discussion is that PC games don't actually care as much about the user. They figure the user has a lot of buttons in front of them, they can press them to bring things up. My example, actually, is DeathSpank. There's a quest log, inventory, 'hero cards' and equipment. Each of those can be brought up from a single keypress. BUT, if you're using a gamepad, there's only a single button allocated to equipment and you step through the pages from there.

Now, my friend mentioned that there's a 'console accommodation' in Skyrim, pressing a single keyboard button brings up a 4-point menu for levelling/skills, map, items and magic. Similar to the four items in DS, really.

My friend stated that he'd use the one button quick key for doing this - but the thing is, I'm not convinced that's the right thing to do, on the game dev's POV at least.

If you use something frequently, leave it a single (easy) keypress away. But if you don't, don't make it a first-class item parallel to everything else, instead delegate down to a menu. In DS, I don't often have to touch any of those 4 pages, so it makes sense that they're one level removed.

Skyrim seems a bit different, where at least one of those pages is frequently accessed, but even then I can't shake the feeling that there's something wrong.

It's as though you're given a dashboard of 15-20 options, that are all as 'important' as each other, seeing how they all take the same effort to make happen, yet surely you don't need all 15-20 options available all the time? Wouldn't it be better to hive off the less important options into a submenu?

And this is what we're seeing being done on console games; they don't have ~100 buttons at pressing distance. Because of this, I'm thinking they have to intentionally be careful with what does what, and force the design to fit - and I'm thinking this is not a bad thing.

I also think a lot of software developers could learn from this approach, actually. Instead of designing to fit with x facilities, what would happen if only a subset y were available?

The other thought I'm having out of all of this is how far I personally have travelled. I always used to be the person who consistently said that I never made it look good, merely that I made it work well, but the more I journey as it were, the more I find that the two things are practically one and the same. I still don't make it look good, but I make it work well for the user, I think.

Thoughts?

Anything would be possible, in theory. Bridging ZenCart and Wedge would be little or no different to bridging to SMF, the big difference is that most people talk about bridging systems as being insecure when it's only that way if done *badly*.

That's the general case at least. Speaking specifically of ZenCart, a couple of years ago I had to modify a ZenCart installation to integrate Sphinx for searching. I didn't have to touch *too* much of the codebase but it was enough that suggested to me that I wouldn't want to do it again.

I have already thought about some kind of storefront plugin for Wedge but it's not been high on my todo list. I wouldn't generally go the other way anyway, because I can't imagine any site that has both a forum and a store component to put the store first (as opposed to using the forum as a CMS type base, and in any case, a properly consistent interface looks much more professional)

That was the point. The code should have worked but it didn't work as expected, in that the layer that (as far as I was concerned) should have been created, just wasn't being created.This was something that bugged me. I saw it was cool but I couldn't quite envisage where it would be beneficial over anything else we were really doing at the time.95% of *Wedge's* use might be that. But that means, yay, I get to fix every plugin I've written thus far that adds a block, because they all use load to add to the layers, though it would logically be better to use an add method.Makes sense.As long as it's documented and there are examples, it seems to make sense...I don't think the chaining really adds anything here.

Technically even ripping CDs to computer is illegal here, btw. Backup copies argument aside, format shifting is technically against the Copyright and Designs Act. Just that for personal use it's quietly ignored.

It's only really Skyward Sword and the Mario games (that I don't own yet) that I can't play during the evening, I can play those during the day if I choose... and Skyward Sword is a bit buggy at the moment going by the forum...

Still, I'm certainly intrigued by the idea.

In other news, I'm now trying out Dolphin...or I will be in a while once the first disc has finished being ripped...

:edit: Or I would if it didn't think I had a faulty drive :/