Vote for green…I mean red (how can I tell I am colour blind)

February 6, 2009inf2241_classfi22410

The project for last week, this week and next week is to build a biased voting machine. After a brainstorming we had the idea to create a voting machine that is biased against color blind people. This is a very specific bias, because it only discriminates a small male portion of the population. On of the trigger for this idea was the fact that I noticed during the lab sessions that Jamon is color blind because he confused the red and green wires used to build circuits.

The design:
We want to have a device with to LEDs and two associated push buttons. On the screen the program will ask the voter to push a button either next to the red or green light in order to vote for someone. Since we will make the color in a way that the difference can not be told by a colour blind person, our voting machine has a direct bias. Jamon will be our calibration “tool” to know that the discrimination works.

Last week we started to work on the over all design and idea. This week the goal was to build a circuit with the two LEDs. The LEDs contain all three main colours and we want to be able to modulate the colour spectrum using the Arduino board. We want to do this with puls-with-modulation (PWM).

Our first goal was to build a circuit that allows use to turn each colour on the board on and off using a digital signal from the Arduino board. The LED uses a common 5 V pin and has a ground pin for each colour. We built a circuit that has a transistor after each colour pin. So we are able to open or close a circuit (and so turn off or on a colour) by using digital signals from the Arduino. This allows us to control each colour in each LED individually. To mix colours we will use PWM to turn colours in the LEDs on and of very fast in order to create a green and red colour spectrum that can not be distinguished by Jamon.

What happened in the lab:

It was difficult to set up the circuit in a correct way since none of the team has a strong background in electronics. However, with the help of the Internet, Matt and especially Jorge we were able to create a circuit that allows us to turn colours on and off using the Arduino board. This enables us to later on mix the colours.
One of the main obstacles was the fact that we burned out the red component in two LEDs while fiddling around with the circuit. This trial and error was necessary because the different colours in the LED seem to need different resistance in order to work properly. The red light gets very dark at around 100 Ohm while the other colours (green and blue) are very bright at 100 Ohm. If we went over 100 Ohm the red light went darker, but the others did not glow any more.
We figured out that about 33 Ohm should be ideal to protect the LEDs from burning, but still allow all components to shine bright enough.

Next week:
The goal for next week is to make the two LEDs shine in red and green, but are not distinguishable by Jamon. Also we have to create a primitive GUI that guides the voter and asks him to press the button either next to the green or red light.

Voters beware!!

February 4, 2009inf2241_classfi22410

Today in our lab, we are going to build a voting machine with a built in bias. In this case, we are defining bias as presupposed expectations as to what the user can understand or do with the machine. If we were Robert morris, we could place the voting machine in a park which was only accessible to people from Thorn HIll, but it is doubtful that we will have time for a field trip today.

Our plan for the voting machine is an extension of our previous project, the traffic light prototype. We will be building a machine with a colour bias, discriminating against those users who are colour blind or are not properly socailized to the meanings of different colours.

In our literature search, we found the article Voter’s Perceptions of Voting Technology: Paper Ballots Versus Voting Machine With and Without Paper Audit Trail (Menno de Jong, Joris van Hoof, Jordy Gosselt. Social Science Computer Review. Thousand Oaks: Winter 2008. Vol. 26, Issue 4; p. 399-411. Available online through UTL). This article compares voter response to paper ballots, electronic voting machines and electronic voting machines with a paper printout shown to the voter to verify their selection. The research experiment was conducted in the Netherlands on the day of provincial elections. Participants were found at the polls, after they had voted in the provincial elections. They were asked to vote using the three methods and were asked to vote for the charity of their choice, the highest polling charity recieving 1000 euro from the research project. This was done to emulate voters caring about the election’s results. After voting in each method, participants filled out a questionnaire that asked about their experiences in four aspects: their sense of anonymity, their perception of usability, their confidence in their voting, and their confidence that their vote would be correctly processed. Contrary to all the concern about voting machines in the tech and design fields, participants ranked the usability and their confidence in correct vote processing for electronic machines as very high. The paper printout to verify the electronic vote had no significant impact on the four factors. The youngest particiapnts and those with higher levels of education were most sceptical of the electronic machines in all four factors. At the end, the authours reflect that the positive response to all voting methods is probably reflective of the confidence in the democratic process in the Netherlands. (At least one group member has been to the Netherlands and can report- they’re got it made.) The authours point out a potential question for future study would be to research if there is less confidence in voting methods in countries where there is less confidence in the democratic process… like, maybe in Canada??? (see: coalition government).

