Forum Pet Peeves

[Cedric]

We all know that running a forum can be a challenging and rewarding experience, but there are certain things that can really get under our skin as webmasters. So, what are your forum pet peeves?

Is it members who constantly break the rules or refuse to follow instructions? Or perhaps it's spammers who flood your forum with irrelevant or inappropriate content? Maybe it's the endless stream of "me too" or "thanks for sharing" posts that add nothing of value to discussions?

What about members who don't take the time to read existing threads before posting their own questions or comments? Or those who engage in flame wars or other forms of disruptive behavior?

And what about technical issues, like slow page load times or frequent downtime? Or the challenges of managing a team of moderators and ensuring that they're enforcing the rules consistently?

We all have our own forum pet peeves, and discussing them can be a cathartic and helpful exercise. By sharing our frustrations and challenges, we can learn from each other and find new ways to improve our forums.

So, let's hear it – what are your forum pet peeves, and how do you deal with them? Let's commiserate, offer support and advice, and help each other create the best possible forum experiences for our communities!

 

[Cory]

The main pet peeve of my own forum is making it hard to generate activity, which is probably an issue with most forums. I wish people would give me more ideas for resources I could create or just post more occasionally in the general discussion areas. I'm sure if I could think of more topic ideas for the general discussion areas, then people would be more likely to engage.

The main pet peeve of other forums is probably controlling, dictator-like staff members.

 

[Arantor]

Pet peeves.

1. The people who seem to be under the impression that I can read their mind and go 'it's broken' without telling me what, how etc.
2. The people who insist on doing things a certain way even though their way is objectively and demonstrably a bad idea.
3. The people who gate-crash 10 year old threads because they got the same super-generic error message, as though it's in any way still relevant.
4. The people who didn't even read the 10 year old threads to conclude it might be a super-generic error message.
5. The people who don't want 10 year old threads being necro'd but also refuse to lock them at the same time.
6. The micromanagement style of moderation.
7. The micromanagement style of moderation, applied inconsistently.

I'm sure there are others. Can you tell I've spent too long around support boards yet?

 

[Ummagumma]

Pet peeves.

1. The people who seem to be under the impression that I can read their mind and go 'it's broken' without telling me what, how etc.
2. The people who insist on doing things a certain way even though their way is objectively and demonstrably a bad idea.
3. The people who gate-crash 10 year old threads because they got the same super-generic error message, as though it's in any way still relevant.
4. The people who didn't even read the 10 year old threads to conclude it might be a super-generic error message.
5. The people who don't want 10 year old threads being necro'd but also refuse to lock them at the same time.
6. The micromanagement style of moderation.
7. The micromanagement style of moderation, applied inconsistently.

I'm sure there are others. Can you tell I've spent too long around support boards yet?

Haha yeah that's about right.

 

[Shortie]

I have a few pet peeves but not too many. The first one is people who do not read threads before replying and end up leaving a reply that is not even relevant to the topic being discussed. Another is when people come on a forum and leave one-word replies when they could have left more for a topic being discussed. Lastly, anyone who posts on a forum uses shortened words such as 'U' for you and 'tht' for that or even 'ur' for your.

 

[Arantor]

My inner troll is fighting to resist the urge to reply "thts jst ur opinion tho". Which is, I think, a jointly held pet peeve in its own right - not only the unnecessarily shortened words, unnecessary terseness, but the baked in contrarian attitude.

 

[Ken]

Spambots just come in and post timeshare vacation posts and other crap that has nothing to do with the forum.

 

[Ravenfreak]

Probably my biggest pet peeve is when someone only replies to a thread with one simple word like "lol". I can understand using lol at the end of a sentence, but if you find something funny I think it's best to react to the post if you don't have anything else to say.

 

[Arantor]

I can understand using lol at the end of a sentence

This is also one of my pet peeves, interestingly. It's like we have turned the fullstop in a sentence into a word that we vocalise, for the purpose of indicating we are done with that sentence, because virtually every instance I come across... it's not 'laughing out loud', it's a fullstop just given letters to play with.

 

[Tracy]

My biggest pet peeve... not using the search feature. Granted, the default mySQL search sucks... but you can STILL do a Google search targeted at the site.

 

[Xilia]

