So it took me five days to actually get a comment that passed Bee and Block and went to Bayes, but now I have an improvement to Bayes to suggest as well as an observation about our message system (which I'm not sure we can do anything about).
First,
this is the comment, and it's pretty obvious
why Bayes thinks this is 88% spam. It quotes an English error message. However, the usability issue at hand here is that Bayes states (see
Don's screenshot earlier in this thread for an example):
and that is not
completely true in my case because I use the Bayes thrashcan. So while it may
technically be a rejection that is kept in the thrashcan, it is actually (in my opinion) a moderation, and I think Bayes should reflect that somehow in the message text (“classified as spam” comes to mind, but it should at least reflect that the comment needs to be revised by a human and is not lost altogether). I think the problem is that Bayes tries to re-use old lang constants instead of using new, more specific ones?
[First-hand experience, this usually leads to two things (I have experienced this before, but I did not know how to react to it then): a) the commentator immediately tries to comment again because he thinks there is some error in the system (“My comment can't be spam!”) and b) I get (because I know the commentator) an angry DM on Twitter “Why does your stupid blog think my comment is spam?”]
And the second thing is the color of the message, which is not related to Bayes but to the core. As far as I can see, the core historically only knows (and styles) two types of messages:
- serendipity_msg_notice – success, positive, green
- serendipity_msg_important – error, negative, red
In older themes, everything that is not clearly either one of those is styles as serendipity_msg_important, which I did not do here (technically, I use a third class serendipity_msg_info). However, the issue is that as a theme author, I can not always tell which type of message will be emitted.
This example from entries.tpl illustrates it well:
Code: Select all
{if $is_comment_added}
<p class="serendipity_msg_notice">{$CONST.COMMENT_ADDED}</p>
{elseif $is_comment_moderate}
<p class="serendipity_msg_info">{$CONST.COMMENT_ADDED}{$CONST.THIS_COMMENT_NEEDS_REVIEW}</p>
{elseif not $entry.allow_comments}
<p class="serendipity_msg_important">{$CONST.COMMENTS_CLOSED}</p>
…
The first one is clearly “success”, the last one is clearly “error”, but the middle one is … hm … I would say somewhere in between. It's not an error, but not a confirmation, it's more of an information or a hint, and in some cases (like here), I can actually tell that fact and use a third class (like I did). But what about (from old default template)
Code: Select all
{foreach from=$comments_messagestack item="message"}
<div class="serendipity_center serendipity_msg_important">{$message}</div>
{/foreach}
I literally have no idea what kind of messages this could emit, especially with plugins being able to hook into these.
I know this is not easy, and I'm sure it's not something we can just change, but I feel we should at some point think about our messaging system and maybe revise as well as extend it …
YL