Devleoping a Product to Create and E-mail Newsletters

3 Messages

George L

Devleoping a Product to Create and E-mail Newsletters

Reply Threaded

Hi,

With the fall comes my chance to do a little more programming than the spring or summer. =) And I'm excited because now I can ask questions on product-developers to get guidance on the overall idea and framework for a product I'm working on -- the list wasn't around a year ago.

I doubt I'd be able to see this all the way through to the end to make a really polished product a lot of others will use, but I think I can make a pretty good version that if other people want, they can take to another level. But to make it more likely the code is useful, I want to talk with folks about it first!

I'm working on a product to create and e-mail newsletters, including newsletters that compile summaries of different content objects ("Upcoming Events," "New Job Postings," etc.). I created an old version for Plone 2.5 last year using Zope 3 views here and there to give some more power and flexibility to the the newsletters, but it was fairly rough.

I'm taking some inspiration from Constant Contact - when I tried editing an e-mail through their interface, it was pretty useable. Basically you choose a pre-defined template, which consists of a few different parent blocks; within each parent block, you can add different subblocks of predefined types ("Greeting," "Article," "Coupon," etc.); then you can edit the settings of a subblock - style, color, main iamge, add regular text, add rich text and images and links, etc.

I worked on a rough prototype of this and then afterward thought - hey, this reminds me of viewlets. But viewlets were too rigid because of all the wiring required just to associate viewlet managers with viewlets, on a site-wide basis rather than per newsletter. Then I thought, this reminds me of portlets! And that's where I'm having a lot of fun, using plone.portlets to set this up. I have a partial version of the product done that can display newsletters and allow some editing using the plone.portlets edit views, so in terms of using plone.portlets a good chunk of that work is done.

Here's my plan, and some questions. Here's how I imagine a user adding a newsletter.
* Initially, for simplicity and also to centralize newsletters since too many shouldn't be going out all the time to a bunch of the same people, newsletters are added in a central place. The current plan -- in the same way as content rules, have a centralized storage utility at the Plone Site root, accessible via plonesite/@@manage-newsletters
* When a newsletter is created, a user decides what template to use for it. The newsletter than automatically creates an appropriate number of "newsletter area" objects, stored in a PersistentMapping. Each newsletter area object corresponds to one of the main parent blocks of a newsletter. The user assigns portlets to the newsletter areas - with a set created by default. The types of portlets available to a newsletter area are pre-wired.
* The portlets are stored with the help of a portlet manager designed specifically to keep track of newsletter areas. It took me a while to understand this, but a portlet manager is not "an object that stores portlets" - but rather, "an object that can say how to store portlets associated with different objects." So plone.dashboard1, plone.dashboard2, plone.dashboard3, and plone.dashboard4 are associated with site-wide portlet managers that manage how portlets are assigned to the first, second, third, and fourth dashboard columns for different users.
* With different portlet manager renderers, we can make the newsletters and portlets appear in different contexts - to view them and edit them; in a web version, HTML e-mail version, and text e-mail version. This can take advantage of some of the existing views.
* Right now, none of this is done with Archetypes, but a lot of Zope objects ... an example URL right now is http://plonesite/++newsletter++events1/++area++header/@@manage-newsletter-portlets

Some example portlets - some inspired by Constant Contact
* Title portlet, whose data would include (1) a logo, and (2) title text
* Greeting portlet, where a user could choose from a few different ways of greeting people (by first name, more formally, or generically)
* A "summary listing" portlet, which would pull up different summaries of items based on search criteria (a Smart Folder light; like the Events portlet or News portlet)
* Article portlet, with a main photo and then article text
* Donate Now portlet, whose data would include PayPal information
* Opt-out portlet, whose data would include a little happytalk and a link to opt out of future newsletters

In terms of how newsletters are sent and stored, ideally:
* There would be a way to send test newsletters
* They could look up e-mails in a variety of ways -- from the portal's member data, from user info stored on the newsletter or the newsletter storage utility -- and send out individualized or mass e-mails
* They could be archived up on sending by storing a static HTML version
* A cronjob on the system could be set up to send newsletters out on a regular basis