Honestly for roleplaying - mandatory posting templates. Bro, I'm on mobile 95% of the time so because said mandatory posting templates don't format well to mobile versions/views of the site (despite how many people prefer to view the forum on say a tablet or smartphone), so they're pointless to me and only make the posts that much harder to read. Not to mention, it's so easy to accidentally delete a character in the code and break the whole damn thing.

 

[Heatman]

What about members who don't take the time to read existing threads before posting their own questions or comments? Or those who engage in flame wars or other forms of disruptive behavior?

This is my own forum pet peeve with some members. In fact, I call them the lazy members because they find it very difficult to use the search feature before posting new topics.

Having to lock or merge new threads to the already existing one's is usually annoying and frustrating for me. They are just creating unnecessary work for me.

 

[joelr]

The people who seem to be under the impression that I can read their mind and go 'it's broken' without telling me what, how etc.

Is this Arantor from SMF? If yes, you've probably seen more than a lifetimes worth of bad support topics.

What is your suggestion to improve / fix the support process?

 

[Arantor]

Is this Arantor from SMF?

My reputation sadly precedes me. (I'm also Pete from TAZ, but that's also another story.) Also this is my entire professional life - I have similar issues with various of my customers reporting things that usually end up with me sending back requests for further info, or even getting on a call with them to show me.

At heart we're talking about a communication problem represented by 'what is obvious to the person is not obvious to me because they haven't used their words to convey all their thoughts'. So, we must figure out how to make it easier for them to tell us things we need to know, and how to avoid everyone involved being lead astray.

Step 1: get rid of historical support topics. Chances are support issues from 3 major versions (might as well call them that) and 15 years ago almost certainly are not relevant, and are at best a distraction. (If they are still relevant, you have screwed up, and you deserve everything you get.)

Step 2: make it as easy as possible for the software to help. Every error message should have a number or code or something that can be looked up in a reference guide. As a general rule, provide as much meaningful, specific data to the person with an issue as is achievable in the situation. The more specific, the better. Bonus points if every error has a guide on a wiki or similar where people can do a search and find the normal next steps. Even if those steps are diagnostic only. Make as it easy as possible for someone to get you enough to act on without you having to ask.

Step 3: Need better interconnect between wherever the people are going to ask, and wherever the answers probably are. I don't mean 'find similar topics based on subject' because that's just nonsense for this. I mean, be able to interrogate wikis from the support forum, especially matching on error codes. I could go on at great length about the failures of modern community platforms and their inherent siloing of content but I'll be saying enough here, so let's not just yet.

Step 4: Have a set of well-written FAQs. Your support folks should be able to tell you what the common support questions are. Having a way to point people at the (right) FAQs is good. Make this obviously discoverable. Again, the angle is to make it as easy as possible for people to find their own solutions, ideally without having to ask. This is mostly for cases where the issue is a 'how do I do x' challenge rather than a 'something is broken' challenge, but they're both support issues.

Now, you're never going to fix this problem. It's not fixable, sometimes things just break and that sucks and you need someone to come in and fix it but you want to make it as easy as possible for them to do so - so have the platform be able to tell you what's wrong as best possible. Build diagnostic tools if that makes sense. Make it possible for people to run these self-diagnostic tools and give you the results. Anything you can do to make it easier for people to help you pays off - because what you'll find is that the people who can't even get *there* will be helped along by the people who are a set further up the chain without dragging the actual support folks in.

Step 4a: don't have templated support tickets. Nor custom fields pushing users for a version number or stuff like that. People don't like it, they get confused, and they'll put in whatever answer gets them through the form quickest, more than they'll put the right answer. It's not unheard of for people to post in the wrong board because they just hit the first one under the support heading, which if that is your oldest version... oops.

And you're always going to have people who aren't interested in doing any of the work themselves. And that's sadly inevitable, but it's life - the best you can do is try to meet them half way. Make it as easy as possible for them to get the information to you.

Big chunky naming schemes are good for this, people actually tend to remember the name of a thing more than a random version number, and are less likely to get it weirdly wrong - SMF currently sees people mangling 2.1.3 into 2.0.13 and similar which can be annoyingly confusing. But if you decide that 2.1 is 'Melon', you can make it 'Melon-3' for third patch. It can even internally *be* 2.1.3 but giving it a name works. Same way that Android and Ubuntu do this - yes, there are people who will latch onto the version number, but these people tend to get it *right* when they do. Give everyone else a chunky name they can latch onto. Makes it easier for everyone.

