Forum OpenACS Q&A: Simple, default form for Spam module in OpenACS 4.x

I've been playing with OpenACS 4.x over the last number of months, but
I've finally installed it onto a client's system and beginning to use
it for real work.

So first: I'm extremely impressed.  It's really amazing to see how
many things are improved over OpenACS 3.x.  Installation requires some
attention to detail, but is so much better than previous versions, I'm
not going to pick nits.  Kudos to the development team!

Now, to my question: In OpenACS 3.x, the Spam module brought up a
simple HTML form from which I could choose all sorts of user
attributes to create my dynamic query.  It looks like the Spam module
in OpenACS 4.x still has all of the old capabilities, but without the
built-in form.  Building a simple form that invokes Spam doesn't
strike me as particularly difficult, but I was wondering if this was a
deliberate choice by the development team, or simply the result of a
lack of time?

The included documentation  (written by ArsDigita) indicates that "ACS
(site-wide) admins will have a page for entering arbitrary SQL queries
for picking groups of users," which sounds like the old system.  Am I
missing something?

Yes, I think the lack in the spam module is due mostly to time.  The 4.x Tcl code base was never completed by aD.  There will be some new spam capability in dotLRN but it's probably tied fairly closely to the structure of that system.
I am working on a new Spam module that will use acs-mail-lite and will
support interpolation of variables in the spam subjects and messages. For
now I am building only APIs, we can add some useful HTML forms for building
queries later.
Yonatan -- how close is your API to being finished?

I might be able to help, although I'm still learning the differences between OpenACS 3.x and 4.x.  I also don't see the acs-mail-lite package in the nightly tarball, although acs-mail is there, if only in the documentation.

I've pitched OpenACS to a number of clients lately, and I was surprised to discover that they all see Spam as a fantastic tool for sending targeting mailings to their members.  I wouldn't want to have to offer them OpenACS 3.x, simply to satisfy this particular need.

If I can make a suggestion...

Can we change the name from "Spam" to something like "Directed mailings"? Spam never had a particularly good connotation and now even non-geeks understand that the term is bad.

So how about something a bit more, uh, marketing friendly?

talli

Yes, changing the name would be a very good thing.  "Spam" is amusing and all, but it doesn't go over very well with my clients.  "Directed mailings" or "targeted mailings" would be a major step forward.
FWIW, we find that people chuckle over the Spam module even if they ultimately ask us to rename it.  I suppose there are some particularly uptight management types out there who wouldn't see the humor in it (probably more than I'd like to think) but for those who do get it I think it makes the toolkit a bit more approachable, gives it a sense of humor.

I'm not really opposed to renaming it if the name is causing problems but thought I would present the other side.  If I were choosing a name I'd call it "bulk mail";  short and to the point, as most of the module names are.

The easiest way to solve this is to add a package param to replace the word "spam" everywhere it appears, and point out to the prospective client that you can now mount it under any name you choose, so there's no reason for any user to ever see the word "spam" if they don't want them to.

I like "bulk mail." It avoids the "spam" problem without resorting
to marketing euphemisms. "Mass mail" works OK too, as would
"broadcast" (as in "fax broadcast"). Overall, though, "bulk mail"
would be my first choice.
Yes, I too vote for a name change.  When the first instance of "spam" was written (1996? 1997?) for photo.net, the term still had a harmless, almost cute connotation.  It is no longer in the least bit funny.
"bulk mail"

short and functional... sounds good.

I really like Janine Sisk's suggestion above (package param, with the standard value set to "bulk mail"), it would allow easy translation... not only for the uptight management types, but for the germanotypes, francotypes, and what ever other types you want to add.

How far will this version of "Spam" be from something we can call "General Alerts", a service that other packages can use to send email to a list of users.

Sloanspace V-1 uses the word "Alerts" as a general term to describe BBoard email as well as admin notifications for certain a survey being filled out, or a user requesting membership in a "request membership" group.

Users are requesting (but we haven't yet started work on) even more alert capabilities, such as calendar reminders, notification of file uploads. etc.

I'm fine with "Bulk Mail" but it might imply to some developers that they should only use it if they will be sending a large number of messages.

Also someday in the glorious future, someone might want a system that lets a user choose if they want communication to be by email, AIM, a page to thier cell phone, etc.

I was going to mention the mobile aspect (a much neglected element).

It's probabyl worth considering a more general text-messaging solution that doesn't force/specify the devliver medium.