Week 16
Evolution of the purpose of this blog, shape coding, the importance of articulation, forbidden fruit effect, a tool to get divergent colour palettes and my plan for the website of my life.
It has been over one hundred days since I embarked on this weekly writing endeavour. What initially started as a means to fulfil a promise that I made to myself in college, soon turned into something more for me; something that I hadn’t anticipated.
About two weeks ago, my mentor asked me why I write this weekly newsletter and I gave her my usual answer (something that you’ll find on the ‘about’ page of this newsletter too). Today, after over 15 times of sitting down and summarising my week, I think the reason to write this blog has evolved a little bit and I’d like to take some space to record this.
All my life, I’ve worked from week to week. Every Friday, you’re forced into a retrospective zone where the previous week closes off and you begin to prepare for the next one. When I think about my week, I usually go down a more negative route: could’ve done more, should’ve done more, still so far away, so much time wasted … you know, the usual.
When in August I started to actively record the happenings of my week every weekend, I was shocked. The sheer number of things that I’d come across in a single week, the thoughts that I’d developed on, my learnings and my progression with experiments were far more than the ones in my head. All my life, I’ve undervalued what I’ve done and writing this blog helps me say: Arjun, you know what, you did OK this week.
I think I’m more pessimistic than optimistic and, like everything else, this also has its boons and banes. In short, writing this blog makes me feel less like shit and even if I turn out to be a complete failure in the long run, I know that I tried pretty damn hard.
Anyway, with that being said, let’s get into the stuff from this week.
[Learnings] [Concepts] Shape coding to design control panels
In an extremely well-written farewell article by Ian Levy, director of the National Cyber Security Centre UK, I came across the concept of shape coding which is now a method often adopted by the design of control centres.
For example, back in the day, all controls felt similar to a pilot when they held them.
When some research was done around why these aircrafts were crashing while landing back at base back in World War Two, it was found out that pilots were exhausted and ended up reaching over for the wrong switch, killing everyone on the plane.
This investigation then led to the concept of shape coding which basically means that a control’s function is signified by the shape of the control. Hold a lever, and you know that it’ll operate the landing gear. Open a panel with the big red button and you know that it’s meant for emergencies and not to open the landing gear.
Interesting design concept, something that we see in the world so often now.
[Realisations] The importance of articulation
At TinkerLabs, we finally managed to make some concrete progress on a tricky project. During the process, we went through several iterations of the same step; majorly focusing on getting the articulation right.
The importance of articulation stuck with me when my mentor & I were coming up with a lesson plan for a course that we both teach together. The goal of this particular session was to try and show how challenging assumptions could lead to innovation. We discussed the case of the ‘Sacco’, which is now popularly known as the bean bag.
If the brief, at that time, was articulated to be: design a better chair, I doubt we’d have gotten the bean bag. We’d just have gotten a mildly better chair. However, if the brief was articulated to be “design a better way to sit”, we’d probably have gotten the bean bag as a result. Or a water chair. Or a hanging-swing-type chair. You get the point.
More often than not, we spend very little time articulating in the design process. Be it user needs, pain points, insights, or even problem statements, far too often the first version is what we stick to. What we fail to realise is that each such decision majorly changes the course of the project. A specific articulation of a user need might lead you to base your project on something that might not have been true in the first place. Or you could be working with a problem statement that narrows your playing field by far too much and you’d never realise this.
I’m glad to have seen the effects of deliberate articulation versus immediate articulation in my observations at office. I think this is a useful mindset to develop.
[Learnings] [Behaviour Science] The forbidden fruit effect
In an interesting paper by Alice Binder, Brigitte Naderer and Jörg Matthes, they expand upon what is now termed as the “forbidden fruit effect”. In their research, they exposed kids to two different versions of visual stimulus containing a mandarin; one in fruit form and the other in candy form.
What they found was that for kids who belonged to households where candy was banned, there was a higher level of emotional arousal for candy when compared to the kids who belonged to households where candy was allowed.
The researchers further connected this to reactance theory which says that, fundamentally, as human beings, we love breaking rules that are imposed on us by others because we want to behave according to our own desires.
The outcome of the paper suggested a forbidden fruit effect, meaning that anything which seems to be unavailable is, as a result, more desirable.
[Resources] Divergent colour palettes
Came across this fantastic tool to use for data visualizations.
What it does is give you a range of colours that move from one extreme colour to the other, with a neutral one in between. This results in a colour palette with good visual contrast between the two ends of your data to make your data viz ‘pop’.
[Articles] Time Magazine’s Best Inventions of 2022
TIME Magazine recently published its list of the Best Inventions of 2022. These are the most impactful new products and ideas of 2022.
[Personal Projects] Finally some website progress
I’ve wanted to update my personal website for quite a while now but realised that I didn’t know enough to do so. I wanted to build a website from scratch (so that I don’t have to pay anything) that also caters to my unique needs (believe me, there are many).
In the last two months, I undertook a basic HTML+CSS course from freecodecamp.org to be able to actually code a website. Then, I re-visited the technical aspects of some portfolio websites that I’ve loved for over 2 years now and finally, they started making sense to me.
I now have a concrete plan to make something that I hope will serve its purpose for a long time without having to depend on any third-party tool, like I currently do for my website.
In short, the plan is to use something that allows me to convert text written in markdown to HTML, which is then styled with a static site generator sitting on top (something like Gyan does for his website).
Apart from this, I want the website to be a complete web experience + an extensive documentation of sorts (a weird mixture of concepts from Yehwan Song’s website and Manaswi’s experimentation documentation).
This one’s going to be probably my longest project yet and I hope to build it by October 2023. Things that I needed to know are in place, the plan has reached iterative development and now the only thing left to do is start making these, one by one and hope that they tie in well together.
Sounds like a stretched-out version of my undergraduate thesis project, but only this time, I have a year to make it. Does that make it better?
I don’t think so 🥴