Stretch goal: when you have common reports of an issue causing support - it doesn't even have to be a bug - FIX IT. There are times that 'this is not how it was designed' is an appropriate response, because sometimes what the user wants to do is a) a fundamentally, objectively bad idea and b) so counter to the implementation that you're not going to be able to hammer it through.

But if you keep seeing the same sorts of requests, that's not the time to sit and defend your design unless you want to say 'we're not going to fix it, sorry, we didn't anticipate this'. And, in some cases, that *can* be the correct answer. Turning a forum into a chatroom is the sort of thing - both forums and chats have a place, and even some interconnect can be good but not a fundamental repositioning of one to the other in some unholy reverse-Discord. But some of the time you do need to identify that actually, the design was bad and FIX IT.

A support request is, by definition, a failure of the project. It is a failure to communicate how to solve a specific problem. Or it is a failure of the development to spot a flaw. Or it is a failure of unanticipated (or anticipated but overruled) need. This is not to suggest that all failures are equal, or that all failures are *bad*, because they're not. Some of these 'failure states' are unreasonable expectations but nevertheless, they are representative of 'the user tried to do something they expected to do, or reasonably be able to do but could not do, or could not work out how to do'. This does not even mean that the software failed in itself, but that the project has somewhere - in theory any suitably functioning ecosystem would yield most common requests either directly in the core product or in some after-market in the form of add-ons/mods/whatever you call them. Any such failure here is either the product of 'the ecosystem failed to deliver' or very commonly 'the ecosystem failed to communicate that a solution existed'.

There are further things that could be applied; but that feels far too far down the ITIL and ITSM playbooks for my liking. Communities don't need regimen, they just need to make it as easy as possible for everyone involved to do the right thing.

 

[joelr]

Step 4a: don't have templated support tickets. Nor custom fields pushing users for a version number or stuff like that. People don't like it, they get confused, and they'll put in whatever answer gets them through the form quickest, more than they'll put the right answer. It's not unheard of for people to post in the wrong board because they just hit the first one under the support heading, which if that is your oldest version... oops.

I'm surprised you say that.

I've always held the belief that the hardest part is not in knowing how to answer the question, it's in knowing how to ask the question. For example, one of the best customer support forms that I've used before required me to provide step by steps to reproduced. That forced me to reproduce, provide screenshots, and accurately document. Templated forms should funnel users to appropriate resolution.

Very interesting insights on your other points.

 

[Arantor]

I've seen so many forms requesting the steps you ask for. It's quite common on GitHub repos actually that when you fill in the issue you have to put in version, steps to reproduce etc.

The problem is, it's not useful. As someone on *both* sides of that fence, I've yet to see it produce any meaningful results. You have the less technical people who won't know the answers, you have the more technical people who will, but for whom those particular details will be mostly irrelevant. The steps to reproduce will, inevitably, miss critical detail that 'should be obvious'. Or, as most of mine have been lately, 'step 1; have this particular setup in your world, step 2; observe it is broken in this specific way' where it's not really a step to reproduce, more an unhandled side effect, and where the second step is 'observe how it is broken' rather than me having *done* something.

You're right - that is absolutely the hardest part. But the 'how to reproduce' rarely gives *useful* information. To try to give you what I mean... "bug: I got food poisoning from this microwave dinner, steps to reproduce, I got it out my fridge, put it in the microwave for 3 minutes on high". This is, for the user, the relevant steps in their mind. For me, I'd want to know things like what the best before date said, was it cooked from frozen or refrigerated (and if from frozen, was it defrosted?) - things that the user almost certainly isn't going to tell me under steps to reproduce because for them, it's *probably not part of the steps they think of having done*. Inevitably the steps to reproduce are the last half the story, if they're even half the story.

Here's the other thing, it's also full of some self-selecting bias. The folks who see the 'provide step by step instructions' think 'oh I need to reflect on this' and provide *detailed* instructions - like yourself - aren't the problem. It's everyone else. And there's a looooooooooooot more of them out there.

 

[joelr]

I've seen so many forms requesting the steps you ask for. It's quite common on GitHub repos actually that when you fill in the issue you have to put in version, steps to reproduce etc.

The problem is, it's not useful. As someone on *both* sides of that fence, I've yet to see it produce any meaningful results. You have the less technical people who won't know the answers, you have the more technical people who will, but for whom those particular details will be mostly irrelevant. The steps to reproduce will, inevitably, miss critical detail that 'should be obvious'. Or, as most of mine have been lately, 'step 1; have this particular setup in your world, step 2; observe it is broken in this specific way' where it's not really a step to reproduce, more an unhandled side effect, and where the second step is 'observe how it is broken' rather than me having *done* something.

