[albatross-users] revisiting checkboxes..

[Eric S. Johansson]

Michael C. Neel wrote:

> First is, it seems you want the list of none-checked items.  This seems
> odd; possbily consider changing the interface so that the user checks
> the list you are really looking for (i.e. if they check the messages to
> keep; have them instead check the ones to deleted?).

we went around the barn on the user interface for the spamtrap quite a few 
times.  We've tried radio buttons, submit buttons on each line etc. but what we 
currently have seems to be the best minimal user interface.

we start out with the following text:

Instructions:

Messages in the red area are strongly suspected to be spam. They have been 
pre-checked.

Messages in the yellow area may be spam, but it's not certain. They have been 
left un-checked.

Your job is to verify that each message is classified correctly; then press 
"Train" to train the anti-spam system with this new data.

     * If the email is spam, tick the checkbox.
     * If the email is not spam, clear the checkbox.
     * If you are not sure, check the message detail by following the subject link.
     * Click "Train" when all the messages on the screen are correctly marked as 
spam/not spam.
     * Repeat until all messages have been processed.

To update the spamtrap display, click Refresh Display <<== link

======

then under this is the table of spamtrap items color-coded according to score as 
well as checked according to score.  I use the checkbox state on submit to 
decide whether or not to pump the message into the train-as-good or train-as-bad 
paths in the spam discriminator.

> There is the "if list not in list" python statement you can use.  This
> uses the store the list in the session; which I also have done with
> large database results before without trouble (the reason there was the
> querey was done once and not for every page or re-sort).  I would have
> done even larger blocks of data, but file objects cannot be pickled =)
> (and that's probably a good thing).

I'm currently trying the attribute method.  I was fighting refactoring the code 
and was trying to stick with mostly the same structure of a standard CGI.  Then 
I realized (for 10 billionth time), that if I'm encountering significant 
resistance solving a problem one way, I'm solving it the wrong way.  So I gave 
in, started refactoring and it feels easier or at least cleaner than the code 
ahead before.  It's not the best class I have ever written but it sucks less 
than a black hole[1].

I think storing the list and extracting information by set operations will be my 
method of last resort.  It falls the category of brute force/bloody ignorance.

> I don't know the details of your app, so I'm not sure if the above are
> options or not, but just wanted to toss them out there.

I appreciate the effort.  I hope my explanations clarify some of the constraints 
I have on the implementation.  Fortunately, I think the Web interface for the 
user configuration and the dumpster tool will be much easier.  When I can show 
them off, I will send the list a URL.

---eric

[1] yea, yea, yea, I'm an astronomy geek in addition to ham radio and computer 
with a taste for bad jokes.