Support » Requests and Feedback » Can we have “Mark as” button in Support Forums

  • Resolved kartiks16

    (@kartiks16)



    Hello Team,

    I would suggest if we can have a “Mark As” Feature on the Support Forums.

    I have observed that some visitors are using Support Forum for advertisement or marketing purpose, so if we have such feature, we can mark those post as Advertisement/Spam etc.

    Currently, while answering any forum, I came across such post, I need to tag the moderator, so he/she can take appropriate action. Instead of bothering them, we can have marked as Spam or It is an Advertisement, so Moderator can take it to right direction.

    We can also keep the feature in which we can Mark Post as Duplicate, in case some similar post is also been added in past.

    This is just a Suggestion/Feedback I thought which can help in making the Forums better.

    Let me know if this doesn’t seem to be a valid request.

    Thanks,
    Kartik

Viewing 11 replies - 1 through 11 (of 11 total)
  • Moderator Jan Dembowski

    (@jdembowski)

    Brute Squad and Volunteer Moderator

    I would suggest if we can have a “Mark As” Feature on the Support Forums.

    I have observed that some visitors are using Support Forum for advertisement or marketing purpose, so if we have such feature, we can mark those post as Advertisement/Spam etc.

    I don’t think this is a good idea. I guarantee it will lead to abuse when people start tagging or marking topics they do not like. Also it would deputize regular users as pseudo-moderators and that too can go badly very quick.

    Currently, while answering any forum, I came across such post, I need to tag the moderator, so he/she can take appropriate action.

    You really don’t need to @ moderators or ping them in Slack. Please don’t. 😉

    All you need to do is reply to that with “spam” and add the modlook tag to the topic.

    https://wordpress.org/support/guidelines/#contacting-the-moderators

    The modlook tag does get looked at an resolved when seen by a moderator.

    Thank you for your reply.

    I will follow your suggestion when I come across such posts in future.

    The present approach is ;

    All you need to do is reply to that with “spam” and add the modlook tag to the topic.

    Forum Guidelines

    The modlook tag does get looked at an resolved when seen by a moderator.

    The request is for ;

    a “Mark As” Feature on the Support Forums

    So it seems that convenience of the present method would be improved by automating this present method, and putting that at the user’s ready access in the forum (what ever it is called, and what ever form it may take e.g. button, drop down list, link, etc).

    Moderator stephencottontail

    (@stephencottontail)

    There is a ticket for regaining the ability for anyone to add the modlook tag without having to make a post in the thread: https://meta.trac.wordpress.org/ticket/1956

    Beyond that, everything Jan said is correct.

    Hi Stephencottontail,

    re

    “without having to make a post in the thread”

    Is that the reason why the suggestion for “mark as” (ie an easy automated system) is not done? that is how the decision makers want the process to work.

    A user that is concerned about the nature of a topic, who makes a comment in the topic, might be viewed by other users, and held to be by the moderators, as attempting to be a mini-mod with their intervention comment.

    The alternative suggested “mark as” above has the advantage that the matter is more directly referred to the moderators, without intervention comment(s) which may lead to digression from the main topic, and nothing actually appears in the topic, until a moderator has decided that something needs to be done.
    If the moderator considers that nothing needs to be done, then the topic is undisturbed, and its content is more to the point.

    The inclusion of any information that the reporting user under the present method, places in their post (within the topic forum), would alternatively be included in the “mark as” report sent to the moderator.
    If the moderator thinks there is no problem, then this report can be kept out of the topic.
    If the moderator thinks there is a problem, then there are options for what happens after that (e.g. the report then gets inserted into the topic, or the moderator requests an explanation from the offending topic author or poster, or what ever else may be considered sensible).

    But in any case,
    the information and ability to carry out these actions is moved into the user interface, rather than further away in some help document, or after they have been informed through their own enquiry (as Kartik16 has been in this case).

    Moderator stephencottontail

    (@stephencottontail)

    You might have misunderstood my post. In the past, there used to be a way that users could add the “modlook” tag to a thread without having to make a post, but that ability was lost when the forums were upgraded. I linked to a Trac ticket about adding that ability back to the forums, and if you were interested, you could help out with that.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    ie an easy automated system

    Easy automated systems are easy to abuse. A simple button to “do the thing” would lead people to click the button.

    If you can’t be bothered to make a post, then is your report really all that valuable?

    We look at the long term. I can make a button to do anything, but will the button work? Will it lead to actual improvements? Or will it lead to more work for our unpaid volunteers?

    Managing a volunteer forum with global reach isn’t quite as simple as you might think.

    Hi Otto,

    1) Re

    We look at the long term. I can make a button to do anything, but will the button work? Will it lead to actual improvements? Or will it lead to more work for our unpaid volunteers?

    Managing a volunteer forum with global reach isn’t quite as simple as you might think.

    But, bearing in mind the requirements, is it as simple as it could be?

    2) Re

    Easy automated systems are easy to abuse. A simple button to “do the thing” would lead people to click the button.

    That is what makes it easy to use – to report the ads/spam, or other factors (e.g. abusive language)

    If you can’t be bothered to make a post, then is your report really all that valuable?

    Value of something is not based on how tedious it is.
    But consider the corollary , if the action of receiving reports of ads/spam (or any other action) is so important, then why make it so difficult. It is usual to encourage favorable actions by making them easy.

    3) Re

    I can make a button to do anything, but will the button work?

    Hopefully the developers that “make” a button would not consider it to have been “made – ready for use”, if it does not work, at the time they make use of it on a large website.

    4) What may be of a high priority is ;

    Or will it lead to more work for our unpaid volunteers?

    And this may be well worth some attention.
    For example, in general, consider all the tedious tasks that the unpaid volunteers do, and consider how they might be automated to assist.
    In this case, consider how an increased number of ad/spam reports could be handled more easily.
    At first there would be an increase in the number of reports, but then when advertisers and spammers find the game plan has changed, then (hopefully) they will be deterred.

    Hi Stephencottontail,

    Thank you for clarifying what you had said. What I had said was intended to find the common ground amongst what you and Otto have said, to seek a solution.

    You have suggested ;
    a) the “mark as” function to make it easier, and
    b) the report does not need to be in the posting (whether or not there is a report required), as per ;

    There is a ticket for regaining the ability for anyone to add the modlook tag without having to make a post in the thread

    Otto has re-iterrated that he considers that
    a) a report is required
    b) the report must be (it sounds like this is mandatory) placed in the topic forum
    c) as little automation as possible should be made available so as to deter the reporting of these matters.
    and he effectively adds that a matter of concern is that such ease would lead to an increase in workload for the volunteers (who as I have added above, might enjoy benefits from a similar approach to automation of their own systems, if such improvements are permitted to be imagined).

    As determined by Otto ;
    a) the “mark as” easy feature is out of the question.
    b) there is the present reporting method

    and, yet to be finalized,
    is your second consideration, of the reporting (which as in b above must be done verbosely) that must be posted in the topic forum.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    A button is too easy.

    People will click the button even when they didn’t want to do that specific thing. Because people are stupid.

    We have a button to subscribe to individual plugin forums. People click it and then complain when they get emails, because they don’t understand what “subscribe” means. And then they fail to understand when we tell them to click the “Unsubscribe” button.

    So yeah, I’m jaded about making things easy. There has to be some kind of way to gauge “intent” to the point that we believe that yes, you actually did mean to do that thing, whatever that thing is.

    A button is too easy.

    Edit: basically, I’m talking about a UI thing, not anything else. If we make it easy to report things, then we get spurious reports. If we make it hard, then we don’t get any. A happy medium is needed. The tagging method used previously worked, but isn’t the easiest thing to do in the current forums. But it can be done, and probably should at least be tried out

    Thank you, everyone, for sharing your thoughts.

    It was really a healthy discussion.

    Eventually, we all are trying to make WordPress and our community forum even better.

    Thanks again!

    Hi Folks,

    Looks like we are able to toss a few ideas around.
    It is looking like this may end up now where,
    but at least it hasn’t had the brakes put on it.

    Continuing ;

    Re my comment on the concept of

    Hopefully the developers that “make” a button would not consider it to have been “made – ready for use”, if it does not work, at the time they make use of it on a large website.

    And Otto’s concerns with the following examples of detracting factors

    a)

    People will click the button even when they didn’t want to do that specific thing. Because people are stupid.

    (note – some more elderly ones may have had a spasm or coordination problem between looking at the screen and moving the mouse button down, or brain fades after long hours – yep humans! People seldom ask computers what they think of humans.)

    b)

    We have a button to subscribe to individual plugin forums. People click it and then complain when they get emails, because they don’t understand what “subscribe” means. And then they fail to understand when we tell them to click the “Unsubscribe” button.

    c)

    There has to be some kind of way to gauge “intent” to the point that we believe that yes, you actually did mean to do that thing, whatever that thing is.

    d) and notably

    I’m talking about a UI thing, not anything else.

    Otto has explained why a button is not a good approach “because it does not work”.
    If it does not work, then “is it really made”.
    The way to make a button work (well), is to make it so that it solves these problems.
    To solve the problem with the buttons (and any process) involves writing text or code, or both. But also hopefully, that will reduce the amount of time needed by staff to manually handle each person’s problem, with time delays.
    So re-languaging this situation, is “we need a (something)(to make an improvement), that can overcome the following (reasons why it can not yet be done)”.

    These suggestions may or may not help with avoiding some of the concerns ;

    d) This is a most important observation to appreciate this circumstance – it is a “User” interface (to the “System” – the other party).

    a) For (a), In this case, make use of a confirmation question, prior to committing the change. and have a ‘cancel’ option, just in case they find the confirmation question confusing as well.
    Note. also for the elderly, or less coordinated, or poor eye sight users, bigger buttons and fonts for the more critical tasks.

    b) For (b), this can often be due to a compounding of two factors;
    i) the explanations supplied from the system to the user, at any or all stages of the ‘process the user is going through (being lead by the system?)’.
    ii) the way the ‘user reads/senses the system’ or the way the ‘system provides impression/perception/cognizance to the user’ (see note ** below).
    This is easily measured by the statement ;

    they fail to understand when we tell them

    But we can break this down a little;

    they fail

    this event is conceptually placed in the “them” basket,
    with a status of “failure”

    to understand

    It is them, the did not “understand”.
    Perhaps we need to remember that anybody using a computer, to work with a literary and/or technical tool like WordPress, has to have a minimum acceptable level of intelligence. So assuming that not everybody who doesn’t “understand” is inherently incapable of understanding, the we are lead to the question of “why didn’t they understand”?
    There is the possibility that perhaps ‘it may not have been clear enough’.
    How much ‘enough’ is needed, may be something that would require exploration/experimentation to find out.
    But also, if the number of times the same event happens, the more the cause needs to be looked for, and it may not be the assumed cause.
    when

    we tell them

    This is the most important point in this comment.
    A scenario is created where you have to tell them (frequently?) by manual means (even if it is a cut and paste from a text file).
    So hopefully there could be a button for the “we” to use, assuming that the “we” does not make the same mistakes when pressing a button, like “they” do.
    That’s two possible improvements, from that sentence;
    – aim for a system that minimises the need for manual response
    – where manual response is required, than make the tools as automatic as possible.
    But there is also an important lesson that might be learnt (even something for AI), and that is. What is it that the “we tell them”, or ‘how are they told’, or ‘how is it explained to them’, that the system had not done prior to that point, and what makes parts of the additional explanation the difference? (and what still does not make a difference)
    Learning what that information is, or learning how to better explain it, then means the the system can then have that improvement built into it as part of the process the user has at the earlier stage.
    This is similar to going through FAQs on a website, and categorizing questions/answers together every so often, and convert their content in to “how to” type instructions/pages, so the information becomes more integral and structured (less hap hazard).
    Or for a business, it is similar to customer inquiries, after a couple of emails, one may chose to copy and edit the contents of a response, and add it to a web page, to save time for future customers, and free up the business’ staff.

    c) For (c) this is similar to (a), confirmation is needed, and, it needs to be good enough to reduce the frequency of mistakes.
    Another way to measure a successful outcome, is to result in less time spent manually handling the adverse events.
    It must be noted here, that there is/was a button for subscribe.
    So at least that has/had a button for that function.
    If that button exists, and that problem remains, then the button has not been removed, because of the problem of mis-clicking (and a proportion of manual communications for staff). So this might be, that even though there is a problem, it is considered workable (may be not optimal), rather than ‘should not be done’.
    So if the subscribe button remains (which by the sound of it, it may), then the number of incidences of mis-click and manual communications for staff, may be improved by use of a confirmation stage, and providing better explanatory information (prior to the stage of mistake, and ‘at’ the stage of mistake).

    If those improvements, are found to work well for that subscribe button, then they may be deemed practical for other buttons, possibly including the button of this topic.

    Note ** re subscribe/unsubscribe button.
    a) Some options are set by drop down menus in wordpress.org.
    Others (particularly in WordPress dashboard are set by toggle switches.
    These toggel switches are not just a “toggle” switch, because what they (the buttons by the ‘system’) also do, is intuitively ‘display/convey‘ to the ‘user’ that there are ‘two states’ (and what those states are), and they are set in the same place (and do not require going somewhere else to reverse a state).
    b) a sure way to connect information to a button (and same for links), is to have a popup box appear that explains, what this exact thing does. And connect it with the button (as in it is part of button coding, to require the explanation text, which may include a link to further information).
    c) help may additionally be available through help text on the same page, a downloadable user manual. But the closer at hand the help, the more likely it is to be seen, and therefore more likely to be read (not that that is a 100% all the time).

    So there’s a few thoughts, and ways of thinking.
    Even if buttons are to not be made so readily available to front end users, some of the hard working staff might appreciate some improvement on the back end (though only they would know – not me).

    Hoping some of this is of at least passing interest.

Viewing 11 replies - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.