This content originally appeared on daverupert.com and was authored by daverupert.com
I’ve been thinking a lot about limitations. Nearly all the rabbit holes I travel down end up with the same theme: “Limitations exist and we need to understand them and work within them”. This of course that got me thinking about the limitations we do and don’t put around building websites.
A motor on a computer chip
I watched a video where Carl Bugeja is prototyping a PCB motor. A PCB motor the size of a quarter seems… ahem… revolutionary when it comes to creating small movable parts. Carl is up against a lot of physical limitations in this quest to blend mechanical and electrical engineering; namely temperature. If the temperature goes to high, the device melts and fails and that is bad for the success of his invention.
An open world game on an iPad
The team at ustwo Games encountered a lot of limitations when building the 3D open world game Alba: A Wildlife Adventure. Some were Unity’s technical limitations in regards to occlusion culling, but a large part were hardware limitations because the game needed to run on an iPad Mini 4 per a launch exclusive deal with Apple Arcade.
I love their prototyping process and how they were able to generate topography through simple geometry and share it across a team. As the game got bigger, the limitation wasn’t generating enough game content, the major limitation was a 30fps framerate. They weren’t hitting the goal and spent a lot of effort and cleverness to engineer their way out of the problem. They used a suite of 7 different profiling tools to analyze, audit, and debug the performance of their game.
They don’t regret evolving into an open world game, but had they considered that a bit more from the start, some design choices might have been different.
A 4MB Gameboy game
I’m making a Gameboy game with my son. The Gameboy device has all kinds of limitations and here’s a short list that surface in GB Studio.
- Max game size:
4096 KB- the size of the Perfect Dark game cartridge. - Min character sprite size:
16pxx16px - Four character sprite colors: #071821, #86c06c, #e0f8cf, #65ff00
- Four background colors: #071821, #306850, #86c06c, #e0f8cf
- Min background size:
160pxx144px - Max background height/width:
2040px - Max background pixels:
1,048,320 - Max background tiles per scene:
192 - Max soundfile length: 3.64s in 8-bit mono
- Max scene assets: 20
- Max scene triggers: 30
- Max scene sprite tiles: 96
In GB Studio there’s a little counter in each scene for your assets, triggers, and sprites. The tooling helps me abide in the limitations of the platform. Learning about these limitations of Gameboy development first hand makes Miyamoto’s 1999 GDS talk and the emphasis he puts on designers understanding the hardware all the more relevant:
I have at last come to the conclusion that the role of a game designer is to design a complete game system by first comprehending the technologies that will enable and realize that system. I believe that one of the jobs of the designer is design itself. How will the ideas that I have in my mind be reproduced by the computer? How can the power of the CPU be best allotted in order for the computer to convey those ideas to the user? How can I bring my own constructions and expression of ideas together with the technology that creates that new level of enjoyment within the hardware and budget limitations placed upon me. This is what I mean by design.
I assume back in the heyday of Gameboy development, you didn’t have a warning meter in your graphical dev tooling. Instead, you had to build intuition about potential performance issues before designing and coding yourself into a corner.
A 4MB website?
Learning about all these limitations over the span of a week got me thinking about limitations on the Web. We never speak about websites through the lens of CPU, RAM, power consumption, thermals, or FPS limitations even though those are real limitations our websites can encounter. Anyone with a phone in low-power mode feels these limitations viscerally.
We sometimes speak of performance as a limitation, but that concept goes over like a lead balloon. Core Web Vitals exists but so does suspicion of Google being the ones prescribing the metrics1. A lot of tu quoque defensiveness like “This one Google product site fails Lighthouse” or “Google’s ad tech is slow and bad, thus my site doesn’t have to be fast” or the ever-present “I work on apps, not websites”. I think it’s ultimately a “you can’t tell me what to do” bias and the fact that people don’t react well when you criticize what makes them feel powerful (read: how they make money).
Accessibility should be a limitation, but we all know how often we skirt that responsibility. A silver-tongued devil’s advocate loves to question “Do blind people even need to…” as a method of swaying the room. Universal Access —a core tenant of the web— only becomes a priority through persistent internal activism or an external lawsuit. It’s rare to see that limitation enshrined at the beginning of a project.
Notably, my website authoring tools don’t tell me if I’m doing a good job on performance or accessibility unless I do a mountain of work to configure them to yell at me2. No bells ring, no counters count, and big problems don’t surface until they’re deployed to real humans. It would be great if the tooling served us better, but in the specific case of accessibility tooling, there’s a mismatch in the limitations of what a computer can do compared to what a body can do. There’s no “pit of success” and we ignore the data available and bail on the concept of human dignity when it becomes the slightest bit inconvenient.
Thinking more about limitations, I realized that when we do talk about limitations, we often talk solely about platform limitations. “HTML can’t do this” (e.g. <tabs>), or “CSS can’t do that” (e.g. :stuck-block-start, :overflowing-x), or “JavaScript doesn’t do my weird fetish” (e.g. type annotations). And so we layer on complex libraries, widgets, build processes, polyfilled features, and custom DSL syntaxes to make those dreams a reality. We award valor and fame for inventing more abstractions. Were I to guess, trying to break the gravity of platform limitations doesn’t help with the physics-based limitations like batteries and electrons. We assume all computers (PCs, laptops, phones, tablets) get replugged into the wall at some point so who cares about energy consumption if I get what I want.
There’s magic in embracing limitations. Entire branches of decision trees fall away. As much as I love complaining about browsers pushing the web platform forward, I bet the job looks very different if I’m not constantly trying to workaround or “fix” unbroken parts of the platform and instead tried to abide in the limitations.
This content originally appeared on daverupert.com and was authored by daverupert.com
daverupert.com | Sciencx (2023-03-15T20:06:00+00:00) Limitations and websites. Retrieved from https://www.scien.cx/2023/03/15/limitations-and-websites/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.