I thought about what ‘unexpected’ was supposed to entail for a long time. I was thinking about what could be ‘unexpected’ from an LED and all I thought about was it not blinking. After much contemplation, I began to think about using a photosensor. My first inspiration was glasses that would shine a light when it was dark, for no reason. But then I began to think of when glasses/goggles would be used along with light. My first thought was of mine workers. Soon my mind (unfortunately) drifted towards morbid thoughts, like how some mine workers would be stuck in the dark if the mine caved in. Considering the recent news, I also thought about the earthquake in Taiwan that trapped several people in rubble.
Soon enough, I decided to make a photosensitive light that would morse code H-E-L-P when the surroundings are dark. I made it in hopes of allowing victims to be more easily found, as people cannot scream for help for a long time.
I set up the RedBoard ‘normally’:
I then looked online on how to morse code H-E-L-P:
H = dot, dot dot, dot , E = dot , L = dot, dash, dot, dot , P = dot, dash, dash, dot
With some help, I was able to code the following (sorry for the bad quality, will learn how to use the website for next time):
When Aaron was talking about some example projects that could be made to fit this week’s assignment task, I was very puzzled. I kept trying to think of ideas that are original and creative at the same time. I wracked my brain and couldn’t think of anything. I resorted to talking to one of my close friends about not being able to think of any ideas and her reply to my frustration was to “do something that you know how to do best”. Therefore, this project contains some elements that I know how to do well – no, unlike the what the title suggests, I am not a thief. I, on the other hand, know how to annoy my friends.
I, therefore, wanted to make something that could potentially annoy others (what better way than to do that with noise, am I right?) and have a practical use. Thinking of what I could do with a buzzer and an LED, I thought of making something that would surround an object so that when (let’s say that you have a cat) your cat tries to steal your box of cereal, for example, the shadow of the cat, when close enough, will cause the buzzer to sound and the lights to turn on.
The midway process video is shown below, where I first coded so that the darker the surroundings, the brighter the LED would get. I couldn’t figure out how to make the initial no-shadow/darkness situation be that so the LED was turned off. It was only after that I realised an extra section of calibration was required – which I implemented into the code (link below).
I originally wanted to put the Arduino and breadboard into a box so that it looks more “discrete” in practical terms and so made this box. I didn’t end up using it though because I couldn’t manage to control the LED light levels (even with calibration) and make it stay off initially and only turn on when a shadow “approaches” the object. I realise now that I’m writing this that I could put the photoresistor on the outside of the box so that it sticks out like I originally wanted the LED to do. Nevertheless, I didn’t end up using the box. I guess one good thing about not using the box is that I got to see my code work “properly” in the sense that originally, it was quite hard to see the changes in the brightness of the LED. Putting it in a box would’ve made it even harder to notice the changes due to the initial brightness being low already. I was able to see that my code was working properly.
Figure 1: The box that I made and didn’t end up using
After the process shown in the video above, I connected the buzzer to the circuit and wrote code that basically said that if the LED was at the brightest, the buzzer would sound on. Meaning that when the cat/person was closest to the object (in this case, the board) the lights would turn on and the buzzer sound on. I thought that this could potentially be a way for the cat to be scared away.
I didn’t realise how sensitive the photoresistor would be. I ended up having so much fun with my assignment that I’m sure I disturbed the whole lab with my annoying buzzer noise. But hey, like I mentioned before, annoying people is what I know how to do.
Quick sorry to everyone who was in the lab while I was playing around with the code and then further messing and fooling around with shadow!
Improvements:
Use more LEDs so that there is more scare effect
Blinking LEDs so that it looks more like an alarm?
Change the buzzer into a speaker and play some really annoying alarm sounds that would annoy all humans and animals
Make the whole thief preventer more discrete so that the thief would not expect an alarm to sound and lights to light up – i.e. incorporate the box into the project and make it a lot more practical (though the USB would still need to be plugged into my computer so I’m not sure how it’ll work).
People never really know if their fever is bad enough to get them out of bed and go see a doctor. This often causes them to miss the optimum diagnosis and recovery window. But don’t fear just yet! Introducing the all new revolutionary therMOMeter 2000! This intelligent device will take your temperature in a matter of seconds and remind you that you need to go see a doctor right away with an alarming red light — just like how a mom would!
The hue alternates between blue (you’re cold), green (you’re fine), and red (you have a fever).
Here is a simple demonstration of the TherMOMeter in action:
Before settling on the TherMOMeter, I experimented with many different sensors including the pressure sensor, the photoreceptor, and the sound sensor. I ultimately opted for the temperature sensor because it was very responsive and adorably compact. The sparkfun website offered a lot of insight in terms of how to properly install the sensor onto the circuit board. Installing the sensor backwards (incorrectly) actually caused it to heat up!
A screenshot of the code I used is attached below:
At the beginning, I was unsure of how to do something ‘unexpected’ with some lights (disclaimer: I still don’t think this is unexpected enough but oh well). As I was crossing the road the other day, I noticed that people kept pressing that little button that was supposed to make the waiting time at the pedestrian crossing faster. I wondered if that actually had any effect on the time difference of the blinking of the traffic light.
I decided to try to create a circuit where, using a pentameter, could control the speed of the blinking of the traffic light. I began by setting up my circuit on the board.
I had my pentameter as an input at A0, my red light attached to the digital output 13, the yellow light at digital output 11, and the green light at digital output 9.
I struggled a little bit with the coding so I went back to the codes we did last class and watched the videos on Analog Input and Analog Output to try and comprehend how it could be done. I don’t think my code ended up being the most simple, but I tried to make it clear enough that I could understand each step, even though I’m sure that there are several extra parts that could be eliminated. My final code ended up looking like this:
In the end, this is how the circuit worked when plugged in with the code:
I think it would be really interesting to figure out much the ratio is between blinking lights at the traffic lights, and how to program the differences in the blinking of the lights.
The way Norman discussed deficiencies in human-machine interaction was fascinating. I believed that the lack of understanding of principles necessary for effective human-machine interaction was the fault of the person on the other end who was using the machine. I always believed that the lack of understanding resulted from the lack of education on technological use. Norman explained how deficiency in human-machine interaction occurs because the design is done by engineers, who are experts in technology but limited in their understanding of people. This seemed so blindly obvious but I could not grasp why I hadn’t thought of this earlier. Engineers tend to think they understand people because they are people themselves, however those who have studied human behaviour understand how amazingly complex it is. It was intriguing to read that difficulties in effective human-machine interaction was caused the technology and not the people. It was also interesting to read the paradox of technology towards the end, the same technology that simplifies life also complicates life by making the device harder to learn and use. It made me realise that good design is not solely limited to the understanding of technology, it goes beyond that, to the understanding of psychology.
Our eyes are unreliable. If you’re anything like me, you’re always frustrated at how our eyes don’t measure brightness linearly. No? Just Me? Sunlight is on average 20 times as bright as indoor lighting and we definitely don’t notice that much of a difference. Anyways, moving on, I wanted to make something that will measure the brightness and give an easy visual indicator to the brightness level currently in the room (and won’t lie to us like our eyes do). So I did this:
The values read from the Light Dependent Resistor are from 0-1024, so what I did is divide the reading by a 100, and store that number in an int variable. What this did is that it extracted the most significant (leftmost) digit of the reading ex: extracts the 7 out of 721. Then, in a for loop, I would set the pins from 0 to the extracted number to high, which resulted in what was shown in the video.
code:
int beginPin = 2;
int endPin = 11;
int sensorPin = A0;
void setup() {
// put your setup code here, to run once:
// for loop to set all the pins to output so I don't have to do it manually
for (int i = beginPin; i <= endPin; i++) {
pinMode(i, OUTPUT);
}
Serial.begin(9600);
}
void loop() {
// put your main code here, to run repeatedly:
int sensorReading = analogRead(sensorPin);
// extracts the leftmost digit of a 3 digit number
int leds = sensorReading/100;
Serial.print(sensorReading);
Serial.print("||");
Serial.println(leds);
// for loop to turn off all the leds before setting the relevant ones to high
for (int i = beginPin; i <= endPin; i++){
digitalWrite(i,LOW);
}
for (int i = beginPin; i < (beginPin+leds); i++){
digitalWrite(i, HIGH);
}
}
Oh also as an added bonus, it can also display the brightness as an 8-bit binary number (0-255)
code for the binary display:
int beginPin = 2;
int endPin = 11;
int sensorPin = A0;
void setup() {
// put your setup code here, to run once:
for (int i = beginPin; i <= endPin; i++) {
pinMode(i, OUTPUT);
}
Serial.begin(9600);
}
void loop() {
// put your main code here, to run repeatedly:
int sensorReading = analogRead(sensorPin);
byte x = map(sensorReading, 0, 1024, 0, 255);
Serial.print(x);
Serial.print(" : ");
for (int i = 0; i < 8; i++) {
digitalWrite(i + beginPin, bitRead(x, i));
Serial.print(bitRead(x, i));
}
Serial.println();
}
keep in mind that on the serial monitor this will print the binary number in reverse.
In this article, Norman emphasizes that how aesthetics can improve user experience after some people criticize Norman for overlooking the values of aesthetics in design.
I never see the usability and aesthetics at odds. They are both contributing to the overall user experience. After all, it is up to the users to decide whether a design is good or bad. A beautiful car that is broken may be useless, but an ugly car that is functioning may also be very frustrating to the driver. However, the focus should really depends on what kind of product we are talking about. A designer should concern too much about the colour of the drop-down oxygen face mask on airplanes as long as they flow oxygen properly when deployed. However, when it is possible, when do we try to make our product both functionally sound and aesthetically pleasing?
The glass door with no markings that indicate where to push, the sliding door that could be a push door or a pull door, the sink that is impossible to empty… all of those spectacular design failures are common objects in our daily lives. The awkward interactions and experience with this kind of objects are too familiar to me. I do not have to leave my dorm to find examples. Every student dorm on campus has a drawer with three drawer boxes. On my move-in day, two of my roommates and I spent almost an hour trying to figure out how to open one of the drawer boxes until we broke it by trying to force open it. It took me an entire semester until someone told me the secret: “you have to have all drawers completely shut before you open any drawer”. I sometimes use it as a joke to mock how “stupid” I can be sometimes. However, I completely agree with the author’s view here: if only “smart” people can figure out how to work something but not the majority “stupid” people, then the design of that thing is at fault, not the people. It is the duty of machines and those who design them to understand people. It is not our duty to understand the arbitrary, meaningless dictates of machines. Designers need to focus on the experience of people who are completely clueless rather than people who had experience interacting with similar mechanisms before.
I felt that the title “Attractive things work better” was quite mismatched to the actual content of the text. Norman discussed how pleasurable designs are not necessarily usable. Subsequently, I find the title confusing as it contradicts what Norman said about the tensions that exist between attractive design and usability. Also, according to the title, I expected that the article would demonstrate how attractive design works better. Rather, he demonstrated how attractive design is more important in some situations than others (ex. high stress situation versus low stress situation). He didn’t explicitly explain how attractive design works better, or what he meant by attractive design. Is ‘attractive’ inclusive of beauty and usability? He simply kept repeating the idea that attractive things work better without offering a sound reasoning as to why that is the case. Although he made interesting claims about how negative and positive affects one’s mindset, and the relationship between design and neuroscience, I found his arguments to be underdeveloped. It was interesting information, but it wasn’t delivered coherently.
When I began reading this article, I was confronted with the statement: “If we were to follow Norman’s description, our designs would all be usable, but they would be ugly.” Immediately, I felt confused and kind of defensive. I saw no where in Norman’s work any indications that designs would end up ugly. As I continued reading, I realized that this point is argued, which made me feel better. The idea that aesthetic and functionality should go hand in hand made sense to me, so I did not consider for a second that Norman’s work excluded aesthetic value because it was not important. I simply assumed, as he later points out, that aesthetic is not mentioned because it is not the primary argument.
This piece lends a focus on behavior rather than design in particular. The affect and behavior of humans can dramatically alter their relationship with a design or task. Negative affect can make easy tasks harder, while positive affect can make difficult tasks easier.
Understanding this aspect of behavior and affect, it is clear that usability and function should be in balance to aesthetic and beauty.
