Jim Ramsay <[EMAIL PROTECTED]> writes:
Jason R. Mastaler wrote:
Jim Ramsay <[EMAIL PROTECTED]> writes:
First, it's non-intuitive. In general, if presented with a GUI that had separate buttons for whitelist and release, I'd expect each to do only their job, not trigger one another.
I disagree with you here. I would intuitively assume that when I whitelist a pending queue message that message (since I just whitelisted it's sender) would then fall through into my inbox. I know this isn't the way TMDA thinks of it, though.
I suppose in my mind there is the distinction of whitelisting an /address/ which would mean "Let everything from %n from now on through my filter" and whitelisting a /message/ which I would consider meaning the queue owner wants the message in question and everything thereafter which comes from the sender.
That said, it would be good to have common terminology between TMDA and tmda-cgi, since they are so integrally related and users come to the same lists for help with both/either.
I agree that we need a common terminology. We have had an historical distinction between whitelisting and releasing but after some thought, I've come to a similar conclusion as Jim. The distinction only works in one direction. That is, I can easily understand a desire to release a message one time but not whitelist the sender -- two distinct actions.
From the other direction, though, I have a hard time envisioningwhitelisting a sender but *not* releasing his/her message. "I just got a piece of crap from someone and, while I don't want to see this piece of crap, I'd like to ensure that future pieces of crap from the same sender get through." Just doesn't work for me at all.
So I think some sort of terminology revision is in order. I spent a number of years in previous life researching and implementing user interfaces on Windows (yuck!). One very important basic tenet of UI work is that users often have a "mental model" of how something works that is wildly at odds with the "implementation model". And that's ok; the mental model is usually a simplification that helps them understand the consequences of their action.
I mention this only to suggest that, while the code implements whitelisting and releasing as separate actions, neither term is necessarily the best term for the interface, although I'm not ruling them out, either. I'm just pointing out that the interface should model what the user thinks is happening, regardless of what we have to do on the code side to "make it so!" (too much ST:NG as a youth...).
Good points!
Gre7g and I have even toyed with the idea of releasing ALL messages with an envelope sender equal to the whitelisted address if someone whitelists a message. This is a little more extreme than just releasing the single message, but it also makes sense: If I've whitelisted someone, I don't what ANYTHING of theirs to be in the pending queue.
<snip... other excellent points made...>
Lastly, why is it necessary for whitelist/blacklist to trigger release/delete when the PENDING_RELEASE_APPEND and PENDING_DELETE_APPEND are available? One just has to set them to get the same behavior if desired.
Hmmm... good point, except that this is restrictive in a different way. If I set PENDING_RELEASE_APPEND and then come across a message I want to release but /not/ whitelist, I am unable to do so without 1) Exiting the pending utility 2) Editing my config file 3) Finding and releasing the message again 4) Setting my config back to the way it was. As for why it is necessary, it makes sense from a useability standpoint since I never "just whitelist" - I always whitelist and then release. It makes sense to me to have a quick/easy way to do both at once.
Yeah, I agree here. There are two positive actions (talking about releasing/whitelisting and ignoring delete/blacklist) that a user would typically make regarding a message stuck in pending: release it (one-time only, no whitelist) and release and whitelist. Setting PENDING_RELEASE_APPEND to the whitelist means I can't just release. Setting PENDING_WHITELIST_APPEND means it takes two steps to do the most common action. Neither of these situations is ideal.
More discussion is clearly warranted.
Perhaps we can go a couple different directions with this, so I'll propose a few solutions we can consider:
1) Change the phrases "Whitelist" in TMDA to mean something different.
I personally don't like this one, but I thought I'd write it down just to get it out of the way. Whitelisting in TMDA means exactly "add this address to a list of allowed contacts", and I think the name is a perfect explanation of what is happening.
2) Change the phrase "Whitelist" in TMDA-cgi to something else more indicative of what is happening.
This will be tricky, mostly because I don't know of any phrase that would do in it's place meaning "Add this address to a list of allowed contacts and then release the message to my inbox". We could do a two-word phrase, like "Whitelist and Release" but then the interface would get uglier and bigger. An icon may be easier to do, as we have a good one for "release" (A checkmark), and a pretty good one for "whitelist" (a white box with writing in it, like a list) which we could combine, but we would need an associated word/phrase also. All the synonyms I could find at thesaurus.com for "allow" looked like they were lacking a bit in meaning, and too easily confused with "release".
3) Agree and acknowledge that there is a distinction between TMDA's "Whitelist" and tmda-cgi's "Whitelist" and just let them be different.
Not really the best solution, since people sending to tmda.users sometimes don't know if they're using TMDA or TMDA-cgi or what, and confusion abounds.
4) Keep the meaning "Whitelist" the same as TMDA's (only add to list, do not release), but add an option (either in TMDA or TMDA-cgi) for "Pending-whitelist also releases" which people can set to "on" if they want this to be the default behaviour. Or it could be on by default (I suggest that this is more correct) and people can set it to "off" if they don't want it for some reason.
I am leaning toward this one. This way meaning stays the same, and all confusion about what is happening disappears once the user posts his/her config file and we see how he/she has it set.
If the option is part of TMDA, this solves the tmda-pending issue as well as the tmda-cgi one, as they would now be doing exactly the same thing all the time.
In other words, a user could set:
PENDING_WHITELIST_APPEND=path/to/list-file PENDING_WHITELIST_RELEASE=1
and whitelisting a message in tmda-pending or tmda-cgi would automatically release it.
To use Tim's terminology, this would clarify to everyone, old TMDAers and new, what their "Mental Model" of "Whitelisting" really is, or whath it should be. I hope most users would think to themselves (assuming that users think...), "I can see that PENDING_WHITELIST_RELEASE is ON, so whitelist means 'add to my list and let the message through'" or "I just turned PENDING_WHITELISTE_RELEASE to OFF, so whitelisting just adds to my list and will not release."
I would be happy to code #4 if people think it's a good idea. It could be done in two ways:
If the change is made in TMDA/Pending.py::Message, a simultaneous release of both TMDA and tmda-cgi would be required so that tmda-cgi does not try to release a message twice, or a new method would have to be added to the Message object (not called Release) which would process the new variable properly.
If the change is made in tmda-pending and tmda-cgi directly, no simultaneous release is necessary.
Please let me know what you think!
-- Jim Ramsay
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
