Community websites often notify users about events taking place on a website. These notification, may it classically be an email or may it try a cooler approach like instant messaging, can be good or bad. Most of the time they are really inconvenient. The following list provides a few ideas how to do it better.
First of all, let me decide which notifications I get. This will make me feel better and making me – the user – feel better is always a good thing. It is sad that not everyone is doing it. And yes, per default every notification – maybe except the notification about new messages – is disabled.
I hate HTML emails. I really hate them. They are seldom rendered correctly and hide the information I want to know in an unnecessary layout. Emails are just text and that’s fine. But I know people who really prefers this colorful stuff. Some people just weight a well formatted mail higher. So give them HTML. And text for me. The email standard provides us a way to do this: multipart. My mail client will render text, for others it will render HTML. We are both happy.
There are also libraries encapsulating the multipart standard. Zend_Mail from the Zend Framework is one of those, ezMail from ezComponents is another option.
By the way: there is no need to keep the mail template twice, one for text and one for Email. Use reStructuredText or Markdown to do both in one go.
When I click a link in the notification email I do not want to get a 403. I want to be logged in seamlessly. I know this is a trade-off between convenience and security but generating a secure token for each sent notification is not that hard. When I open my messagebox, let me just click the link host.com/messages/abcdefg123456 and my mailbox appears and I’m logged in. Technically that’s not hard to do, one authentication token per mail with an TTL of a week or so. This applies for Instant Messaging too.
It’s alright if you send me a mail if I’m not logged in for two weeks (unless I don’t disable it) or if you offer me cheaper deals for your payed account (unless I don’t disable it …). But please, do not try to track if I read the mail or what link I have clicked or whatever you might want to know. My inbox is private and when the mail is in my inbox, you are no longer allowed to do anything with it.
The data you get from this kind of tracking will be flawed and wrong anyway – see the chapter about formats and my preference for text above. Also a number of widely spreaded webmail clients like Google mail will not render your tracking pixels anyway, so stop doing that.
And no, it is not cool the use the XHTML extension of Jabber to load tracking pixels (alright, me, being a geek would find it sort of cool).
If you provide a free service for me and do advertising, even context sensitive advertising, it might be a fair deal for me. But this does not apply to messages you send to me. Again: my mailbox is my mailbox, so it is an act of grace to allow you to send me emails. A lot of people more important than you are not allowed to do that, so feel honored. It is just an act of courtesy to not include advertising material from you or your partners in a notification.
I would really love to see the mails you have sent me and what the status is. If your system tells me the notification mail for XYZ has been delayed, because the receiving SMTP-server does greylisting I want to know that I have to wait a few minutes. You will have that information anyway so why shouldn’t you make the process transparent to me? And no, you are not going to tell me the exact SMTP status, assume I’m not the nerd I am, assume I am a customer who wants to know what’s going on. It’s not that hard to translate an SMTP status code into a human readable (and understandable) message which can be displayed to the user.
Tobias Schlitt on »Doing Magic with PHP«. A great overview but I do not agree with the property part of it.
(I found this
__get()-magic pretty unintuitive and unreadable. If I want to learn the API of a Zend Framework class, I just read the source, if I need to learn the API of an ezComponent, I’m forced to read the documentation, which is in fact pretty good. I prefer setters and getters over virtual properties.)
If you use PHP for some years, you will often fight the same problems, which leads to a lot of unuseful work when implementing basic issues like a properly designed class to send mails in a sane way, parsing an INI-file, basic generating of PHP-code, logging to a file or database or an implementation for a persistant object. This components are often needed and you have to write them by yourself, if you want to work around the tranditional and outdated PEAR-packages. So, maybe some day, you have all the patterns you need and can begin to write code but how long does it take? Two years? For years? Not that sensible. So it raises productivity if you can use a set of components which are small, independent and designed for the current state of the language, means: PHP 5.1.x. eZ components by eZ systems fit this specification. You can solve the problems above and much more – analysing and modifying images, debugging, working with user input and, as surplus, you can work with PHP for shell-scripts with ConsoleTools.
As theory is supposed to be useless without practice, a small example for reading an INI-file. Let’s assume the following INI-file:
[context] foobar = Bla bla = blubb whatever = bar
$reader = new ezcConfigurationIniReader(); $reader->init('/path/to/your/config/dir, 'config' ); $config = $reader->load(); echo $config->getSetting( "context", "foobar" );