Engage / ArtifactView / Comments

[James William Yoon]

 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 <hugues.boily at mccord.mcgill.ca
> 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 <james.yoon at utoronto.ca
>> <mailto:james.yoon at utoronto.ca>> 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 <michelle.dsouza at utoronto.ca
>> <mailto:michelle.dsouza at utoronto.ca>> wrote:
>> Forwarding to the list because I accidentally took this off list.
>>
>> Michelle
>>
>> Begin forwarded message:
>>
>> From: Joan Garcia Vila <jgarciavila at uoc.edu<mailto:jgarciavila at uoc.edu>>
>>
>> Date: November 30, 2009 11:11:30 AM EST
>> To: "michelle.dsouza at utoronto.ca<mailto:michelle.dsouza at utoronto.ca>" <
>> michelle.dsouza at utoronto.ca<mailto:michelle.dsouza at utoronto.ca>>
>>
>> Subject: RE: Re: Engage / ArtifactView / Comments
>>
>> Hi michelle,
>>
>> A boolean is good for me.
>>
>> Cheers,
>> Joan.
>>
>> --> Missatge original de Michelle (michelle.dsouza at utoronto.ca<mailto:
>> michelle.dsouza at utoronto.ca>) 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 (james.yoon at utoronto.ca
>> <mailto:james.yoon at utoronto.ca>) 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 <
>> james.yoon at utoronto.ca<mailto:james.yoon at utoronto.ca>> 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 - fluid-work at fluidproject.org<mailto:
>> fluid-work at fluidproject.org>
>>
>> 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 - fluid-work at fluidproject.org<mailto:
>> fluid-work at fluidproject.org>
>>
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>
>>
>>
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org<mailto:
>> fluid-work at fluidproject.org>
>>
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20091207/b3b682af/attachment.htm>