This article will be about OTRS, a ticket system we're using at the FSFE for handling things like swag orders, internship applications and so on. But it could actually be about any software. OTRS just happened to be in the line of fire this time.
This will be an example in how to (not) manage user expectations. You may know the principle of least astonishment, and this will be a typical example of where it fails. The problem is in how a program communicates (or fails to communicate) to the user what it will do based on some input.
The design principle of least astonishment simply means you should aim for designing your software in a way that what the user expects should happen when performing a certain operation, should also happen. If something else happens, that's bad design.
I got foiled twice today by bad design. The first situation was setting up notifications that were supposed to trigger when a ticket (such as a swag order) was updated with new information. The notification system allowed me to configure a Ticket Filter to limit the notification to only some tickets. So I could set to limit the notification only to tickets with a priority of normal.
But wait, what if I have a situation where the ticket priority is changed from low to normal? Does the Ticket Filter consider the existing ticket or the changed ticket? It's not obvious which it is, and even reading the on page instructions or the manual failed to give any clear insight. It took an experiment to determine that it's the latter.
The second situation occurred when setting up a notification which should send an email to the original user (called a customer in OTRS terminology). There's a neat setting in the notification configuration which says to send to Customer of the ticket, so naturally I choose this.
Imagine my surprise when those notifications started coming to me, instead of the customer. Turns out (and I actually needed to read the code to figure this out) that when it says Customer of the ticket, it doesn't actually mean the customer.
Wait, this is confusing. Yes, yes it is. Each ticket has a field called "Customer ID" which in our case is almost always the e-mail address of the original user, the person ordering swag or applying for an internship. So you might think that the Customer of the ticket is the e-mail address listed in the ticket.
Not so. The Customer of the ticket is actually the sender OR the recipient of the last e-mail in the ticket. Consider a ticket containing these three e-mails:
From: Jane User <email@example.com> To: firstname.lastname@example.org Subject: Application for internship I'm applying, see my attachment for details!
From: Office <email@example.com> To: Jane User <firstname.lastname@example.org> Subject: Thank you for your application Thank you for your application, we'll review soon.
From: Office <email@example.com> To: Joe Coworker <firstname.lastname@example.org>, My Assistant <email@example.com> Subject: Re: Application for internship Hey, I think this application looks really good, maybe we should accept Jane?
You might think that the Customer of the ticket is Jane, and the fact that the first notification (an automatic reply) goes to Jane is a clear indication of this. However, in some cases, the third email will cause the behavior to change. The system will look through the e-mails in the ticket, determine that the last e-mail is #3, and since this email is sent from the system address, the recipients of that email (Joe and My) must be the Customer.
So rather than sending a notification to Jane, any future notifications going to the Customer will be sent to Joe and My. Until someone sends an email to Jane, after which any future notifications will again go to Jane.
Triggering this behavior required a few other things to go wrong too, but nothing which I would consider to be strange or out of the ordinary. Settings which seems pretty logical to make, but which in the end, caused a completely different result than what I was lead to believe it would.
Follow the principle of least astonishment and your users will be happy.