Matthew Garrett (mjg59) wrote,

Showers and UI design

Travelling rather a lot this year has left me spending plenty of time staring at showers[1]. There seem to be three broad categories of shower UI design. The first is the one that exposes the raw functionality of the underlying implementation:

(image by bean, reused under cc-by-nc 2.0)
Showers work by mixing hot and cold water and feeding them through a shower head. This implementation allows direct control of the hot and cold feeds. The user can obtain any combination of pressure and temperature that the supply contraints make possible, but at the cost of it being impossible to adjust single variables. Changing the pressure without changing the temperature is difficult. One of the most common alternatives I've seen this year is the following:

(image by anearthling, reused under cc-by-nc-sa 2.0)
Here, power and temperature are unified into a single control. The major problem with this design is that it's generally impossible to have any pressure setting other than full on. The benefit is that the temperature can be altered without any significant concern over the pressure. Simplification through limiting functionality. Finally, we have setups like:

(image by stevec77, reused under cc-by-nc 2.0)
Though not clearly shown, this interface separates temperature and pressure into independent functions. The number of UI elements is identical to the original "hot/cold" case, but the user is now able to set temperature and pressure independently without having to worry about the interaction between the two. This is obviously more effort to implement but improves usability, decreases complexity and doesn't clutter the interface.

So, if this is a solved problem, why do I keep coming across implementations that suck?

YES THIS IS A METAPHOR FOR SOFTWARE DESIGN

[1] Often in a certain degree of confusion, but that's not really the point here
Tags: advogato, fedora
  • 57 comments
  • 57 comments

Comments for this post were locked by the author