// current
// initialization
// using java because it's
// not web technology (since 2017)
String[] tasks = this.work()[2]().tasks;
Chapter[] chapters = new ChapterFactory(tasks)
.createMany(5);
write a designer personal statement
find a topic that I'm interested in
write an intro
write the rest
write the visuals
write this
Who am I? Why do I design? The act of writing a design statement didn't seem too difficult on the surface, I know myself the best after all. Everything started to click in place though, as the situation sunk in. The truth is, this wasn't the first time I struggled with self introductions. I went through that process when I needed to create an "About" page for my "Intro to Creative Media" class, then realizing that was the hardest part of writing a site. The fact that the next task on the list would be to write something I liked, told me things were going to be a hell of a doozy.
Screenshot of the "About" page
I sat down and started to think, why do I actually design? (I literally just sat down and thought, which is why I don't really have many fancy materials to show here xd) Here's my thought process, recalled:
Well, I don't only like things to look good
I want things to be satisfying I guess
Why the f*ck
So how do I design?
...
I try to walk to the edge of the ring of "done and accepted", then walk back from there until there's a balance of appeal & "my mom would hate that"
I sometimes definitely put in way too much effort to walk to places that no one has been to tho
they're places like the world's 17th highest mountain, no one cares if I climbed it, but I'd still have to literally scale a mountain
The fun things I do are definitely more spontaneous than planned out, now that I think about it
Wait, but then I plan out the sh*t I do after I decide I want to do the sh*t
This is sounding more and more like a study of chaos theory
When I design something, the result has a response
Now, is that chaos?
What's the "determined"?
Yooooooo
And after that train (wreck) of thought, I came up with a quick draft, summarizing some of the thoughts:
Design to me, feels like playing with the box you're supposed to think in. Hit it hard enough and you'll get a concussion, but maybe a satisfying final product as well at the end. As things go though, the questions of, "what tools to bash with", "which parts are the most vulnerable", and "why am I hitting a box", inevitably come up. One question after the next, and I often end up with things that I shouldn't have cared about enough to pursue, like convex hull algorithms just to create a picture grid next to some text written in the style of a forest fire. Thus, I guess all that just means I like design, for the chaos that it causes.
With that out of the way, I could focus on the next task, which was —
Find a topic that I'm interested in.
Well sh*t. I don't have anything to talk about regarding what I like to do. What am I going to do? Drop an audiobook because I like music production? (F*ck that's actually a good f*cking idea) What I did have though, was an ol-reliable strategy of writing about things that have caused me pain. I mean, it's genius, with failure you remember more details of the situation, and for longer. So, I present to you, my list of pain:
online classes
the inconsistencies of Android
corruption in school managements
some mental health bs
the limitations of web tech
Oh and also, I present to you my list of why pain is invalid:
This is already super talked about, with a lot of conversation. It's also kinda boring too xd
I didn't think I could do something unbiased, because I haven't used iOS for as long compared to Android.
This is kinda political, and uh, writing about something that you're depending on doesn't seem like too great of an idea xd
I've already written quite about this beforehand, so I was kinda burnt out by it at that point (ironic xdd)
okay yeah that's fresh, why tf not
And so just like that, I chose to talk about web development stuff.
A little backstory on why that topic came up in the first place. I had been working on a program, called "Auto Intro".
Screenshot of "Auto Intro"
The idea came from a parody video I made some time ago that gained some traction, about a program that could create "intros" basically only using one button and zero brain cells.
Screenshot of the animation that started the project
At the time, I didn't know how to code, which meant the program would stay fiction until development of it became practical. That time came after I finished my first full fat website, in which I used a library called "Lottie", that enabled After Effects animations to be exported into code and displayed on Web, Android, iOS, etc. Before that, I had only poked around with Lottie for Android, which was hell to get working properly (because I didn't know much about the Android dev workflow at the time), but I managed to get the web version working pretty easily, and even built a mini animation library around it. The eureka moment came when I pieced together the fact that I was fluent in TypeScript (a superset of JavaScript), and the fact that the files that Lottie used were JSON files (literally standing for JavaScript Object Notation). A match made in heaven? A match made in hell?
Screenshot of the full fat website that was based on my animation library, which implemented Lottie.
By the time I started on this assignment, I'd been developing this program on and off for months now, and had to do a bunch of R&D to get around limitations of the browser. Speed and especially memory usage ended up being way worse for the simple rendering that it had to do, as well as things like needing to introduce otherwise unneeded encoding processes because the hacky solution used to turn rendered frames into video. At the core it was a surprisingly simple program — only really consisting of a UI, a de/compiler for Lottie files, an editor for Lottie files, and a template generator — but it ballooned in complexity due to the lacking client environment, as well as the lacking developer environment (I had to do extra R&D to develop a solution for working code formatting).
All that basically bubbled into my want for a middle ground, something that would solve the client-side problems, as well as my stupid developer ones. That idea of a golden unicorn solution came to be, something with these criteria:
running natively on the client's computer
maintained by large entities
have the simplicity of the web
Writing it all down into words was pretty challenging. Initially, the audience for what I wrote was still unclear. I thought I was writing to a "me". This prompted me to put in words, what I thought was going to catch my attention. Unfortunately though, this made it unclear to everyone else what I was talking about; a context-less approach.
The web is a miracle. It has very much succeeded in achieving the original vision of what it was supposed to be — "a place to be found for any information or reference which one felt was important, and a way of finding it afterwards" (Berners-Lee, 1998). Though, some may argue that it has actually superseded the said aim, with the web as we know it, vastly different from what it was (Grinaker, 2019). The web currently houses many non-content driven applications, from simple canvas-based games to whole WebAssembly based virtual machines (copy, 2020). All this sets precedence on the question of, should web and web technologies be used outside of content driven applications? The reason why this question divulges into something less than a simple "yes", is because of the inefficiencies and inadequacies, said technologies bring. "Good enough" of performance and user usability, has been the de facto justification for the convenient use of web technology, as well as better developer experiences being the nail in the coffin (Ghadyani, 2019). The problem arises when said technologies seep into places that have to make sacrifices just to use it. As a user, heavier web based applications are often slow, lack features, or just plainly run with quirks. For example, unexpected user interface behaviours, large memory footprints, etcetra (Koretić, 2020). This even applies to the application examples mentioned above, as they have to deal with the limited WebGL, as well as convoluted workarounds in WebAssembly (Emscripten, 2015). As a developer, you are also handicapped by the "best advantage" of the web — interoperability across devices. You are forced to support many different types and versions of browsers, which means things from legacy javascript APIs that cause mild inconvenience, to platform bugs that break rendering completely (Bureau, 2020). With all that said, a proposed solution exists, and will be explored below — a standardized platform independent wrapper for native platform APIs, with a toolchain resembling the web stack.
Thus, this v0 was short-lived, as I knew I had to pivot.
I started out my refactor with a plan.
it's taking over the world anyways
content-driven
should be feeding the user information
the traditional type of "program" made with web tech
typically not resource intensive, with majority of business logic living in the server
application-driven
should extract information from and exchange information with, the user
recent, and increasing amount built with web tech
can be resource intensive, running business logic/computation on the client device
typical websites
social media apps
typora
spacex dragon
they are the creators of the most popular web based framework — "react"
aims to solve the problem of reactivity of user interface components
enables said components to react to changes in data with ease while being "performant"
they are the "f" in "faang"
have massive development teams for every platform they create
should be able to showcase both the pros and cons across spectrum
how they use
web is react
mobile is react native
why i choose
facebook's flagship app, should have the most work put in it
is very content-focused, and thus performs good enough
some unexpected ui, eg. expandable drawers that cause big ui shifts
doesn't deal with large lists or datasets
doesn't contain features that require specific hardware
(unsafe) has performance budget for animations, making the experience a lot nicer
how they use
web version built with react
mobile version used to be native, but after bought by fb, now uses react native
why i choose
web version has historically lagged behind mobile app counterpart even though they can share a lot of code
mobile version contains bugs and weird problems that come with either replacing native components, or having to run business logic on main thread
doesn't always conform to user interface expectations, eg. buttons not giving feedback, sliding drawers not being able to be controlled using gestures, etc
can get sluggish while doing simple tasks, eg. switching between tabs, editing profile, exiting and reentering app
does the content-focused part very well, the "app" part not really, as when content has been loaded and is being shown, it generally performs well
(unsafe) animations in app are stripped back (eg. tab switching) but still present in many places (eg. bottom sheets)
how they use
web version built with react
desktop version built with react native
mobile version experimented with react native but switched away in 2017, a rewrite in 2020 stripped away many cross-platform code as well (→)
why i choose
can get very slow on web and on desktop, especially with long conversations, but not on mobile
has most features but also a history of being bloated
competitors cannot reach its level of features and speed of implementing them (reactions, msg replies, minigames, planners, secret conversations), but they also perform a lot better
many many unexpected ui, eg. weird logo menu on messenger desktop, intrusive time popovers on web, confusing message kebab menu, image overlay that cannot be dismissed by clicking on it
(unsafe) animations are barebones on web and desktop to make them feel more responsive, but results in them being more unnatural to use
there are actually two users of web tech, the "user" and the developer
pros
potential better feature parity
can reuse code across platforms
cons
slow (runtime & startup)
because of abstraction layer
lacking/unpolished features
because dev needs to deal with limitations of environment (eg. processing, graphics)
unexpected user interface behaviour
dev's needs to reimplement many things themselves, as that is by design of the web
thus, best practices like accessibility labels, user feedback, and layout structuring, may suffer
ram chowing
related to speed, because the runtime for web tech needs to be complicated for web tech to perform well
pros
cheaper to develop for
less developers needed to develop for multiple platforms, 1 team for all platforms vs 1 team for 1 platform
there are more web developers in the world, as it is accessible with a low skill floor
cons
you have to write platform code anyways
every platform does things differently, and libraries that abstract them out may not be up to par or available at all
legacy code for not-so-legacy platforms
because web tech has to support as much as they can, old API's that were designed without current time language creature comforts may have syntax that sucks, or documentation that sucks
archi/platform/version/environment bugs
a dev will only need to target bugs that appear in their current environment version, which makes everything more deterministic
similar to bundling a fixed version of electron, but you would only need to declare the version you're using instead of packaging it together, leveraging the environment's binaries
make the environment a web browser, instead of having a web browser on top of the environment
more precisely: a standardized platform independent wrapper for native platform API's, wrapped in a web technology-esque toolchain
having it built in an env lets it be fixed versions instead of a rolling spec, implementing semver for specificity targets
runtime can be built & cached on install similar to android's ART
with defined versions, it sets expectations for users as well, and makes it clear when something they want to use require an update
something similar is done for C++, VCRedist
the larger size footprint can be swallowed by an operating system but not necessarily a browser that has to be downloaded
handle versioning differences:
if a person has an older patch version, display warning icon
if a person has an older minor version, display warning dialog
if a person has a older major version, refuse to run
web tech-esque toolchain enables easy migration & adoption
will compile down to machine code
better performance, solves biggest compromise of current solutions
using something like AssemblyScript & HTML that resembles react native's JSX & CSS
will ease adoption
will bring over the web's already solid design
ease porting over of existing ecosystem, especially dependencies written in typescript
cons:
uses web technology directly
known for slow start-up times, & especially slow with big lists, large datasets
pros:
is a "wrapper" for native versions of APIs
easy adoption, familiar
react is popular, with many codebases already in it, and interop between web code & react native code better than any other solution (not perfect at all though)
cons:
uses tech stack foreign to web devs, more common among OS/app devs which might not be familiar with front end
pros:
is a "wrapper" for native versions of APIs
compiles down to machine code using C++
eg. word
eg. definition
runtime
the software you write is the driver, and the runtime is the steering wheel. it helps facilitate the features of an application
abstraction
they're like middlemen that hide working details of one or multiple functions
environment
it is the car that contains the driver and the steering wheel. like a room with tools provided which the software take advantage of, similar to the concept of an "escape room".
user interface
the visual part of a contraption, like a button to start an engine
feature parity
like how similar of a skillset does a group of employees have, in software it would be how similarly would the features be
platform
if the environment is the car, the platform is the road it's running on; a hardware system that contains an operating system
library
a collection of software robots and tools
legacy
old software that is left for compatibility, but won't be removed in the foreseeable future
API
"Application Programming Interface" — like the dashboard of a car or bus that enables the driver to interact with a contraption, either their own or someone else's
syntax
like grammar for a language
deterministic
the result of a task is predictable and able to be determined consistently
fixed version
like a version of an object which once owned, will not be repaired or changed by the manufacturer, eg. a shelf, some food, commodities
binary
a type of file that contains a large list of instructions for the computer
wrapper
another type of middleman that attempts to be an adapter for the driver and the car, like hand throttles for the handicapped
native
software that is designed to run on a certain platform, eg. a driver that is trained to drive on concrete, driving a car on concrete
toolchain
a collection of tools that enables the driver to drive, eg. your mom, that made your arms and legs
rolling release
the opposite of fixed versioning, like a house, which landlords will repair when broken instead of giving tenants a whole new house
semantic versioning
a specification of version labelling that requires version numbers with the format of "MAJOR.MINOR.PATCH"
cache
information that is temporarily stored, typically after being processed. like writing down a grocery list as you remember them throughout the week, instead of trying to compute what you need when you reach the store
operating system
a part of the "platform". OS is the pavement, while hardware is the earth.
patch version
version for backwards compatible fixes, will not confuse the driver. eg. a fixing a crooked start button in a car dashboard
minor version
version for added functionality in a backwards compatible manner, will not confuse the driver. eg. adding a new button but not changing the layout of the other buttons
major version
version for incompatible API changes, will confuse the driver unless its taught/rewritten to understand what is going on. eg. making the steering wheel square
migration
like a driver changing cars, relearning how things work, transferring the driver's knowledge from one car to another, etc
compile
an action for creating an executable program from code written in human readable format, like the transformation of a mother and fathers' DNA into the driver
machine code
the raw instructions that tell a computer what to do, like the raw fuel going into the engine
porting
the action of adapting software from one environment to another, like you teaching the driver a new car
dependency
a piece of software that another piece of software depends on, like a Proton car that uses a Mitsubishi engine
list
a visual representation of a list of items. eg. your contacts list, your insta feed, etc
dataset
a collection of data, like food for drivers
codebase
a collection of source code, like a team of drivers
interoperability
the ability of a piece of software to share or exchange a set of formats; the ability of a driver to to talk to or ask from another driver.
front end
the layer of software that bridges the human to the contraption, eg. dashboard of a car
business logic
logic that deals with data, such as managing databases, or instantiating user interfaces; the brain of the driver
instantiate
create a new instance of a predefined software object, like the driver fully remembering a plan to overtake his enemy's car, and then executing the plan
A big, f*cking plan.
I wrote down everything I wanted to talk about — case studies, POV's, related technologies, proposals, a 35-word glossary, and more. It detailed basically everything I had a problem with, and how they could all be solved. It was a magical 1833-word document. Then with the content out of the way, I went ahead and rewrote most of the parts, sticking with the same style of writing, depending on additional metaphors to explain my intentions. After 10 iterations, I had a "good enough" intro that I was well satisfied with. It still featured the optimizations to be as clear as possible, reflecting what the passage would say, but at a clarity level I thought was pretty squeaky.
*squeaky clear, but you get my point (taken from SpongeBob Squarepants, Season 5, Episode 97b)
Unfortunately,
I had a big problem.
It was boring.
Around the 8th iteration of v2, I noticed how the dependence on metaphors, meant that most of the essay would be filled with things unrelated to the topic anyways. This caused the experienced people to be bored by all the unnecessary fluff, and the general folk to be confused with the jargon. Then adding insult to injury, the metaphors would end up messy and uncorrelated at the end, as it was hard to convey information entertainingly, educationally, and consistently, in 2 sentences or less.
It was then which I had an idea, why not just make the whole f*cking essay a story? In my tests, I tried to make it as exotic as possible, using wild and epic language to transform the boring topic of the essay into a Disney-esque villain arc. It was weird to write at first, as I don't read much of fiction, or much in general, but I sort of got the hang of it as I went. If you're reading this, it already proves the second refactor worked wonders in improving the experience for both sides of the audience. I mean, why else would you be reading another big fat essay if you didn't enjoy the first one?
Now, one thing I didn't mention above was that I had some of the body written while at the tail end of developing v2 (2.8-2.10 contained body drafts), but the bump to v3 meant that those would need to go. I started v3 body development by continuing its intro's points — setting up the environment, the protagonist, his motivations, as well as some not-so-subtle foreshadowing.
Talking about not-so-subtle foreshadowing, remember how I wrote out the massive outline detailing what I wanted to say? Yeah f*ck that. Quickly into writing the essay, I realised that I could no longer go with the original narrative, as trying to detail out the nuanced way the proposal I wanted would work, was pretty challenging using only one character and one villain. I wasn't too eager to switch out everything though, so I tried my best to simplify it all and decimate everything that wasn't needed. Even writing the pros and cons became testimonies to the technical side of storytelling, as the difficulty of having to map each base feature to each character attribute, did numbers on my feeble brain.
me (taken from SpongeBob Squarepants, Season 3, Episode 48b)
Then, waltzing in, came the real cog stopper. Mid-way through the essay I already knew I wanted to do a three-act system, with act one being the setup, act two being the build-up, and act three being the climax. Unfortunately, I could not for the hell of me find a climax (xd). More precisely, I could not find a parallel I could use to map over my proposal. "Find the different type of curse" was all that I could come up with, and that would still not be able to explain what type of curse and why that type of curse invalidated my arguments against curses.
In my pursuit of finding resources and references to help with the block, I remembered about this little app framework called "Flutter". Well, all I can say that, the foreshadowing for this is definitely less obvious. Before wondering about Flutter, I did already have doubts as to the "native" approach having the same customizability that apps demand. Flutter came into the picture and solved that problem, as how it worked was to utilize close-to-native APIs and draw its own shapes, building UI from scratch. It also uses a programming language called "Dart", which is also said to be simple to pick up and run with. I didn't know if I should've felt stoked though. This seemed like the true ideal solution, but it was also a solution that already existed, meaning I had to definitely scratch some parts of what I wanted to write about. Adding salt to the wound, was the (still currently active) issues I found with the framework, where people were describing breaking problems on certain platforms that made it impractical to use it in real production.
Screenshot of the many issues related to crippling animation jank
So it was here where I made the decision to shift most of the boat. I'd come to accept that, there won't be a perfect solution, and all in all, it just had to come down to choice.
I now had a complete arc — loving web technology's simplicity & fast development turnaround, then said technologies struggling to keep up with feature-rich & demanding apps, then ending with a moral to make the correct choice and not give in to temptation, always.
That's it right?
I finished the essay?
F*ck you.
Firstly, the tooltips. There was R&D that went into that b*tch. Google Sites is pretty restrictive in what you can and cannot do, and one of the things you can't do is hover over inline text to get a tooltip. Now, the only thing on Google Sites that creates a tooltip when hovered, is the button. So, what should happen when you click on the button? What about the people who can't hover (eg. mobile users)?
First of all, sorry to mobile users, as the way Google Site's layout system is built, prevents me from putting the button tooltips on the side without destroying mobile's layout. I can't say I didn't attempt to have compatibility, as I made a simple API that displays the text I tell it to through the URL, to enable you to click on it instead of hovering. In the end though, daddy Google just made too much of a fuss on the page for it to be viably used outside of desktop, which sucks.
Second of all, the margin above and below the tooltips were nightmares. I initially used blanked images as the spacing, but about 1/4 the way through, I noticed that images would shrink and grow as you resized a page, messing everything up if any person had a different sized screen as the one I was editing on. I then moved on to using textboxes filled with new-lines. This made things a lot more tedious to resize, as the editor's output would always be slightly different than the final site's. After a lot of button spams though, I did eventually get everything to "close-enough".
How the nightmare works in Google Sites.
Other than that, you might've also noticed I only used plebeian GIFs and screenshots for this essay, and that's simply because the 3D shenanigans were a pain in all of the asses it created in me.
I started by figuring out a solution to what I could do instead of pictures. I thought 3D models would be simple enough, I just had to download some and place them in the correct spots, right? Well, that was me assuming there was a 3D viewer online that I could just yank. Fortunately, there was! Unfortunately, it was more akin to yanking a steak from a bear, a bear stole the steak from Chuck Norris (hehe pun).
Screenshot of code I had to mangle together in a few hours
If you'd just excuse the horrible code and non-existent linting/formatting, you'd notice that I was using "Babylon.js". It's a library I've known about and been wanting to learn for some time now, and oh boy do I regret not doing it sooner (because I'd know to not to). Its documentation is fishy at best, and literally broken at worst. It mixes "PascalCase" and "camelCase" for some reason, and writes like it was made by the mummies (yes that's an empty callback in an async function). I had to randomly invert the Z-axis for lights for them to be positioned correctly as well. Why? I have as little clue, as MH370 has, survivors.
Oh ho ho ho, it's not done there. It's time for Blender. There's an export plugin made for Blender that enables unidirectional export to Babylon.js, but issues arise when you recognize how different both their underlying architectures are. Fortunately, Blender had (relatively) recently (properly) implemented PBR materials, a type of shader/texture system originally developed by Disney for use in their internal software, that has become standard across the industry. Unfortunately, there were still more exporter settings adding to the learning curve, as well as the requirement for an older version of Blender (2.83, first released 9 months ago) for the exporter to work properly. Then, after I successfully got a scene to export, thanks to bad documentation, not everything loaded into the 3D viewer. It turned out that the code in the examples "viewer.loadModel(...)", only loaded the mesh, while "BABYLON.SceneLoader.AppendAsync(...)", would then only load the whole scene. ALSO, exporting would sometimes (all the time) fail outright due to empty nodes in Blender, generated when importing a downloaded model's material into Blender, forcing me to go through everything, relinking or deleting nodes until the error went away.
Screenshot of my favourite scene, because it was the only one didn't cause me any problems
All in all, I hope the irony of me struggling with getting something heavy onto the web using web technology, for... you know... an essay all about not doing that, is at least entertaining.
Screenshot of the result of Chrome's GPU process gloriously crashing. (Note the sad box guy on the top left of the viewer)
Finally, yes. Everything's published and ready to rock. If you somehow hadn't read the essay I've been referring to, here is the link to it accompanied by my deep judgement. So, what have I learnt by writing something like that?
It's hard to understand what you want, but it'll help out the result a lot once you do
It's okay to pivot when a piece of work is pulling itself to that direction
Don't over-extend too much when making preparations, especially in projects with tight deadlines
Consider THREE.js instead (another 3D library for the web)
And thus, with that said, thank you to whoever you are, for reading this clusterf*ck of a write up detailing what went into the other clusterf*ck of an essay.
// archive
final String[] tasks = this.work()[2]().tasks;
Chapter[] chapters = new ChapterFactory(tasks).createMany(5);
write a designer personal statement
find a topic that i'm interested in
write an intro
write the rest
write this
Who am I? Why do I design? The act of writing a design statement didn't seem too difficult on the surface, I know myself the best after all. Everything started to click in place though, as the situation sunk in. The truth is, this wasn't the first time I struggled with self introductions. I went through that process when I needed to create an "About" page for my "Intro to Creative Media" class, then realizing that was the hardest part of writing a site. The fact that the next task on the list would be to write something I liked, told me things were going to be a hell of a doozy.
I sat down and started to think, why do I actually design? (I literally just sat down and thought, which is why I don't really have many fancy materials to show here xd) Here's my thought process, recalled:
Well, I don't only like things to look good
I want things to be satisfying I guess
Why the f*ck
So how do I design?
...
I try to walk to the edge of the ring of "done and accepted", then walk back from there until there's a balance of appeal & "my mom would hate that"
I sometimes definitely put in way too much effort to walk to places that no one has been to tho
they're places like the world's 17th highest mountain, no one cares if i climbed it, but i'd still have to literally scale a mountain
The fun things I do are definitely more spontaneous than planned out, now that I think about it
Wait, but then I plan out the sh*t I do after I decide I want to do the sh*t
This is sounding more and more like a study of chaos theory
When I design something, the result has a response
Now, is that chaos?
What's the determined?
Yooooooo
And after that train(wreck) of thought, I came up with a quick draft, summarizing some of the thoughts:
Design to me, feels like playing with the box you're supposed to think in. Hit it hard enough and you'll get a concussion, but maybe a satisfying final product as well at the end. As things go though, the questions of, "what tools to bash with", "which parts are the most vulnerable", and "why am I hitting a box", inevitably come up. One question after the next, and I often end up with things that I shouldn't have cared about enough to pursue, like convex hull algorithms just to create a picture grid next to some text written in the style of a forest fire. Thus, I guess all that just means I like design, for the chaos that it causes.
(Find the final version here)
With that out of the way, I could focus on the next task, which was —
Find a topic that I'm interested in.
Well sh*t. I don't have anything to talk about regarding what I like to do. What am I going to do? Drop an audiobook because I like music production? (F*ck that's actually a good f*cking idea) What I did have though, was an ol-reliable strategy of writing about things that has caused me pain. I mean, it's genius, with failure you remember more details of the situation, and for longer. So, I present to you, my list of pain:
online classes
the inconsistencies of Android
corruption in school managements
some metal health bs
the limitations of web tech
Oh and also, I present to you my list of why pain is invalid:
This is already super talked about, with a lot of conversation. It's also kinda boring too xd
I didn't think I could do something unbiased, because I haven't used iOS for as long compared to Android.
This is kinda political, and uh, writing about something that you're depending on doesn't seem like too great of an idea xd
I've already written quite about this before hand, so I was kinda burnt out by it at that point (ironic xdd)
okay yeah that's fresh, why tf not
A little backstory on why that topic came up in the first place. I had been working on a program called "Auto Intro" The idea came from a parody video I made some time ago that gained some traction, about a program that could create "intros" basically only using one button and zero braincells. At the time, I didn't know how to code, which meant the program would stay fiction, until development of it became practical. That time came after I finished my first full fat website, in which I used a library called "lottie", that enabled After Effects animations to be exported into code and displayed on Web, Android, iOS, etc. Before that, I had only poked around with lottie for Android, which was hell to get working properly (because I didn't know much about the Android dev workflow at the time), but I managed to get the web version working pretty easily, and even built a mini animation library around it (have I mentioned how cool that website is). The eureka moment came when I pieced together the fact that I was fluent in TypeScript (a superset of JavaScript), and the fact that the files that lottie used were JSON files (literally standing for JavaScript Object Notation). A match made in heaven? A match made in hell?
By the time I started on this assignment, I'd been developing this program on and off for months now, and had to do a bunch of R&D to get around limitations of the browser. Speed and especially memory usage ended up being way worse for the simple rendering that it had to do, as well as things like needing to introduce otherwise unneeded encoding processes because the hacky solution used to turn canvas frames into video. At the core it was a surprisingly simple program — only really consisting of a UI, a de/compiler for lottie files, an editor for lottie files, and a template generator — but it ballooned in complexity due to the lacking client environment, as well as the lacking developer environment (I had to do extra R&D to develop a solution for working code linting).
All that basically bubbled into my want for a middle ground, something that would solve the client-side problems, as well as my stupid developer ones. That idea of a golden unicorn solution came to be, something with these criteria:
running natively on the clients computer
maintained by large entities
have the simplicity of the web
Writing it all down into words was pretty challenging. Initially, the audience for what I wrote was still unclear. I thought I was writing to a "me". This prompted me to put in words, what I thought was going to catch my attention. Unfortunately though, this made it unclear to everyone else what I was talking; a context-less approach.
<!-- insert intro v0.1 here -->
Thus, this v0 was short lived, as I knew I had to pivot.
I started out my refactor with a plan.
<!-- insert plan here -->
I wrote down everything I wanted to talk about — case studies, POV's, related technologies, proposals, a 35 word glossary, and more. It detailed basically everything I had a problem with, and how they could all be solved. It was a magical 1833 word document. Then with the content out of the way I went ahead and rewrote most of the parts, sticking with the same style of writing, depending on additional metaphors to explain my intentions. After 10 iterations, I had a "good enough" intro that I was well satisfied with. It still featured the optimizations to be as clear as possible, reflecting what the passage would say, but at a clarity level I thought was pretty squeaky.
Unfortunately,
I had a big problem.
It was boring.
Around the 8th iteration of v2, I noticed how the dependence of metaphors, meant that most of the essay would be filled with things unrelated to the topic anyways. This caused the experienced people to be bored by all the unnecessary fluff, and the general folk to be confused with the jargon. Then adding insult to injury, the metaphors would end up messy and uncorrelated at the end, as it was hard to convey information entertainingly, educationally, and consistently, in 2 sentences or less.
It was then which I had an idea, why not just make the whole f*cking essay a story? In my tests, I tried to make it as exotic as possible, using wild and epic language to transform the boring topic of the essay into a disney-esque villain arc. It was weird to write at first, as I don't read much of fiction, or much in general, but I sort of got the hang of it as I went. If you're reading this, it already proves the second refactor worked wonders in improving the experience for both sides of the audience. I mean, why else would you be reading another big fat essay if you didn't enjoy the first one?