So here are some questions:
* What are folks' thoughts on this in general?
* I have seen in a couple of e-mails before that people think e-mail list management is a task best left outside of Plone and for Plone to hook into; any thoughts on this?
* Does this seem like an appropriate use of plone.portlets? (I think it's pretty exciting -- I can also see a similar technique being used to set up some flexible templates on a Plone site itself that people could fill in.) Are there techniques existing products like CompositePack are using that this is duplicating or could learn from?
* Does the idea of centralizing newsletter storage make sense?
* Is it possible to index newsletters in the same way as Archetypes content, or to wrap newsletters into Archetypes-ish objects down the line?

Some specific coding questions:
* The GenericSetup handler for portlets.xml automatically chooses to create a PortalManager instead of allowing an alternative portal manager (e.g., for one that would have a different method for retrieving the addable portlets); it would be great if there was an optional flag for this.
* Also while relying on calls to plone.portlets and plone.app.portlets code, there are issues where after editing, URL's redirect to things like http://plonesite/newsletterevents1/areaheader/... instead of http://plonesite/++newsletter++events1/++area++header/... I'm still looking into how to address this
* How does one distinguish what to put into different packages such as plone.portlets and plone.app.portlets? Right now I have three packages communitytechnology.newsletter, communitytechnology.app.newsletter, and ywasite.newsletterdefinitions (the third being a specific implementation defining different portlets and newsletters), but I don't know if the first two are really a right use of the "app" idea, or how to really distinguish what would go in one or the other -- independence from Zope3? From Plone?

Thanks for any feedback and guidance!

Peace,
George

David Bain-5

Re: Devleoping a Product to Create and E-mail Newsletters

Reply Threaded

My initial thought, not claiming to be an expert, would be to consider refactoring the PloneGazette project.

On 9/11/07, George Lee <georgeleejr@...> wrote:

Hi,

With the fall comes my chance to do a little more programming than the
spring or summer. =)  And I'm excited because now I can ask questions on
product-developers to get guidance on the overall idea and framework for a
product I'm working on -- the list wasn't around a year ago.

I doubt I'd be able to see this all the way through to the end to make a
really polished product a lot of others will use, but I think I can make a
pretty good version that if other people want, they can take to another
level. But to make it more likely the code is useful, I want to talk with
folks about it first!

