It’s all about a leap
This class feels like it’s over before it even started. From what I can remember of what we did on the first day, we were introduced to p5.js. Before that day, I had thought I knew the programming language, but when I even read the list of functions for A1, I realised I knew only about half of them. I then realised how versatile programming languages are. You could think of practically anything, and p5.js would have a built-in function for it. After coding in Java first, then in Python, and now in p5.js, I realised how much coding languages have evolved. In the sense, in Java, to find a particular function (say to check if the mouse is pressed), you would have to look up the syntax, however, with p5.js it is so much more intuition-based (it’s literally mouseIsPressed).
After exploring a few functions for dictionaries and arrays, I got a hang of the syntax and the way one codes in p5.js. In the following week, we had to work on our Document of Understanding with an area we had identified within E-governance. Chaitali and I chose DigiLocker, an e-locker scheme started by the government. While researching, we came across the different features that it had and the pros and cons of using a system like that. However, because it isn’t a very popular service, we hit a roadblock after we researched a little bit. Gaurav then told us about design fiction — something very similar to speculative design, where one doesn’t consider the limitations that bind us in this world, but designs for a completely different world, where these limitations don’t exist at all.
I’m more practical than I am imaginative, and so coming up with a design fiction story was a little tough for me. I couldn’t imagine a world without the things that exist today, and so I couldn’t imagine designing without them. However, we then collaborated with Arsh and Janaki, which made it a little easier for me to think wilder. We did an exercise where we all built on a story, making it even more speculative. I think that exercise really helped me get a hang of how to design for an imaginative world. By the end of it, we were talking about a chip in our thumbs (in a world where the internet doesn’t exist, and you can’t hurt your thumb) so normally that other people I’m sure thought we were crazy.
The coding of the idea, in the beginning, was very annoying, because I felt like there was a gap between what I wanted to do and actually doing it. We didn’t fully know how to get around the functions and the structure, but with some (actually quite a lot) trial and error, we managed to achieve something.
What started as a 10-day studio, came down to 9, then to 8, and finally to a seven-day studio, but the 12-hour hackathon made up for it all.
Should designers code?
Should designers code? — A question that crosses my mind every day. However, seeing the advantages that one has when he/she can execute a conceptualised idea, I feel that five years down the line I will find myself in the grey area between coding and design. With technology like Artificial Intelligence (AI), Internet of Things (IoT), machine learning and so on being developed, I feel that engineering has reached its peak. However, how many people do you know actually own and use Alexa or Google Home? Though technology is advancing every day, only a selected few are reaping its benefits. I think that’s where designers (Human Centred Design, more specifically) come in. Since we as designers have a more people’s approach — that is for the people, we could make technology usable and accessible all the way down the social ladder. For designers to be able to do this, understanding how this technology works is key — and all that lies in understanding the backbone of it all, the code.
I might be a little biased to this because I love coding myself, but I feel like understanding advanced programming concepts, too, is necessary for designers. You cannot go to a big company and expect their code to be a set of if and else statements. If you really want to understand this code, delving deeper into programming is essential. After working in this studio, and even in the last studio (on Amazon algorithms), I realised that even to simulate a 10x10 warehouse took so much effort because of the complexity. And as the complexity of a system increases, so does the complexity of the code.
How should a designer learn programming when most of them really not accepting to learn the technical aspect of it?
I feel that code is very logical. Imagine this — you have two places, 400m apart. If you were to tell someone how long it would take to get there on an average, what would you do? You would first approximate a speed that a person walks at, then count the number of turns etc. the person would have to take. This is in an ideal situation. If you were designing for a real-world situation, you would take into account various other factors — traffic, roadblocks, road conditions and so on. This is exactly how one codes too. Take the variable factors as variables, and the constants as constants! I feel most people are afraid of coding because they are intimidated by the syntax. That’s what initially happened to me too. However, what they need to understand is that coding doesn’t equal syntax, that’s the last part. If they would solve a coding problem exactly how they would solve it in real life, I think it would help remove the fear of technical language.
Your review on the reading: An interview with David Kelley by Bradley Hartfield
The reading is very interesting and speaks about the difference between engineering and design. I feel it’s very valid in a course like this (AP&P), which is close to the intersection of the two fields. The reading says that design requires taking a leap, a leap which at most times is uncomfortable (I can tell from first-hand experience). As I’ve mentioned before, thinking of a design fiction story was tough for me. I think the main problem is the fear of failure. From the way we are taught in school, the fear of not being correct in inherent in most people. We’ve always been taught that everything is either black or white. There is no grey. But what design teaches us is to take that leap and see that what you think is black could white and vice versa. Engineering, on the other hand, deals more with implementation. Engineers have been trained in a certain way. “Whatever comes up, they are supposed to apply the methodology — to analyse and synthesize.” Speculation doesn’t play as big a role here because they play safe. They’ve decided a particular set of conditions (or assumptions), and anything that doesn’t follow that is deemed false. However, designers would work with the things that don’t follow conditions and design for those instead.
Relevance of object-oriented paradigm in design, thinking and programming
Object-Oriented Programming (OOP) was something I was introduced to back in ninth grade but hadn’t fully understood the use of until this studio. OOP uses classes and objects to divide a full problem into smaller parts. For instance, take a car. It has many parts — steering wheel, wheels, gears, wipers, windows, doors and so on. If you were to solve a problem that a car was facing, it would be easy because you would know where exactly to look. For example, if the seatbelt wasn’t working, you would know it was spoilt. But what if a car had no divisions of parts. The whole thing was just a CAR. Where then would you look to solve a problem if it occurred? OOP works similarly. It divides code into classes so that classes that relate to each other can communicate with each other (through objects) but aren’t part of of the same big chunk of code. It also makes it easier to understand the relationship between each part. In the car example, you know that when you press the clutch, you can change the gear, because of which you can increase the speed of the car. In OOP, classes share different types of relationships, which makes it easier to understand the bigger picture.
