Architectural Digest: Why do we need to compress our design language?
The tête-à-tête of the colours? The camaraderie of the space with shapes? The sublime user interaction? Or is it something more enigmatic? A particular something. Unnamable, but not inexplicable.
Cut to bandwidth. (Yes. Bandwidth, from the previous episode of this series, batting the streaks.)
Bandwidth and computation have a complex relationship. In the vast majority of apps we use today, its trade-off is obvious. Zoom is where we do our job, while TikTok and Instagram are where we get our enjoyment. Just a decade ago, the concept of video conferencing for two-way communication was unheard of. Courtesy, bandwidth limitations.
Video conferencing involves the computation of data at both ends. If you will recall our last lesson, this means that bandwidth is shared between upload and download. Video is compressed and decompressed at both ends by most software programmes.
Digital video is an example of generic data compression that pays little regard to information content. Regardless of the content of the video, data compression on video is always in use.
One more time for the people in the back? Step one, the source compresses the video to reduce its size. Step two, the source uploads it, transmits it, and it reaches your phone. Step three, the same application decompresses the video. Et voilà, you can now view Emily in Paris in full resolution (but should you? Hmmm.).
That programmes utilise your phone’s computational power for this exercise, is great. Why? If they did not, you would have to pay an exorbitant amount of money for mobile data.
How exactly does this work? Have you ever had a private conversation on a group chat, where your communication centred on a story that only you and one other person knows? In that instance of recognition, which occurs on both ends, you do not remember the story word for word. It comes back to you in expressions.
Similarly, if both the transmitter and receiver have the same body of language for their signals or bits, they can convey repeated sections of a bit as a single one. Once that unitary bit is received, it unfurls into the original amount, and très voilà — Emily is back in action (aïe mon dieu).
To sum it up, having an efficient body of information on which both the transmitter and receiver agree is critical for data compression.
This, is why TikTok is famous. No, it does not have as much to do with the “Renegade” dance moves as one would think.
It has more to do with the fact that while Instagram allows videos to be streamed at 4G speeds, TikTok, perhaps the finest video compression thingamajig in the world, has been delivering content at 2G bandwidth.
How does TikTok do it? It works behind the layers of the internet.
Each layer merely processes data to and from the levels to which it is connected. Each layer, does not have to “know” or deal with the complicated variables handled by the other layers. When we launch TikTok, the application layer offers the primary interface via internet protocols such as HTTP. When we play a video, the transport layer relays information from the online database and presents it to the application layer.
TikTok, in particular, transmits requests to its backend over the internet. This is the mechanism that facilitates the app’s mobile functioning. The backend makes a request to its database. The database scours its deepest corners to fetch what is being “searched.” Once located, it is transmitted to the backend and onto the phone’s interface.
All of this — before you can blink!
This calls for curiosity about the use of signals in our language of design. The likes of AutoCAD have limited our knowledge of design to dimensions. But a design is more than that.
Cut to 1977, the year Christopher Alexander published A Pattern Language.
Alexander, an architect and design theorist, coined the phrase “quality without a name” (QWAN). He also started a movement to help those at the grassroots build meaningful architecture. His doctrine, A Pattern Language: Towns, Buildings, Construction, marks the beginning of that movement. The book was one of the first attempts to codify the diverse and abstract design language of architecture.
Alexander proposed starting with essential building blocks that were modifiable. Programming languages that are built on objects rather than actions, embody this philosophy.
Programmers, developers, and designers were using Alexander’s insights to arrange their work. Meanwhile, the physical world was turning digital, one page at a time.
It would still be a decade before computer scientists Kent Beck and Ward Cunningham would think of utilising design patterns in programming. But as a result of their presentation at the Object-Oriented Programming Systems, Languages & Applications (OOPSLA) conference in 1986, a new area of programming began to take shape.
Cut back to today, professionals are still finding new ways to use his innovative insights. If each pattern can be compressed into one bit, we might be able to arrive at software that can replicate the whole process of designing through the computing power available in a mobile phone. From the design of an entire city, down to every last detail in the bedroom — all on your phone.
The question is, do we agree on the many one-bit pieces supplied by the Pattern Language. For that matter, will we agree on the one-bit pieces of IKEA to facilitate our design language?
IKEA’s research and design lab, SPACE10, published a paper titled The Digital in Architecture: Then, Now, and the Future. The paper examines how digital technologies for design and production have contributed to the built environment today.
It follows the timeline of parametric building design. From the late 19th century to the present, the focus is on design methods. As a result of the breadth of the article, the visualisation unfolds into an immersive, poster-sized design that encourages close inspection.
If we are to move forward, we must reach an agreement. If we wish to exchange shared information across restricted bandwidth, we will need to develop more and more ways. It will not only save us money on logistics, but it will also save us time by making the design process more scientific, standardised, and acceptable.
At OOPSLA ’96, Alexander put forth the programmers the same questions that puzzle architects. ‘Build a better ecosystem with your actions. Then, ask yourself: Does the thing you are building make sense?’
‘People have asked me what kind of a process was involved in creating the architectural pattern language? One of the things we looked for was a profound impact on human life. We were able to judge patterns, and tried to judge them, according to the extent that when present in the environment we were confident that they really do make people more whole in themselves.’ — Architect and design theorist, Christopher Alexander
About the Writer
Sana Paul is an undergraduate architecture student and writer at the Jamia Millia Islamia, Delhi, hailing from the cozy streets of Punjab. She has experience working at the India Lost and Found (ILF) by Amit Pasricha, and Rethinking The Future (RTF).
About the Editor
Nishtha Singh is an editor, writer and researcher in the fields of Philosophy of Language, Ethics and Artificial Intelligence (AI). She has trained as an editor at the Seagull School of Publishing, Calcutta and is a graduate of the Department of Philosophy, and the Hansraj College, University of Delhi (DU), India.
About the Illustrator
Diksha Garg is an undergraduate architecture student at the School of Planning and Architecture Bhopal, hailing from Chandigarh. She is an illustrator, graphic designer and writer. She has received a citation for G-Sen Trophy and a Juror’s Choice Award for Journalism Trophy by the National Association of Students of Architecture (NASA), India.
