Wedge

In the midst of discussions about privacy, we were discussing the way the Local Moderator / Board Moderator group's badge is handled and the problems with it.[1]

Which leads me to this topic, the general state of play as far as displaying user badges goes.

Some people just want to display the badge of the main group, some people might want to display the main group + local moderator badge if appropriate, some the main group's badge plus post count stars. Some people even want lots of badges (e.g. if you're a developer + artist + doc writer, say, you might want badges for all three)

Nao mentioned that it would probably be hard to write as a plugin - certainly currently that's the case because extending the display area is generally a pain, but we can certainly put something in place to make it easier.

So, I want some feedback on what you use, what you'd like. Tell me how you have your sites set up, whether you like that approach or not, and also whether you use the mods out there for such things like Stars and Badges. :)

1.	On this site, for example, in some of the boards I'm listed as a local moderator rather than my normal badge because I'm not in the admin group. There is special code in the loader for this specific purpose.

I just had an amusing aside drawn to my attention.

I did a project several years ago which attracted a little attention in certain quarters and I got some kudos out of it in consequence. Long story, rather not dredge the names up because some of it is a touch embarrassing. But it's relevant because a few months after I wound down my involvement with it, one of the people I had worked with was putting out a contract for tender.

Now, this would have been mid-late 2009 or so that this happened, and I applied knowing full well that the person concerned liked my previous work, so I totalled up what I thought it would have cost me to build in terms of time/labour, and knowing that I was building it on top of SMF, as part of my pitch I explained how I'd build it and why it would save some serious time and effort (and SMF 2.0 was a strong base, the amount of customised code was substantial but not unmaintainably so) and submitted the bid. IIRC, I pitched it at about $3000 to build. It was a big job, because of all the fun requirements that went into it but that I didn't think $3k was unreasonable for the work load and support that would come into it - that would be for all the base dev (2 months full time, my estimate was) plus a year's support and extensions were generally free in that time.

About a week later, I heard that he'd picked a programmer and work began. Scroll forward to 2012. There's been at least three separate attempts to launch said site, one of which actually got as far as beta (the first alpha was August 2010, the first beta June 2011) - but they're rewinding that. There's been at least 4 'rock star programmers', all of which have been dispensed with, and by all accounts, starting over AGAIN.

I can't help but turn a wry smile. Yes, $3k is a lot of money, but that was for the 2 months I was predicting as a build time (even on top of SMF) but he'd have gotten the site launched by now. Probably would have gotten it launched back in 2009, too. But that's how things go, I guess.

I'm not sure if we talked about this or not, but I'm seriously debating enforcing JS to be present for the admin panel. While I can understand non-JS fallbacks for the normal forum, I'm less clear on it in the admin area, though I can see the argument in favour of accommodating screen readers etc. But even there I'm kind of thinking that it might be better to use JS primarily and not have the fallbacks, because I'm just thinking that there's no good way the admin panel can work for non-sighted users, there just isn't.

Thoughts?

