/usr/portage

Best practice: Convenient notifications 3

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.

Let me adjust

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.
This implicitly

Let me decide

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.

Authenticate me

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.

Don’t try to track my behaviour

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).

My mailclient is not your billboard

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.

Show me your guts

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.

Filed on 08-04-2008, 21:09 under , , , , , , & three comments & no trackbacks

Magical PHP 0

Tobias Schlitt on »Doing Magic with PHP«. A great overview but I do not agree with the property part of it.
(I found this __set(), __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.)

Filed on 10-06-2007, 13:01 under , , , , & no comments & no trackbacks

ezComponents 2006.2 0

As Derick Rethans states, ezComponents 2006.2 were released. I really like the new graph-component, you can draw beautiful graphs now easily. And I mean graphs that does not look like typical graphs.

Filed on 21-12-2006, 01:01 under , , & no comments & no trackbacks

ezComponents 1.1 released 0

On June 12th ezPublish, the new employer of Sebastian Bergmann, released ezComponents 1.1. I’m lazy, read the changes by yourself and begin to use one the most helpful PHP-patterns.

Filed on 18-06-2006, 05:05 under , , , & no comments & no trackbacks

eZ components - doing things fast and smart 0

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

Now the PHP-code with ezConfigurationIniReader:
$reader = new ezcConfigurationIniReader();
$reader->init('/path/to/your/config/dir, 'config' );
$config = $reader->load();
echo $config->getSetting( "context", "foobar" );

Isn’t that simple?

Filed on 03-05-2006, 11:11 under , , , , , , , & no comments & no trackbacks