Me on the coffee line

At the office, they swapped out the automated coffee machines. These are the ones in which you select "Espresso", then you select regular or decaf, then you choose the size of the cup, then you press the button, and in a few seconds, the espresso comes streaming out.

I noticed that the new UI operates differently from the old one. The current interface retains the previous settings while on the old machine, the settings return to the default ("regular" and "medium") after each use.

The interface design reflects a choice by the developer, which embeds the developer's assumption about user behavior.

The current developer assumes a kind of serial correlation, that the next user is likely to require the same settings as the previous user. We can frame this problem as predicting the setting requested by the next user. We want to maximize the total number of correct predictions in a queue of users. The retain-previous strategy sounds reasonable.

The developer of the other machine adopts a different strategy: show the same default settings to everyone. Presumably, the default settings are the most commonly requested settings. Both strategies are easy to understand, and this latter one, even simpler.

The common-default strategy discards the serial nature of the problem, as it treats every user identically regardless of their position in the queue. If, say, the most common settings are desired by 40% of users, then this strategy will predict correctly 40% of the time. Its effectiveness is a function of how common the most common is.

The retain-previous strategy is more complicated to analyze. In these coffee machines, there are three settings of caffeination (regular, half decaf, decaf); and three settings of size; thus, there are eight possible types of users. If we have historical data, we can take adjacent pairs of users and count what proportion are same-same pairs.

Without data, we may call upon some standard probability model for simulating a queue of users. This starts getting a little complicated. Any standard model assumes independence between samples, which should preclude serial dependence! That said, a standard model is obviously capable of generating adjacent pairs that have the same settings, i.e. sequential users who select the same settings.

Flipping a coin continuously will result in "runs" even though the coin is perfectly fair. The probability that the next flip is a head given the previous flip is a head is $ \frac{1}{2} $; ditto tail given tail. So the probability of seeing a run of length 2 is $ \frac{1}{2} \times \frac{1}{2} + \frac{1}{2} \times \frac{1}{2} = \frac{1}{2} $. But since the coin is fair and flips are independent, the serial correlation is zero!

Let's get back on track. I don't like the serial correlation assumption anyway. Does knowing about the prior user really provide information about the next user's requirements? It might matter, for example, if the coffee machine is in a family home; but for a shared office, I don't think so.

If the developer of the new coffee machine assumes serial independence, then the probability of the next user's settings is the same whether or not we condition on the previous user's settings. So, the prediction is driven by the overall preferences amongst the eight possible settings. We are back to the common-default strategy.

This is sufficient to argue that the retain-previous strategy is suboptimal relative to the common-default strategy. The only way it may be better is if user preferences are correlated serially in a material way.

If this is not convincing, see my future post for a more quantitative argument.

The retain-previous interface is annoying me in another way. It adds variety when none is needed. There is a certain "comfort" that comes with seeing the same settings each time, even if they aren't my preferred settings. With retain-previous, I have to train myself to ignore the UI and just put in my requirements. If I accidentally press Start without looking, I'm not sure what I'm getting.