This article seemed somewhat relevant to our task since it focuses on the perceptions of the user in voting machines. A short editorial, Vote for Usability (Richard Babyak, Appliance Design [Troy], vol.56, no.11, pp.4, 2008, available online form UTL), brings attention to the human factor in voting machine design and points out how inconsiderate design can discriminate against large portions of the population.

Voting Machine I: Reflecting on the Pregnant, Dimpled and Hanging (Chads, that is)

February 4, 2009inf2241_classfi22410

There was a lot of discussion within Bruno’s BellyButton as to exactly how to bias the design of a voting machine.  We tossed around three different manners of embedding bias: the machine could be biased against a specific option, and thus towards the other (for simplicity’s sake, we are assuming there are only two options); the machine could also be biased against a specific segment or segments of the population; the third option involves both, in which the bias embedded in the design disadvantages a segment of the population that tends towards a certain political persuasion. After a bit of ideological ping pong, we decided to explore the second option (biasing the design against a segment of the population), because it seemed the most conducive to a realistic yet evocative case.

As a point of departure, we look to the controversy surrounding the ballots in Palm Beach County, Florida for the 2000 American federal election, as recounted in LaFratta and Lake (2001). The design of this ballot proved to be confusing for voters, particularly those with motor or vision difficulties, or with arthritis. Candidates were listed on facing pages with a single column in the centre for voters to indicate their selection by punching holes on black dots indicating the desired candidate:

Confusion arose for three reasons. First, candidates were listed in two columns but the vote was to be indicated in one column, causing a displacement in the order of the indicators (LaFratta & Lake, 2001). Thus, the Democratic Party candidate was in the second place in the left column, but the second indicator corresponded to the Reform Party candidate and the third corresponded to the Democrat. Second, any confusion as to which black dot corresponded to which candidate was magnified by the very short arrows that were intended to indicate which dot corresponded to which candidate, but were in fact too short to properly show the link. These two features posed problematic for people with vision problems. Finally, the punch card itself proved very difficult for those with motor skill impairments or arthritis, who were unable to punch the holes completely, adding the terms “pregnant chad”, “dimpled chad”, and “hanging chad” to modern vocabulary. These incomplete holes were subsequently rejected by ballot reading machines. Charges of voter disenfranchisement of the elderly were levelled and this, as well as other problems plaguing Florida’s election, caused a month of controversy ending finally in the election of George W. Bush (which in itself is still controversial eight years later).

We intend our voting machine to be similarly flawed (but on a more technological basis), to confound and hinder democratically-inclined senior citizens. Perhaps, using our machine, voters will be directed to indicate their selection using a small 3-setting switch. The middle setting will be neutral or “off”, while the settings on either side will indicate the voters’ decision.  The switch itself is quite tiny (approximately 1/5 the size of a light switch) and difficult to manipulate for anyone with motor difficulties.  This could be  mounted on a hand-held interface, it too small in size but also fairly heavy, making it difficult to hold steady.  In addition, ‘smallness’ and ‘clumsiness’ could also be carried over to the visual interface, disadvantaging those with vision difficulties. Therefore, the design will invite voters to make a selection but fail to adequately accommodate those with motor skill impairments, vision impairments, and/or arthritis – in short, grandma and grandpa.

To make a working prototype for such a device, we will on build the ‘Arduino Meets Processing’ ( ) tutorial explored this past week.  While previous forays into Arduino relied on the use of relatively simple indicators (LEDs, serial monitor) as feedback, the above code samples opened up the possibility of also using the computer screen (as well as the wonderfully creative world of Processing).  This was seen in the case of using a pushbutton to control an animated ‘bar graphic,’ employing the ap_ReadDigital sketch in Arduino in conjunction with the pa_PushButton sketch in Processing.  It worked!