I'm working on a product to create and e-mail newsletters, including
newsletters that compile summaries of different content objects ("Upcoming
Events," "New Job Postings," etc.). I created an old version for Plone 2.5
last year using Zope 3 views here and there to give some more power and
flexibility to the the newsletters, but it was fairly rough.

I'm taking some inspiration from Constant Contact - when I tried editing an
e-mail through their interface, it was pretty useable. Basically you choose
a pre-defined template, which consists of a few different parent blocks;
within each parent block, you can add different subblocks of predefined
types ("Greeting," "Article," "Coupon," etc.); then you can edit the
settings of a subblock - style, color, main iamge, add regular text, add
rich text and images and links, etc.

I worked on a rough prototype of this and then afterward thought - hey, this
reminds me of viewlets. But viewlets were too rigid because of all the
wiring required just to associate viewlet managers with viewlets, on a
site-wide basis rather than per newsletter. Then I thought, this reminds me
of portlets! And that's where I'm having a lot of fun, using plone.portlets
to set this up. I have a partial version of the product done that can
display newsletters and allow some editing using the plone.portlets edit
views, so in terms of using plone.portlets a good chunk of that work is
done.

Here's my plan, and some questions. Here's how I imagine a user adding a
newsletter.
* Initially, for simplicity and also to centralize newsletters since too
many shouldn't be going out all the time to a bunch of the same people,
newsletters are added in a central place. The current plan -- in the same
way as content rules, have a centralized storage utility at the Plone Site
root, accessible via plonesite/@@manage-newsletters
  * When a newsletter is created, a user decides what template to use for
it. The newsletter than automatically creates an appropriate number of
"newsletter area" objects, stored in a PersistentMapping. Each newsletter
area object corresponds to one of the main parent blocks of a newsletter.
The user assigns portlets to the newsletter areas - with a set created by
default. The types of portlets available to a newsletter area are pre-wired.
  * The portlets are stored with the help of a portlet manager designed
specifically to keep track of newsletter areas. It took me a while to
understand this, but a portlet manager is not "an object that stores
portlets" - but rather, "an object that can say how to store portlets
associated with different objects." So plone.dashboard1 , plone.dashboard2,
plone.dashboard3, and plone.dashboard4 are associated with site-wide portlet
managers that manage how portlets are assigned to the first, second, third,
and fourth dashboard columns for different users.
   * With different portlet manager renderers, we can make the newsletters
and portlets appear in different contexts - to view them and edit them; in a
web version, HTML e-mail version, and text e-mail version. This can take
advantage of some of the existing views.
   * Right now, none of this is done with Archetypes, but a lot of Zope
objects ... an example URL right now is
http://plonesite/++newsletter++events1/++area++header/@@manage-newsletter-portlets

Some example portlets - some inspired by Constant Contact
  * Title portlet, whose data would include (1) a logo, and (2) title text
  * Greeting portlet, where a user could choose from a few different ways of
greeting people (by first name, more formally, or generically)
  * A "summary listing" portlet, which would pull up different summaries of
items based on search criteria (a Smart Folder light; like the Events
portlet or News portlet)
  * Article portlet, with a main photo and then article text
  * Donate Now portlet, whose data would include PayPal information
  * Opt-out portlet, whose data would include a little happytalk and a link
to opt out of future newsletters

In terms of how newsletters are sent and stored, ideally:
  * There would be a way to send test newsletters
  * They could look up e-mails in a variety of ways -- from the portal's
member data, from user info stored on the newsletter or the newsletter
storage utility -- and send out individualized or mass e-mails
  * They could be archived up on sending by storing a static HTML version
  * A cronjob on the system could be set up to send newsletters out on a
regular basis

So here are some questions:
  * What are folks' thoughts on this in general?
  * I have seen in a couple of e-mails before that people think e-mail list
management is a task best left outside of Plone and for Plone to hook into;
any thoughts on this?
  * Does this seem like an appropriate use of plone.portlets? (I think it's
pretty exciting -- I can also see a similar technique being used to set up
some flexible templates on a Plone site itself that people could fill in.)
Are there techniques existing products like CompositePack are using that
this is duplicating or could learn from?
  * Does the idea of centralizing newsletter storage make sense?
  * Is it possible to index newsletters in the same way as Archetypes
content, or to wrap newsletters into Archetypes-ish objects down the line?

Some specific coding questions:
  * The GenericSetup handler for portlets.xml automatically chooses to
create a PortalManager instead of allowing an alternative portal manager
(e.g., for one that would have a different method for retrieving the addable
portlets); it would be great if there was an optional flag for this.
  * Also while relying on calls to plone.portlets and plone.app.portlets
code, there are issues where after editing, URL's redirect to things like
http://plonesite/newsletterevents1/areaheader/... instead of
http://plonesite/++newsletter++events1/++area++header/. .. I'm still looking
into how to address this
  * How does one distinguish what to put into different packages such as
plone.portlets and plone.app.portlets? Right now I have three packages
communitytechnology.newsletter , communitytechnology.app.newsletter, and
ywasite.newsletterdefinitions (the third being a specific implementation
defining different portlets and newsletters), but I don't know if the first
two are really a right use of the "app" idea, or how to really distinguish
what would go in one or the other -- independence from Zope3? From Plone?

Thanks for any feedback and guidance!

Peace,
George
--
View this message in context: http://www.nabble.com/Devleoping-a-Product-to-Create-and-E-mail-Newsletters-tf4420534s20094.html#a12608760
Sent from the Product Developers mailing list archive at Nabble.com.

_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers

petschki

Re: Devleoping a Product to Create and E-mail Newsletters

Reply Threaded

hi,
we've been thinking about this topic a while ago and decided to refactor
PloneGazette to our needs. the result of this refactoring is an
archetypes based newslettertool generated with UML and AGX using nearly
the same features as PG (MaildropHost, ...)

we've added usefull subscriber informations (graduation, salutation,
first/lastname, organisation) and enabled personalization within the
newsletter template.

