There was a point in the reading where Norman talks about how a bookmark placed in a book can be a signifier. How it shows the amount of pages that are left until the end. How when a student places a bookmark they are confronted with the idea that there are ‘n’ number of pages left until it’s finally done. This was extremely relatable when reading his piece.
Although sometimes the piece seemed to drag on and Norman seemed to be repeating his point and explanation over and over again, his arguments are solid. In his conclusion about how a good design is the combination of various fields and the understanding of human nature made a lot of sense to me.
I’ve had many discussions with my brother about using Androids and how they are more ‘efficient’ and have higher capabilities. However, as a loyal iPhone user, I find the appeal of the phone not centered around its usability but also its aesthetics, simple to use and easy to understand interface, compatibility with other devices etc. . Perhaps it’s human to like simple and pleasing rather than ugly but efficient.
Also, I found it funny how he was describing a watch that had social media and smartphone like capabilities because all I kept thinking was: Apple Watch!!!
Perhaps “The Design of Everyday Things” takes a different turn after the first chapter, but none of what was written in this article seemed incongruent with what was written in the book. While “The Design” emphasizes the clear transmission of functions, it does not suggest to me that this would necessarily make things uglier. In fact, when he identifies that “[g]reat designers produce pleasurable experiences”, I could easily see aesthetics being implied in this. It is certainly true that the importance of emotion was not thoroughly analyzed and that there is a great deal of interesting and relevant information in the article, but if feels like a natural extension of the design philosophy previously mentioned. If the primary mechanism for determining the quality of a design is the response people give to it, then pretty things will obviously score higher than equally functional ugly things.
Unlike the previous readings, I don’t have much to say about this reading, as I found that it was almost exclusively new and comprehensible ideas to me. While my experiences with a number of designs differ from the authors, especially concerning the sink, his identification of the problem and proposed solution both seem feasible to me. However, that does bring me to the one questionable moment I found in his analysis. In his introduction of human centered design he mentions that part of the process is “to avoid specifying the problem as long as possible but instead to
iterate upon repeated approximations.” While this clearly works as a stopgap, throughout the rest of the chapter he is able to clearly identify what is wrong and what the solution could be for a number of bad designs. These solutions also all fit together in a consistent framework, and so it seems to me that with some development it should be possible to remove the iterations and allow the minimum requirements for a good design in any situation to be known before the object is ever made, much less used. There would almost certainly be multiple “correct” solutions, but this seems to me to be the point at which the engineers would get on board and the difficulty in communication between departments, as he identifies at the end, would lessen.
Have you ever been on a date and the other person begins to be… a little too handsy?
Well say no more, because the “Can’t Touch This Sweater” is the perfect product for you.
Not only will you know that your date is being rude because of their hands, but the flashing red light will show other people that your date is being a bit too handsy.
What do I mean? How does this product work?
The product comes in an adorable black colored sweater, with a cute traffic light on it.
Ok ok, so now you know how it looks, but what exactly does this thing do?
Well, the sweater is at a constant green light as such:
And in the circuit, there is a soft potentiometer. This is the analog input source.
This potentiometer is meant to be around the chest area of the woman. (Sadly, this was not possible to do on my model due to technical problems.)
Therefore, when there is no contact on the chest area (ie, the soft potentiometer) the light is green. This means everything is ok.
On the outskirts of the soft potentiometer, if there is a pressure, it will still be green. BUT THIS IS ONLY FOR A VERY SMALL SECTION OF THE POTENTIOMETER.
When the person’s hand begins to come too close to the soft potentiometer area, the light will turn yellow as so. (This area means it is approaching a place it shouldn’t be, but is not quite there yet.)
And then finally, when the person’s hand is about to reach the chest zone, the light turns red. This indicates that their hand has gone too far and they need to BACK OFF. (Unless consent is given; then by all means continue.)
And so, here is a video demonstration.
How I made it:
From there, came the physical sweater part.
INSERT IMAGE
In my circuit, there is a soft potentiometer and an RGB LED.
As for the code, the soft potentiometer works in a range of 0-1023. Taking this, I divided the strip into approx:
green —> 20% of the strip
yellow —> 50% of the strip (yellow in an RGB LED is done by activating both the RED and GREEN)
red —> 30% of the strip
(in this order.)
Here is my code:
*The sweater will not soon be in stores. It was inspired by light-up Christmas sweaters. The next model will have a switch to turn off the green light.*
1) I wanted the LED to light up when the brightness was low and vice versa using the LDR. I had multiple ideas of how to build the circuit, but every-time I tried executing my idea I struggled with actually getting the plan to be successful. One thing I could do better next time is to actually sketch out my idea using diagrams. I looked at an Arduino tutorial to help clarify how I should set the circuit: https://www.youtube.com/watch?v=4fN1aJMH9mM. However, I wired it in a different manner that was more familiar to me.
2) I wanted to take one step further and work on fading the lights in and out instead of the lights abruptly changing every time it was dark and bright. I wanted the LED to vary in brightness depending on how dark the setting was. I implemented the code as seen below, however that only contributed to the dimming of the LED. I did not achieve the results I desired.
3) I learnt that the problem arose from the fact that the ledPin was at 7, which was not an analog output (PWM). Only when I switched it to a PWM would the LED fade. Adham helped me write my code more efficiently (ex. adding a map function instead of doing the analogRead under the loop function in the Example #2). However, even after writing the code efficiently and switching the ledPin two its proper location, the LED would brighten very subtly when it was dark. The change almost appeared non-existent. Only after switching around the values in the map function (by looking at the highest and lowest values from the serial monitor) was I able to see a difference in the fading of the light.
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.
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.