(…we decided to go totally rogue and simply press two wire ends together in lieu of a pushbutton…)

It seems feasible at this point to modify these code samples (as well as the pa_Switch sample on the same website) to mock up the code to link a hand-held interface to a computer display, creating a voting machine which matches our described intent.  At least, we hope.

As mentioned above, our understanding of this sort of flawed design was informed by LaFratta and Lake (2001). The paper outlines all the difficulties of the Florida election, but we elected to concentrate on the design aspects in the Palm Beach County controversy, as outlined in greater detail above, due to its relevance to the assignment. In the end, the authors conclude that the difficulties were due to issues in accessibility, election worker training, and ballot design (p. 160) and propose various standardization solutions. We also looked at Siegel v. Lepore (2000), the legal proceedings of one of the many Florida court cases in the American 2000 election, but rejected it due to its very specific legal bent. We also considered Newport and Jones (2008), an examination of voter demographics for the then-upcoming 2008 American federal election showing that elderly voters tended to support right-wing candidates more than younger voters. This would have shown the implications of disadvantaging older voters because the Lafratta and James (2001) discussed design.



LaFratta, B. K., & Lake, J. (2001). Inside the voting booth: ensuring the intent of the elderly voter. The Elder Law Journal, 9(1), 142-164.

Newport, F., & Jones, J. M. (2008). Young Voters Favor Obama, but How Many Will Vote? Gallup. Retrieved February 1, 2009, from

Siegel v. Lepore (12/6/2000, No. 00-15981). (2000). Emory Law. Retrieved February 1, 2009, from

Best Ash Tray Ever

February 2, 2009inf2241_classfi22410

Our group, NUTS (Non/Not-Useful-Temporary-Stuff), planned to build an ash tray that blows smoke at the user. We thought this would be a perfect invention given the assignment, which was to create a piece of technology that is biased and allows for or encourages moral consideration. The bias in this device being, of course, against smokers.

The design was simple. We attached a sensor that could detect changes to heat. So as a hand, cigarette, bird or whatever came close to the ash tray an electric motor would be activated to blow the smoke towards the user – literally blowing smoke in their face and making them aware of the dirty, nasty terrible (use of harsh words justified due to biased nature of assignment) habit they are engaging in.

Our initial attempt at detecting movement or light, using an unknown component. It did not work.

Armin Soldering infrared photo transistor

Transistor soldered and secured in place

The fan spins when there is a change in infrared (from what we can tell anyways) light detected by the transistor. The component is slow to respond to changes and creates an unpredictable on/off behaviour that might further compound attempts at using it for cigarette ashes.


* AnalogInput
* by DojoDave <>
* Turns on and off a light emitting diode(LED) connected to digital
* pin 13. The amount of time the LED will be on and off depends on
* the value obtained by analogRead(). In the easiest case we connect
* a potentiometer to analog pin 2.

// hacked and modified by NUTS to toggle a fan based on
// values read from an infrared transistor