Well, more than once Nao and I talked about logging the user id of the person who edits a post. Maybe we can use that to prune some of the data from the table, maybe we won't do that yet, don't know. (It's not a huge deal if we decide to do that, put it that way.)

But what this does mean is that we can identify who last edited a post, and more importantly, we can figure out if either the last editor is the post author or not, or even if the last editor is actually a moderator.

This means we can (quickly but maybe slightly inaccurately, or slower but guaranteed accurate) identify whether the post was edited by a moderator and potentially disallow future edits to that post, by non moderators.

Would you use such a feature? Would you want it enabled by default (that if a post is edited by someone other than the author, only a moderator can edit it further)? Something further?

Hmm, there are a few things that bug me about board descriptions at present, would love to know what you think.

1. Board descriptions being shown inside the board too. (Optionally or otherwise) Is this necessary? Given that we're talking the same description on the board index as we are inside the board, is that actually worth doing?

2. Would it not be better to have a main board description that's used on board indexes, and an optional bigger description that can be used inside the boards themselves?

3. Regardless of where the content comes from, is it really necessary that such a description should be a user preference rather than an admin one?

4. Right now the board description is used in favour of the board title for meta description. I'm not sure that's entirely a good idea, but it makes me think that 2 is a better option: supply boxes/storage for both a small description for the board index and a larger description for inside the board itself. That way you can also get a better description in place for SEO purposes etc.

Thoughts?

Regular readers will likely have noticed that I've been slacking for a while... life's been like that, a royal pain. But in order to celebrate getting back into the swing of things, I tackled something I've been wanting to do in SMF for years (and did begin to plan it back in 2010) - some serious automated moderation rules.

The idea is that you should be able to do things easily and conveniently and awesomely. It's still very much WIP, and those who've been following one of the other topics will get a better idea of the innards but that's not why I'm writing here.

I'm writing here because I have screenshots to show as well :D And this way it'll get a bit more visibility than it might elsewhere, which means hopefully a few more people might add their comments to this. Those who follow us on Facebook will have already had some comments from me on this.

The idea is that the system should be able to do some of the work for you, not just moderating posts based on some rules (like post counts and boards) but also on content, and I fully intend to make this even *more* powerful than it already is. But already it's powerful.

Details

The first rule says, if the post begins with /lock and the user has the permission to lock any topic, well, lock the topic.

The second rule says, if the post contains a rude word and the user isn't an administrator, moderate the topic. That's the power we're talking about, you can do things that don't implicitly require permissions everywhere.

The last rule says, simply, if the post is made in General Discussion, moderate it. That's a very broad rule, not likely to be used in real life, but illustrative more than anything.

Notice that we have two moderate rules - this is a logical rather than a technical divide. This way, we can create many different combinations quite easily - here, it's (user isn't admin + says a rude word) OR (posting in a specific board).

I couldn't think of any better way to display it but if you have any ideas, I'd love to hear them. Meanwhile, I'm going to finish up this code (it's barely enough to actually display this!) and then get onto the create-rule UI.

Oh, and people who've read the FB post will also know that I've removed Core Features. Nao's r1304 removed the Media Gallery from being in Core Features leaving Post Moderation as the only thing there, and now, it's not there. Locally, not yet committed, I've removed most of the traces of post moderation from the system (I just need to strip out the permissions stuff where it's buried deep in the permissions system)

But that means I get to finally purge one of the most illogical parts of SMF that we inherited, and I'm glad it's finally gone. I like trimming useless code at the best of times, but this was annoying to boot :D

Anyway, this is me saying "Hello!" and getting back in the saddle to make more awesomeness :)

So, we've talked about this one but all the time up to now I've been putting off implementing it because I was never thoroughly sure how to efficiently handle doing likes.

The idea of doing a big (and potentially expensive) query on thread display never appealed to me but after sitting down and examining XenForo (which does it as a core feature) and seeing how they did it, I find myself unable to find a better way of doing it.

Specifically, their method is to embed an array of entries into the posts table, in a blob[1] and pull that out as display time.

Oddly enough, that actually contains the username as well so there's no extra performance hit there, but I imagine the change of display name is expensive if that person did a lot of likes.

So, for the programmers out there, what do you reckon?

As I see it, there are four options:
1. Just store the likes/post relationship and query it at display time (optionally with caching). Smallest in the DB, no additional maintenance, but it does mean there's an extra query - and we do have to run through that query in its entirety, it's not like we can stick a limit in, because you can't do a limit per criteria: you can't get "3 rows of that criteria, 10 rows of that", so we have to evaluate all the likes on the page at once.

2. Store the list of ids who like a post into the post table, and add that list of people into the main loadMemberData call (or do a second, smaller one just for minimal since we only need the names at that point). Much quicker and more efficient, but there's still extra work being done to handle the overhead of gathering names etc. (though of course we only get the right number of names, the first 3 or so actual names and just bundle the rest together)

3. Store the list of ids and names in the post table. Consumes a lot more space than either of the other two options, however it means there's no extra effort involved other than parsing the extra item (which need only be an unserialize call, or even a json_decode call, bearing in mind that we only need the first 3 or so rows, and can discard the rest after), and of course adds to the maintenance work if a user changes their display name.

4. We store just the count of likes in the post table, and fetch the list (using the same table as in 1) AJAXively if someone asks. Much lighter than the others, but far less nice IMHO.


Thoughts?

1.	Eh, could be a text, can't think of any overwhelming differences, other than that it's harder to get a blob in a table, you have to prance around doing CAST() to get at it.