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 envisioning whitelisting 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...). >> Next, it runs counter to the behavior of tmda-pending which is >> confusing. > > Right, but I think that tmda-cgi is mostly geared to users who don't > have shell access and couldn't/shouldn't run tmda-pending (so they > wouldn't be bothered by such a distinction anyway). > > On the other hand, users moving from the cmdline to tmda-cgi may have > a difficult time adjusting. I agree with you that a terminology > adjustment is a good idea. And another point, if we decide that a particular terminology and implementation is best from the UI perspective, tmda-pending can change as well. It's not as if God engraved it on tablets (and put it in an Alabama courthouse). >> Further, it's restrictive. If I just want to whitelist or blacklist >> the message without releasing or deleting it, I can't. > > I don't know anyone who's wanted to do this, but I can add a separate > option for those who may want it. Again, this one doesn't make sense to me. Just because it might be physically possible to stand on my head while taking a shower doesn't mean the manufacturer of the shower has to go out of its way to make it easy (the floor's too hard, the water jets the wrong way...). > From a useability standpoint, I think we should provide easy one- or > two-click options for "commonly used" functions and provide > less-commonly used functions elsewhere. I think this is a good strategy in general. More commonly used (and expected) behavior should be easy to get find. Less commonly used should be available but shouldn't clutter the UI. It's just distracting and thus confusing. >> 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. Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
