Vagrearg Logo  
Statistics, the old fashioned way, upgraded
Lies, damn lies and statistics.

You have a high school science fair and want to know how your project was perceived by the visitors. Modern online behaviour will direct you to "taking the online survey". That requires an extra step for the visitors, usually by taking hold of their mobile device and fiddling with a small screen.

One problem you will encounter is designing good computer interaction and a proper look and feel on the tiny screen. It is a lot of work. A second problem is the distraction of using the mobile device with respect to the project being surveyed. The visitor will concentrate on the mobile device and that will diminish focus on the project for a moment. A third problem is anonymity and proliferation of data. Do we really need to be online and spread all that information one's device sends?

This is where I was contacted by a colleague, who wanted to do a survey with physical interaction. There are some shops here in town, featuring a three-smiley button box, asking the customer about their shopping experience. Such question is often well-answered by a three-choice device. Would it be possible to make a box with five choices? (And also asked "can I have six boxes two weeks from now"...)
Of course is it possible to make a box with physical interaction and five choices. The real question is whether it can be designed, implemented and produced in short time.

The problem one tries to solve here did intrigue me. How to do a survey with physical interaction and reduce the interaction to an absolute minimum? How do you use the visual cues to direct people to push the button of their choice? Especially interesting was the prospect to discard any use of internet and mobile devices. The box simply asks the question "How much do you like..." within the context of the box's placement and the visual cues on the box[1].

So here you have it, SmileyBox:


The box consists of five arcade buttons with integrated LED. The box is lasercut acrylic (3 mm top and bottom, 5 mm sides) and assembled with screw-nut joints. An simple laser printed paper inlay under the top acrylic plate serves as the question's visual indicator.

All buttons will blink/glow slowly when waiting for a button press. A press of any button will blink/glow that button for 5 seconds at a faster pace indicating the press. The waiting period also prevents the most wild multi-press abuse that otherwise can occur.


A statistics interface is implemented on a 16x2 LCD screen. Access to the menu is granted by a recessed tactile button next to the screen. You need a pencil to push it.


The menu advancement is controlled by two of the arcade buttons (next/prev menu entry) and menu-entry activation is done by the recessed tactile button. It will give you the following options:
  1. - Show Stats
  2. - Reset Stats
  3. - Set Passcode
  4. - Remove Code
  5. - Exit Menu
The passcode (if set) will require you to enter a sequence on the arcade buttons while holding the recessed tactile button down (between 1...9 presses). This should make user-manipulations a bit harder.

Power comes from a (very) cheap 500 mA USB charger. They are so cheap that one actually blew up, generating a bang and lots of magic smoke, when I put it in the 230 V mains. Ah well, what can/do you expect from low-cost crappy power supplies.

All statistics will survive power-cycling. The data is stored in the EEPROM of the ATMega chip. The writes will cycle the entire EEPROM, effectively doing some primitive wear-leveling. The box should be usable for at least 20000 statistics-reset cycles (or 27 years when doing two resets per day every single day of the year).

The code also contains a serial interface. All data can be gathered from the serial port and the passcode can be set/reset there too. If I'd had more time, then I'd implemented a USB interface to connect to your PC (with an Arduino Nano or something like that), dropping the LCD display and have power-entry via the USB connector through the case. This may be a new project...


Six boxes were required... It turned out that most of the components were available from the backroom (my big stock of components and other unusual stuff).


The electronics are extremely simple. There is an Arduino Pro Mini interfacing with all the buttons and the LCD display. The rest is code. The PCB was designed to ensure mechanical stability of the setup. All wiring is done with connectors and all parts can be fixed/repaired.

The cost per box is about $50. This could be done somewhat cheaper when carefully selecting sources and components. However, this project needed to be done fast. The arcade buttons will already set you back about $13 and could be done cheaper at the cost of quality and tactile experience. The acrylic sheet is not cheap either (~$8 per box); you need to look carefully to get it at a good price at sufficient quality. Wiring and connectors come at $7 (lots of manual crimp-work). The PCB with Arduino, LCD and PSU is about $13. The remaining cost is in power wiring (a 3 m USB cable) and mechanical stuff.


It is Friday. The bar is open and the beer is flowing. What do you like more, beer from a bottle or a draught from the keg?

Just one more question to ask (this is box #7).


Design files (licenses CC-BY-SA-3.0 and GPLv3):
Note [1]
Of course, questionnaires and statistics is a complex field. Making this box introduces several possible biases in the results that you may get. For instance, how do users react to (peer) pressure when they are requested to evaluate your project and you or others are looking (peer and interviewer bias)? How can you assure that the user actually pressed the right/intended button (placement and context bias)? How can you assure that the user is honest in his/her evaluation? Is the user only pressing once or trying to influence the result by repeated evaluations? Are you asking the right question (question bias)? How do you represent the visual cues (interpretation bias)?
There are many factors that come into play. That is where the real science is.

Posted: 2018-09-29
Updated: 2018-09-29

Overengineering @ request