There is also the issue of bots triggering the report abuse link. Out of
175 abuses reported in comments on our web site, all but a few were
false alerts.
Hugues
-------- Original Message --------
Subject: Re: Engage / ArtifactView / Comments
Date: Mon, 7 Dec 2009 13:45:48 -0500
From: James William Yoon <[email protected]>
To: Hugues Boily <[email protected]>, "[email protected]"
<[email protected]>
CC: Fluid Work <[email protected]>
References: <30137311.362731259597492454.javamail.r...@canet>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Hullo,
I have some thoughts on this. To avoid accidental input of a "report abuse"
button it would be good
to ask the user for confirmation via a dialog/pop-up.
This is a great idea, though it does come down to a question of balancing
between: a) attaining further confirmation to avoid accidental input, and b)
forcing an additional step on the user to report abuse. I imagine it'll come
down to: 1) how likely accidental input would be (e.g., how near the button is
placed to other inputs, how big the button is, where the button is placed in
relation to the rest of the screen, etc.), and 2) how harmful accidental input
would be (e.g., is it destructive?), especially if we already have other
measures in place to distinguish between accidental and intentional input
Regarding the reset of the function I think that there should be no reset for a
user-comment combination.
This means if a user flags a comment as abuse this should only be possible
once. If no user management is done (sign in without authentication or with
pseudonym) any user can abuse the system and flag a comment multiple times by
login out and in again.
Another great point, though if I understand your suggestion correctly, it would mean that a comment flagged
by one person as "abuse" would either appear as "abuse" on all users' screens without
giving them the ability to report as abuse as well (i.e., definitively declaring that the comment is
"abuse"), or not appearing at all. The problem with this solution, which prevents multiple count
abuse, actually makes it easier to abuse the system--consider a user who marks all comments as abuse. His/her
mark would be considered definitive until the moderator reviews all the comments.
On the other hand, multiple count abuse (logging in and out again multiple
times and reporting abuse) would be a tedious task for the offender--he or she
would need to have quite the personal vendetta against that one comment!
The user comment section of the CBC News site uses a similar approach. For
example, see :
http://www.cbc.ca/money/story/2009/12/07/building-permits-october.html
Indeed--CBC does have an additional confirmation via a dialog for report abuse.
Interestingly enough though, when you reload the page, you can report abuse to
the same comment again (I tried it on a suitably offensive looking comment).
Cheers,
James
On Mon, Dec 7, 2009 at 11:45 AM, Hugues Boily
<[email protected]<mailto:[email protected]>> wrote:
Hi guys,
The user comment section of the CBC News site uses a similar approach. For
example, see :
http://www.cbc.ca/money/story/2009/12/07/building-permits-october.html
Hugues
Armin Krauss wrote:
Hi James,
I have some thoughts on this. To avoid accidental input of a "report abuse"
button it would be good
to ask the user for confirmation via a dialog/pop-up.
Regarding the reset of the function I think that there should be no reset for a
user-comment combination.
This means if a user flags a comment as abuse this should only be possible
once. If no user management
is done (sign in without authentication or with pseudonym) any user can abuse
the system and flag
a comment multiple times by login out and in again.
Armin
On Mon, Dec 7, 2009 at 10:01, James William Yoon
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
wrote:
Thanks for bringing this question to list!
Let's actually keep a count of the abuses (i.e., use integer instead of
boolean).
Doing so would afford us the following benefits:
a) Accidental, unintentional tapping of the "report abuse" button would have a
less significant effect (lower count)
b) Individuals abusing the "report abuse" button (e.g., users who maliciously
attempt to have other people's legitimate comments removed) would have a less significant
effect (lower count)
c) Crowd sourcing: if many people find something offensive, there's a good
chance it's offensive (although the flip side of this democratic morality is
that marginal users who genuinely find something offensive would have a less
significant effect on the abuse count)
The upshot of all of this is that the moderator can prioritize which comments
to look at first and delete, instead of wading through a potentially long list
of not-necessarily-offensive comments.
Also, I imagine you've already taken this into consideration, but the report
abuse functionality should probably be reset for each session or login, and not
by IP since it's quite possible that multiple users will have the same IP when
in the museum, especially if they're using a museum device.
Cheers,
James
On Mon, Nov 30, 2009 at 11:19 AM, Michelle
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
wrote:
Forwarding to the list because I accidentally took this off list.
Michelle
Begin forwarded message:
From: Joan Garcia Vila
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Date: November 30, 2009 11:11:30 AM EST
To:
"[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>"
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Subject: RE: Re: Engage / ArtifactView / Comments
Hi michelle,
A boolean is good for me.
Cheers,
Joan.
--> Missatge original de Michelle
([email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>)
per a Joan García Vila enviat el 30/11/2009 17:04:49
Hi Joan,
One question about the abuse attribute. Are you using it as a boolean or are
you planning to keep a count of the number of times abuse has been reported? If
it's a boolean I would suggest that you use a boolean instead of an integer.
Michelle
On 2009-11-30, at 6:22 AM, Joan Garcia Vila wrote:
Hi James.
Many thanks for your quick response.
Only one more question/suggestion:
- ... when user clicks "report abuse" , the comment is marked (attribute abuse=1) and
becomes out off the view. In this way, user who reports sees the comment disappear which is good
("Something happened in the UI after a click it done"). That is, the comments lists is
filtered (comment.abuse != 1).
When the moderator decides that the comment is "abuse" hi can delete it. But,
if he decides the opposite, the abuse attribute is set to 0 so it will become visible
again.
Makes sense?
many thanks in advance,
cheers,
joan.
--> Missatge original de James William Yoon
([email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>)
per a Joan García Vila enviat el 26/11/2009 20:16:22
Woah, that was weird. Copying and pasting from the Jira comment somehow copied
both raw text and the marked up text. Apologies for the redundancy.
On Thu, Nov 26, 2009 at 2:09 PM, James William Yoon
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
wrote:
Hey Joan,
Great question. I've posted a comment to the Jira. Here's a copy:
"Report abuse" functionality hasn't been fully fleshed out, but the idea
scaffold is as follows:
- User taps "Report abuse" for a comment
- List of reported comments abuse on museum moderator/administrator's side
would update to include said comment
- At this list, moderator should be able to see all the abuse-flagged comments,
and delete/hide comments as necessary
_______________________________________________________
fluid-work mailing list -
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
------------------------------------------------------
Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto
_______________________________________________________
fluid-work mailing list -
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list -
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
