Sketch ideas
I began sketching some ideas on the types of microinteractions I wanted to come up with, with relation
to motivation. My ideas were simple...but they could potentially get very complicated.
One of my ideas were about linking the digital microinteractions on a screen to translate into a
physical microinteraction. For example, by pressing the like button on any social media platform,
there will a Heart In A Box that pops out and makes some really annoying sounds. As I have found out
that people mainly procrastinate on their phones when unmotivated, this was one of the ways I thought
of to invade their time on their phones.
Another idea was a physical Health Bar. There will be a set amount of lights on the bar, and every
time the unmotivated individual interacts with the like button or any interactive button on a post,
one light will go off. When all the lights go off, the phone will turn off. In a way, it is a limiting
device.
Consultation
Presenting my initial idea sketches to Andreas marked a pivotal step in the creative process,
reinforcing the importance of breaking out of my comfort zone. Andreas encouraged me to delve into the
practical aspects by suggesting the unpacking of the Arduino box as a starting point. This involves a
systematic approach, including labeling individual components and providing detailed descriptions of
their functions. This hands-on activity not only facilitates a deeper understanding of the Arduino kit
but also sparks ideas for potential outcomes that can be achieved through the manipulation of these
components. By exploring various configurations and connections, the Arduino box becomes a versatile
tool, offering the potential for creative and innovative applications that can be harnessed in my
design process. This exercise encourages an experimental mindset, fostering a more dynamic and
expansive approach to my creative endeavors.
I needed to start small. Like finding out how to light up 1 LED, and then make it blink... Use a
button or a servomotor. An important part of the conversation we had that I remember is this, "You may
think it is simple to turn on a light, but your mother will probably say its amazing." For some
reason, this sticks to me and has made me realise I've just been overthinking and downplaying my own
capabilities.
Arduino Unboxing
Embarking on my Arduino experiment marked a hands-on journey that began with meticulous preparation. I
took the time to label each component, creating a personalized reference guide for myself. Armed with
this resource, I confidently followed the instructions, navigating the intricacies of the Arduino kit
However, when it came to setting up the breadboard, apprehension crept in. Fearful of breaking
delicate wires, uncertainty clouded my attempt, leading to an unconventional horizontal arrangement of
the breadboard, resulting in a disjointed setup.
Surprisingly, I underestimated the significance of the rows on the breadboard, assuming electricity
would effortlessly find its path. This oversight prompted doubts about the circuit's integrity.
Engaging in a trial-and-error process, I changed wires and the LED, only to discover that the culprit
was a set of defective lights. This unexpected hurdle, while frustrating, unveiled a crucial lesson in
resilience and troubleshooting.
Despite initial challenges, the experiment concluded triumphantly as the LED lit up without the need
for code, utilizing the direct 5V output pin. This experience not only emphasized the importance of
meticulous setup but also underscored the value of perseverance and adaptability in overcoming
unforeseen obstacles. It's a reminder that hands-on exploration is not just about the end result but
also about the iterative process of learning, problem-solving, and the unexpected discoveries that
unfold along the way.
.jpg)
.jpg)
Paywall hurdle...or?
Navigating the final stages of my prototype development has brought me face-to-face with a
significant hurdle — the necessity of a two-way communication channel between Arduino and
screen-based software. Enter Protopie Connect, a seemingly seamless solution, but at a steep cost
of $80 per month. This financial commitment raises immediate concerns, as committing to the
subscription for the entire year could tally up to $400, a weighty investment for a five-month
prototyping period.
The crux of my reflection lies in the apprehension surrounding the post-subscription life of the final prototype. Will it remain usable for showcasing purposes, or will it become a relic dependent on the subscription's continuity? This question lingers, urging me to consider the long-term implications of relying on a tool with a hefty price tag. It sparks contemplation about sustainability and the broader accessibility of the project beyond my immediate prototyping needs.
Attempting to mitigate these concerns, I grapple with the question of documentation. How can I encapsulate the essence of the project in a way that ensures its longevity, even without the Protopie Connect subscription? It becomes evident that my documentation strategy must transcend a mere procedural guide. It needs to encapsulate the journey, the roadblocks, the alternative paths explored, and the lessons learned. This documentation serves as a lifeline, not just for me but for anyone interested in understanding and possibly reconstructing the project.
Yet, as I delve into forums in search of alternatives, I'm met with a barrage of technical terms like HC05 and Python, realms I'm not entirely familiar with. The frustration grows as I stumble upon seemingly promising alternatives, only to realize they either lack the required bidirectional communication or are in beta stages, limiting their functionality. The daunting nature of these technical alternatives prompts self-reflection on my technical proficiency and the potential gaps in my skill set.