int potPin = 5;    // select the input pin for the potentiometer
int ledPin = 9;   // select the pin for the LED
int val = 0;       // variable to store the value coming from the sensor
void setup() {
pinMode(ledPin, OUTPUT);  // declare the ledPin as an OUTPUT
Serial.begin(9600);          // set the baud rate to 300
Serial.println(“Starting ashtray infrared sensor.”);

void loop() {

delay(500); // too unpredictable without a delay e.g. rapid on/off behaviour

val = analogRead(potPin);    // read the value from the sensor
Serial.println(val);      // Output the value from the potentiometer (debugging)
// poti gives values between 0 and about 1024
Serial.println(val);      // Output the new value from the potentiometer (debugging)

if (analogRead(5) < 400) {
// if someone darkens the area around the transistor, toggle the fan on
digitalWrite(ledPin, HIGH) ;


if (analogRead(5) > 450) {
// if the transistor reads ambient infrared light (tested indoors on a cloudy day) toggle fan off
digitalWrite(ledPin, LOW);

/* legacy code from potentiometer sketch
void write_led() {

//digitalWrite(ledPin, HIGH);  // turn the ledPin on
//delay(val);                  // stop the program for some time
//digitalWrite(ledPin, LOW);   // turn the ledPin off
//delay(val);                  // stop the program for some time
analogWrite(ledPin, val);

Critical Failure

January 31, 2009inf2241_classCourses, fi22411

On January 21st 2009, our team was sent into the lab with a mission: to construct a device that was highly moral. We had previously talked about this concept of morality in class and discussed readings from previous weeks. We were comfortable with programming and designing with Arduino, we had a range of tools to use, and a wide variety of background knowledge and experience to draw from. We thought we were destined for greatness.

We failed. At the end of the lab, the class showed off their designs, including a functioning stoplight and a posture corrector. We had nothing to show but some weird half-ideas and a bunch of semi-completed circuits. So what happened?

Well, our brainstorming session was all over the place. No one idea emerged from the pack, so we decided to start building and see where we ended up (mistake #1?). We spent some time looking around the lab for cool little components we might want to include… we found a knock sensor that looked promising and decided to build around that (mistake #2?). Finally, we couldn’t agree on the defenition of morality (mistake #3?). Was a device with no output moral? How about a device that had no input or output? What about a re-purposed device?

Because we didn’t have a clear goal, we weren’t able to subdivide the tasks in the group (mistake #4). We also still weren’t sure what we were building, but started to lean towards a ‘wife-beater detector.’ Yeah. Ummm… yeah. The idea was that the knock sensor would be able to distinguish between love taps and wife beating, and would display a message on the screen if the threshold of wife beating was passed. Probably not very practical (knock sensors all over the body?), but it met all sorts of criteria for ‘highly moral device’ and we were running out of time.

We didn’t get there. We got the code and circuit working, but it wasn’t really what we had intended (and looked suspiciously like what we had done the previous week in the lab). Here it is in all it’s glory:

In truth, some of the things listed above may not be mistakes. The push-pull between materials and potential ideas (from mistake 2) is a characteristic of this kind of work; it could be viewed as a necessity, or even an positive. And clearly discussing the concept of morality in devices (mistake 4) was part of the point of the lab. So, while we may not have produced a finished physical product, we did analyse/discuss/think/argue/learn. Couldn’t the whole experience could be viewed as design-oriented research?

Yeah, I think we’ll go with that.


A Magical Stop Light

The magic is that it works! Or to be more specific, it performs the functions we asked it to do through the code.  This week, our group was instructed to build a moral technology. We decided to emulate an existing technology by building a prototype for a traffic light. We briefly discussed the concept and went to work. This week’s lab was particularly fun in that we were encouraged to rummage through the Critical Making lab and use whatever materials we could get our hands on.

First, we wrote the code and created the circuit. We built the circuit, lining up the LED lights along the breadboard and attaching all the grounds to one pin on the arduino. The code (included below) is quite simple, turning the appropriate lights on and off for a set period of time. Once we knew that the code and the circuit were performing properly, we were ready to move the circuit off the breadboard and into a physical object.

The delegation of tasks in the making process occurred naturally within the group. Nancy took on the task of soldering wire and header pins together and insulating them with purple stuff(?). Mike wrote most of the code. Marta collected materials to fashion the object/ shell for the circuitry. Though each person took on roles associated with their strengths, there were overlaps. Nancy and Marta worked together to solder the wires to the LEDS, Mike experimented with various elements to use as a supporting post for the object, Mike and Marta collaborated on building the circuit, Marta helped to complete the code.

A hollow threaded pipe with a base was the main support for the light. A pink piece of foam was cut into a vertical rectangle, the bottom of the foam forming a narrow post shape. This narrower section was inserted into the hollow pipe to produce the main body of the object. We applied a piece of yellow duct tape over the main rectangle at the top of the object for aesthetic purposes.  We soldered the LEDs to long wire soldered to header pins. We then punched holes in our object and inserted the lights in the appropriate spaces (it took a moment to remember the order of the colours, revealing to us the ubiquitous nature of this technology (we know what it means without thinking about how it operates or is constructed)). In this case, attaching the circuit to the physical object was as easy as inserting LEDs into some holes and tying the loose wires together at the back. Potential issues that may arise in future projects may be integrating the wiring and circuitry into the physical object in a more seamless, less obvious way.

What fun!


// Assignment 1
// Moral Actor:
// This program is used to control a stop light.  It consists
// of three lights (green, yellow, red) that are controlled by time.
// Created By: Marta Chudolinska, Nancy Davies, Michael Trumbull

// Define constants
#define red_light 13
#define yellow_light 12
#define green_light 11

void setup () {

void loop () {

// Go, Caution, Stop Sequence
digitalWrite(green_light,HIGH);  //Show Green
delay  (10000);                  //Pause Green 10 seconds
digitalWrite(green_light,LOW);  //Turn off Green

delay  (3000);

delay  (10000);

//Blink Sequence
delay  (500);
delay  (500);
delay  (500);
delay  (500);
delay  (500);
delay  (500);
delay  (500);
delay  (500);
delay  (500);
delay  (500);

“Stand Up Straight” by Bruno’s BellyButton

January 27, 2009inf2241_classfi22412

Hello from the team known as Bruno’s BellyButton (an ode to everyone’s favourite socio-technical scholar).  This week we are reporting on the first real project assigned by our ‘client’ Matt who asked that we make a device which is to be a “highly moral, highly social actor” (thanks again, Bruno!).  In tackling this problem, we did not start by devising an elaborate scheme rich in social/moral commentary and then attempt to find the parts necessary to build the vision.  Rather, our design was an example of ‘making the most out of little,’ seeing what was available in the lab and imagining what sorts of social behavior or morality the found pieces could be used to influence.  Muwahahaha…  After examining various accessories including a Wii controller, we decided we were not quite up to that level of ‘hacking’ just yet.  One of our team members (the handsome asian fellow) had brought with him a recently-purchased ball switch, which we hooked up to the Arduino board using the relatively simple digital_read (serial) configuration.  After a few mishaps with the wiring as well as monkeying with the code a little too much, we finally got it to work:

So… what could this be… the ball switch is very physically-oriented, and sends an alert (via LED) when the assemblage is tilted ‘out of plumb.’  Suddenly, memories of a stern, authoritative voice from childhood – “Stand up straight, do you want to end up with a hunched back?”  A-ha!  A Posture-Correcting Device.  To act as such, all hardware (Arduino board, wires & breadboard) was mounted on a rectangle of semi-rigid foam and double-sided taped to the top of a toque (how very Canadian).  The result resembled a bizarre ‘wired’ version of the cultural cliche of being taught how to walk ‘properly’ by balancing a book on one’s head:

Here is the final code used (comments in italics indicate our own additions and modifications to the sample Arduino code):

int ledPin = 13;    // choose the pin for the LED
int inputPin = 2;    // choose the input pin (for a simple switch)
// note: confusion between this declaration of variables
// and the ‘# DEFINE’ syntax in the other code sample

int val = 0;        // variable for reading the pin status

void setup() {
Serial.begin(9600);        // enable serial monitor output
pinMode(ledPin, OUTPUT);    // declare LED as output
pinMode(inputPin, INPUT);         // declare pushbutton as input

void loop(){
val = digitalRead(inputPin);    // read input value
if (val == LOW) {        // check input
digitalWrite(ledPin, LOW);    // turn LED OFF
Serial.println(“Tsk Tsk STRAIGHTEN UP THERE YE SLOUCH!”);
// write a stern ‘moral’ message to the user
} else {
digitalWrite(ledPin, HIGH);    // turn LED ON
Serial.println(” “);        // write a blank line if the user is ‘standing straight’
delay(100);        // delay to mitigate spurious signals

And there you have it: with this device implemented en masse, a utopia of upstanding citizens may be realized!


Follow Us