In this class I learnt a lot about how to use the print function. I learnt that if I want to print out a specific phrase, then I need to put it into quotation marks in parentheses after the word print. However, if I wanted to write one phrase in many different ways, I need to assign is as a variable and then make it uppercase or lowercase using the str. lower or str. upper function. I also learned that for user input it required to be a variable with an integer to be compared with another integer. If the input is not a variable number then it cannot be compared to a variable.
I think this connects to design thinking because when programmers are trying to create something, they ask the public for what they want and try to program that. If the public wants a certain website for a certain function then the programmer can create that website. The creator can then test out the product and see if the public likes it and the go back to prototyping.
I can create effective surveys to pinpoint a certain Point of improvement to empathise with my audience. I can prototype a product with an end design in mind. I can create surveys to see if my audience likes my product.
Design Thinking Sentence: Our students have problems with the location, space, and the locks of their lockers, so we have decided to give students temporary lockers in 2-3 locations with student id’s (or temporary passes incase of lost id’s) as the locks.
We first decided on a problem in school, and we chose lockers as a problem in the school. We then developed questions to ask to our peers about lockers to try and focus in on what we wanted to improve. We had many complaints about the location of the lockers, so we decided to put lockers in 2-3 locations around the school. People also had issues with their locks so we decided to use a control panel type of lock. This control panel requires students to swipe their id cards to gain access to the panel. We created a model of it using cardboard and made a questionnaire. The people who filled out the questionnaire seemed to like the idea.
We were asked to program a peer to get multiple hkis shields around the room. My partner was programming me, so he wrote the program. We were successful because the spot that we started in had many shields so it was easy to get them as they were so dense. We encountered a problem when we realised that we needed to communicate to the “robot” to reach out to get the shields. Although this wasn’t too much of a problem, it would still take time to get the shields, time that we didn’t have. Another problem we encountered was when we were one step short of getting something, causing us to not get the fourth shield, which would have meant winning. We could improvise on the spot better.
Tying a shoelace: In this activity we had to figure out how to tell a robot how to tie a shoelace. I think that we did it in a good amount of steps which was 5. I think that we could have done it more clearly and in less steps. When we tried out the program that we made, we had to make some changes because it wasn’t clear enough. I think that this taught me a good lesson about testing the program.