I would have the following "worries":
- performance of pulling / update object on images individualized by
recipient, if there are really many recipients (which is in general the
case for an "Announce")
Yes, I had realized that and expect to use it for associations with less than 100 intended
recipients.
- what if recipients are distribution lists or generic
emails ? (that's
also often the case of "Announces"). I don't think there's any easy way
to
know what are the "real" recipients behind ...
As good as email can be; this is true.
Although I do not know how to implement it, I would favour to use user-names and resort to
individual emails separately.
This also supports better the read-witnessing (avatar, user-name, ... no cryptic emails).
You could also have a look at return receipt [1]
though it's a pretty
uncertain mechanism.
It seems to have gone away from most email clients nowadays. I am not sure why.
Though quite different use-case, the most similar I
know may be the
Newsletter Application. Ideally, I suppose some "Distribution List
Application" may be a nice addition, to be (re)used both by the NewsLetter
application and your proposed app ;-) So you could create DLs inside the
wiki, then send an Announce or a Newsletter to a particular DL (instead of
relying on DLs managed by various email or mailing lists servers - but on
another side, that's encroaching on those servers' territory :) ).
[1] -
http://en.wikipedia.org/wiki/Return_receipt
[2] -
http://extensions.xwiki.org/xwiki/bin/view/Extension/Newsletter+Application
Where I found the idea of announce nice is that the content of the announce is visible as
one page and its "reads" are displayed there as well.
People can refer to it and show it to each other.
Compared to a newsletter distribution list, a facet of an association with local activity
is that the names and faces of others are almost all known so that displaying the
recipients name is a good idea.
I do not seem to see this there.
The template approach might be useful indeed but it seems a bit "profesional
oriented". Also, I strongly refuse to send PDF files instead of email bodies as this
encourages weight in the mailboxes, left-around-files in the attachments' temporary
directories, and almost encourages the people to print.
paul