There was a time when power outages would create housefuls of blinking twelves– VCRs, microwaves and alarm clocks would all complain about no longer knowing the time. In my parents’ house, this blinking could go on for several days until my siblings or I got annoyed enough to fix them. My dad tended to ignore the clocks despite (or because of) his engineering background because he was usually wearing a watch. My mom, on the other hand, couldn’t figure out all the different interfaces.
I first came across the term “blinking twelve problem” in Neal Stephenson’s remarkable essay “In the Beginning… Was the Command Line.”1 Stephenson claimed that the blinking twelve problem as the result of a sudden change in available technologies:
…because the VCR was invented when it was–during a sort of awkward transitional period between the era of mechanical interfaces and GUIs–it just had a bunch of pushbuttons on the front, and in order to set the time you had to push the buttons in just the right way. This must have seemed reasonable enough to the engineers responsible for it, but to many users it was simply impossible. Thus the famous blinking 12:00 that appears on so many VCRs. Computer people call this “the blinking twelve problem”. When they talk about it, though, they usually aren’t talking about VCRs….
Stephenson’s essay focused on the gaps in GUI’s and in operating systems. Often the term applies to an interface problem2, in other words, the gap between a technological solution (e.g. a device can tell time if set properly) and the user’s ability to make use of it. However, the “blinking twelve” problem can be used to describe technological gaps in general; a blinking twelve problem is any instance of a gap between an implemented solution and the knowledge or ability to use that solution. Blinking twelve solutions, therefore, often involve either building the technical solution to be more usable or building the users’ knowledge or ability to use the solution.