the newsletter can handle all standard portal_types (wrapped by a
newsletter_typeview_wrapper template which defines the "newsletterlook"
of each used type).
we've made a ATTopic wrapper so you can filter site content with ATTopic
criterions and include the results in your newsletter.
there's also a single ContentReference type where you can "symlink"
existing items into your newsletter. since the newsletter is folderish
you have of course all the folder_contents benefits from plone 2.5 like
sorting, deleting, copy/paste ....

this product is developed for plone 2.5

i will put the source to the collective repository soon but if anybody
is interested in our KNewsletter product right now please send me a mail.

peter

David Bain schrieb:

> My initial thought, not claiming to be an expert, would be to consider
> refactoring the PloneGazette project.
>
> On 9/11/07, *George Lee* <
> georgeleejr@...
> <mailto:georgeleejr@...>> wrote:
>
>
> Hi,
>
> With the fall comes my chance to do a little more programming than the
> spring or summer. =) And I'm excited because now I can ask questions on
> product-developers to get guidance on the overall idea and framework
> for a
> product I'm working on -- the list wasn't around a year ago.
>
> I doubt I'd be able to see this all the way through to the end to make a
> really polished product a lot of others will use, but I think I can
> make a
> pretty good version that if other people want, they can take to another
> level. But to make it more likely the code is useful, I want to talk
> with
> folks about it first!
>
> I'm working on a product to create and e-mail newsletters, including
> newsletters that compile summaries of different content objects
> ("Upcoming
> Events," "New Job Postings," etc.). I created an old version for
> Plone 2.5
> last year using Zope 3 views here and there to give some more power and
> flexibility to the the newsletters, but it was fairly rough.
>
> I'm taking some inspiration from Constant Contact - when I tried
> editing an
> e-mail through their interface, it was pretty useable. Basically you
> choose
> a pre-defined template, which consists of a few different parent
> blocks;
> within each parent block, you can add different subblocks of predefined
> types ("Greeting," "Article," "Coupon," etc.); then you can edit the
> settings of a subblock - style, color, main iamge, add regular text,
> add
> rich text and images and links, etc.
>
> I worked on a rough prototype of this and then afterward thought -
> hey, this
> reminds me of viewlets. But viewlets were too rigid because of all the
> wiring required just to associate viewlet managers with viewlets, on a
> site-wide basis rather than per newsletter. Then I thought, this
> reminds me
> of portlets! And that's where I'm having a lot of fun, using
> plone.portlets
> to set this up. I have a partial version of the product done that can
> display newsletters and allow some editing using the plone.portlets edit
> views, so in terms of using plone.portlets a good chunk of that work is
> done.
>
> Here's my plan, and some questions. Here's how I imagine a user
> adding a
> newsletter.
> * Initially, for simplicity and also to centralize newsletters since too
> many shouldn't be going out all the time to a bunch of the same people,
> newsletters are added in a central place. The current plan -- in the
> same
> way as content rules, have a centralized storage utility at the
> Plone Site
> root, accessible via plonesite/@@manage-newsletters
> * When a newsletter is created, a user decides what template to
> use for
> it. The newsletter than automatically creates an appropriate number of
> "newsletter area" objects, stored in a PersistentMapping. Each
> newsletter
> area object corresponds to one of the main parent blocks of a
> newsletter.
> The user assigns portlets to the newsletter areas - with a set
> created by
> default. The types of portlets available to a newsletter area are
> pre-wired.
> * The portlets are stored with the help of a portlet manager designed
> specifically to keep track of newsletter areas. It took me a while to
> understand this, but a portlet manager is not "an object that stores
> portlets" - but rather, "an object that can say how to store portlets
> associated with different objects." So plone.dashboard1 ,
> plone.dashboard2,
> plone.dashboard3, and plone.dashboard4 are associated with site-wide
> portlet
> managers that manage how portlets are assigned to the first, second,
> third,
> and fourth dashboard columns for different users.
> * With different portlet manager renderers, we can make the
> newsletters
> and portlets appear in different contexts - to view them and edit
> them; in a
> web version, HTML e-mail version, and text e-mail version. This can
> take
> advantage of some of the existing views.
> * Right now, none of this is done with Archetypes, but a lot of Zope
> objects ... an example URL right now is
> http://plonesite/++newsletter++events1/++area++header/@@manage-newsletter-portlets
>
> Some example portlets - some inspired by Constant Contact
> * Title portlet, whose data would include (1) a logo, and (2)
> title text
> * Greeting portlet, where a user could choose from a few different
> ways of
> greeting people (by first name, more formally, or generically)
> * A "summary listing" portlet, which would pull up different
> summaries of
> items based on search criteria (a Smart Folder light; like the Events
> portlet or News portlet)
> * Article portlet, with a main photo and then article text
> * Donate Now portlet, whose data would include PayPal information
> * Opt-out portlet, whose data would include a little happytalk and
> a link
> to opt out of future newsletters
>
> In terms of how newsletters are sent and stored, ideally:
> * There would be a way to send test newsletters
> * They could look up e-mails in a variety of ways -- from the portal's
> member data, from user info stored on the newsletter or the newsletter
> storage utility -- and send out individualized or mass e-mails
> * They could be archived up on sending by storing a static HTML
> version
> * A cronjob on the system could be set up to send newsletters out on a
> regular basis
>
> So here are some questions:
> * What are folks' thoughts on this in general?
> * I have seen in a couple of e-mails before that people think
> e-mail list
> management is a task best left outside of Plone and for Plone to
> hook into;
> any thoughts on this?
> * Does this seem like an appropriate use of plone.portlets? (I
> think it's
> pretty exciting -- I can also see a similar technique being used to
> set up
> some flexible templates on a Plone site itself that people could
> fill in.)
> Are there techniques existing products like CompositePack are using
> that
> this is duplicating or could learn from?
> * Does the idea of centralizing newsletter storage make sense?
> * Is it possible to index newsletters in the same way as Archetypes
> content, or to wrap newsletters into Archetypes-ish objects down the
> line?
>
> Some specific coding questions:
> * The GenericSetup handler for portlets.xml automatically chooses to
> create a PortalManager instead of allowing an alternative portal manager
> (e.g., for one that would have a different method for retrieving the
> addable
> portlets); it would be great if there was an optional flag for this.
> * Also while relying on calls to plone.portlets and plone.app.portlets
> code, there are issues where after editing, URL's redirect to things
> like
> http://plonesite/newsletterevents1/areaheader/... instead of
> http://plonesite/++newsletter++events1/++area++header/.
> <http://plonesite/++newsletter++events1/++area++header/.>.. I'm
> still looking
> into how to address this
> * How does one distinguish what to put into different packages such as
> plone.portlets and plone.app.portlets? Right now I have three packages
> communitytechnology.newsletter , communitytechnology.app.newsletter, and
> ywasite.newsletterdefinitions (the third being a specific implementation
> defining different portlets and newsletters), but I don't know if
> the first
> two are really a right use of the "app" idea, or how to really
> distinguish
> what would go in one or the other -- independence from Zope3? From
> Plone?
>
>
> Thanks for any feedback and guidance!
>
> Peace,
> George
> --
> View this message in context:
> http://www.nabble.com/Devleoping-a-Product-to-Create-and-E-mail-Newsletters-tf4420534s20094.html#a12608760
> Sent from the Product Developers mailing list archive at Nabble.com
> <http://Nabble.com>.
>
>
> _______________________________________________
> Product-Developers mailing list
> Product-Developers@...
> <mailto:Product-Developers@...>
> http://lists.plone.org/mailman/listinfo/product-developers
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Product-Developers mailing list
> Product-Developers@...
> http://lists.plone.org/mailman/listinfo/product-developers

_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers