Re: [apps-discuss] Call for Adoption: draft-ordogh-spam-reporting-using-imap

[Ned Freed <[e-mail]>]

> On 5/12/2012 8:20 AM, Ned Freed wrote:
> >
> >     (1) The message was classified as spam and the user has not said
> > anything.
> >     (2) The message was classified as spam but the user says it isn't.
> >     (3) The message was not classified as spam and the user has not said
> >         anything.
> >     (4) The message was not classified as spam but the user says it is.
> >
> > You cannot represent all of those in a single bit.


> Correct, and I think we should /not/ try to represent all those cases.

Unfortunately, failure to allow for all of these cases will prevent the
interface from being effective in all cases.

> Rather, I think we need one bit, which is a "current" classification of
> the message as spam or not.  How that bit gets set should be kept a
> separate matter.  Might be set by the system.  Might be set by the user.

Then unless you report transitions of this state, this fails to support
the functionality current UIs provide.

> My understanding of research on user-level spam control is that one bit
> is sufficient and more than one bit is confusing, even given the fact
> that user's often invoke the spam button to mean "unsubscribe".

You're confusing what's presented to the user with what has to be stored behind
the scenes. These are not the same, and as I pointed out previously, all of
these states can be, and usually are, trivially presented as a single button -
essentially a "click if you disagree with the current state" control.

				Ned