Email. But not just email. Regular, automated email to a self segmenting list
So, you have a website that publishes details about where and when your popup outlet is going to be each week. Now all you need is a way of pushing this info to your customers by email.
Mail Merge - do people still say that?
I remember when people used 'mail merge' with databases to print personalised letters. You'd write your letter letting some lucky punter know they'd won an amazing opportunity to invest in a share of a partially build flat in the Costa del Sol, and add a tag like '< first_name >' which would be replaced by a column in a spreadsheet or database.
Emails can be personalised in a similar way. You can loop through your online users database and send the same email to each e-mail address you have, and add their name to the salutation.
So far, so what? Yes there are plenty of technical issues that can make getting this far a pain, particularly layout rendering limitations, but once you’ce got your core templates in order, and your function that fires out your messages, sending personalised message to a list is no big shakes. The bit that has piqued my interest is building a system to allow website users to create a repeating email that generates all its content based on user definable rules.
Time for an example
My client sets up shop in a couple of different places each week. I want to set something up so that his customer base can sign up for email notifications, with or without matching chosen locations. It would be useful if the timing of the different elements could be fluid, so that if emails are scheduled to go out each Wednesday, and details of a Friday event are posted on a Thursday, they can be sent too.
Tagging or TQL?
I have two options in mind for including content. The simpler one is to use tags - e.g. ~* events-calendar *~. The opening and closing strings '~*' and '*~' can be anything. The MailChimp system uses '*|' and '|*'. As long as the changes of anyone using the tags in real content, then it doesn't really matter.
The other option is a vague SQL layer that that I could create a self aggrandising title for, "Typomania Query Language". Each content type could then have it's own interpreter to take the TQL and create SQL. E.g. '~*all future events*~ would become SELECT * FROM events WHERE date>=CURRDATE() LIMIT 10 (10 being an example sane default maximum - who wants to receive a massive scrolling email with hundreds of events?).
All of a sudden it looks like a combination of both might be needed – a set of instructions that says what to include with options.
2 hours later... Well that took a bit less time than I was expecting.
I've modified my main content engine to parse my new TQL tags, which are basically JSON strings that can easily be validated and converted to arrays. The tags start with *{ and end with }*
E.g. *{"include":"events"}*
By simply stripping the *s we have something we have JSON and the rest is easy. Well easy ish. A bit easy? Ok - there's still a lot to do in order for stuff that might appear in a webpage to also appear in an email – full paths to images and table-based versions of layouts that would otherwise rely on DIVs. It still works though - on an MVP level.