You're right - that is absolutely the hardest part. But the 'how to reproduce' rarely gives *useful* information. To try to give you what I mean... "bug: I got food poisoning from this microwave dinner, steps to reproduce, I got it out my fridge, put it in the microwave for 3 minutes on high". This is, for the user, the relevant steps in their mind. For me, I'd want to know things like what the best before date said, was it cooked from frozen or refrigerated (and if from frozen, was it defrosted?) - things that the user almost certainly isn't going to tell me under steps to reproduce because for them, it's *probably not part of the steps they think of having done*. Inevitably the steps to reproduce are the last half the story, if they're even half the story.

Here's the other thing, it's also full of some self-selecting bias. The folks who see the 'provide step by step instructions' think 'oh I need to reflect on this' and provide *detailed* instructions - like yourself - aren't the problem. It's everyone else. And there's a looooooooooooot more of them out there.

Let's move away from technical questions (eg. I have a forum bug) to non-technical, since the root of this question is: how do we encourage users to ask the right questions on forums, so we can provide the right answer? This is a big question.

Self-reflection by itself is not bad. I (try to, when I remember) to provide information on what I already tried. There are certainly some inherent pitfalls (aka assuming I troubleshooted correctly), but there's also value in imparting that I'm capable and knowledgeable enough in addressing level 1 inspection.

 

[Arantor]

how do we encourage users to ask the right questions on forums, so we can provide the right answer? This is a big question.

Give them as much immediate and pertinent information as possible. Error codes are amazing, like 'XFE-177 encountered' because that can define a whole realm of things both for the more motivated individual to find answers themselves, as well as focusing any support effort in a given direction.

It's also not surprising that other ecosystems have more dedicated 'fault reporting tools'. Firefox crashes? You get the Crash Reporting Tool pop up, offering to get a bunch of diagnostic information from the user - with the caveat that the user has to accept to send because it 'could' be sensitive information, if it crashed while on your banking site for example.

But here's also the thing: you know why you get those really *really* irritating support scripts down the phone? The 'have you plugged it in and have you turned it on' level stuff? The companies do this because they *know*, not just anecdotally but with years of actual data, that this will resolve a definite amount of problem before you start. And anyone on the other end of that call knows just fine when the caller is all 'but I already did that' the chances are they didn't.

The fundamental issue here is simple: the person wants a solution. They want the fewest *possible* steps that they have to take to get that solution. Filling out a form - even if they were accurate and truthful (and remember, House was right: everyone lies) - isn't going to work out in the majority case. So the tools have to be smarter and do as much of the legwork as possible.

We live in a time where people, when asked for a screenshot, will take out their phone, take a photo of their laptop and send that in. (Bonus points to the computing science PhD person who did this to me a few years back.) In the same way we need to simplify how people do things on sites and make it simpler - we need to do that for support issues. It's not for nothing that WooCommerce support routinely asks for the output of their support tool - so they don't have to ask the user for versions of everything, nor do they have to contend with users getting it wrong. I'd even be in favour of being able to make a support request directly from the ACP (assuming you can get in) which can report all the obvious pertinent information.

I guess my angle here is the dev-ops approach. Humans are fallible and make mistakes, so automate away the things humans are bad at, make it as easy as possible for them to do the right thing. But it's not something I think *too* hard about because I've learned with my customers that they appreciate having me to talk to about the issue. The 'show me' phase is great - if we could bottle that it'd be amazing but people suck at even simpler tasks.

As for self-reflection, no, it isn't bad. Just most people are bad at it.

 

[Oblivion Knight]

Forum Games (eg. Word Association, Count to X)

Yeah, admins want their forums to be busy - but this is not the way to do it. I'm almost instantly turned off from joining/participating in a community when I see such things..

 

[Ken]

Forum Games (eg. Word Association, Count to X)

Yeah, admins want their forums to be busy - but this is not the way to do it. I'm almost instantly turned off from joining/participating in a community when I see such things..

I strongly disagree. Forum games are a way to boost members post counts and it's a tradition of the forum community since Proboards existed 23 years ago. If there are no forum games in the community, what do you expect them to do without them? I mean, seriously.