FutureRack PILL Project Thread

[chenoehart]

Here is a dedicated forum thread to document my research and design journey with the FutureRack Protocol Pill project.

First of all, a little introductory information about myself: My background is in architecture, I have some experience with electronics and computer programming, and I’ve written before about how emerging technologies relate to the built environment. You can see more of my work on my website. I participated in SoP last year with the Addressable Space project.

For an introduction to my PILL project this year, here’s its RFC proposal description for reference:

“The 19” rack format, first pioneered in 1922, is a ubiquitous protocol for mounting telecom, audio/visual and IT equipment. Devices of varied shapes and sizes fit within racks which may be mounted on walls or on wheels, carried in portable cases by musicians and soldiers, and organized in rows inside our data centers.

Advertisements from a fictional manufacturer of rack adapters will aim to amuse online IT and audio engineering communities by illustrating new construction techniques to utilize the racks within unexpected settings such as kitchens, gardens and retail displays, expanding the protocol’s imagined vocabulary of configurations.”

I’ll update this thread with additional sections for information about different aspects of the project, and compile within this first post in the thread a set of links to each of those future posts.

Post links:

1. Project backstory
2. Rack history & context
3. Design: 2D Dimensional Analysis
4. Content Brainstorming
5. Catalog Development

I’ll look forward to hearing your thoughts and comments!

[chenoehart]

Part 1: Project Backstory

As a first step on my journey with this project this summer, I am going to share some of the story behind its gradual development as an idea.

I see the idea as having had several phases in its past gestation:

1. I’m curious about data centers. As someone who has always been interested in electronics and who started building my own computers when I was in high school, I became curious when I noticed when I was in graduate architecture school around 2017/18 that there was a zeitgeist emerging in my field involving curiosity about data centers as an emerging building type. I wrote a paper on data centers in one of my seminar classes (which I learned enough from that I’d like to rewrite it and try to publish it somewhere), and in another class I did a series of drawings conceptually exploring the flow of air within data centers.

• Rough initial sketches and 3D models made during the class, where I was trying to make initial gestural drawings abstracting the airflow inside a computer/server:

(Since this was a drawing class, there was more of an emphasis on producing something visually and spatially interesting rather than necessarily documenting the technical details of the non-architectural aspects of my subject matter.)

• Expanding my drawing ideas to encompass a rack of servers …

• … and then a whole room of them:

(There’s a bit of a subplot going on with this project where I also have had a longstanding architectural interest in large aggregate quantities of objects/information, and in how that phenomenon manifests itself in physical space.)

• The final drawing I did in the class, attempting to simultaneously look at airflow within the server and within the large set of racks at the same time:

(Images from the U.C. Berkeley class “Drawing Air” taught by Mark Anderson.)

• That project encouraged me to think a little bit more about servers and server racks than I had before, in addition to the extent to which I had already been aware of their general form factors from reading articles about computer-related topics over the years.

2. Musical rack devices. Over the course of a few years of the 2010s I also started increasingly noticing that ideas for song lyrics would randomly appear in my head. When the COVID pandemic happened, I decided to spend some time trying to teach myself how to produce music. (Current status: I’ve finished songs and shown them to small groups of people.) As someone who also found old electronics intriguing, over the next few years I acquired a collection of music production devices, some of which are older than I am. It seemed kind of interesting to me that many of them were designed to fit into the same rack format as the servers.

A few of my synthesizers (and their MIDI controller on top) which I had nearby to photograph.

3. Technical standards as protocols. While I was participating in the 2023 Summer of Protocols program, I noticed that David Lang’s project on technical standards offered several useful relatively concrete reference points to help me refine my own definitions of what exactly a protocol is. I was also intrigued by his project’s references to the MIDI format developed as a standard for communication between music synthesizers as being an example of a protocol. One of his Town Hall slides showed some musical equipment (in the context of discussing the history of MIDI) in the same format as mine:
   

   

4. I build a rack. After the 2023 SoP program ended I decided to take a little bit of time to better organize my music setup, which included starting to build a rack to mount some of my devices on:

• I’m now faster at installing rack nuts into a frame than I was when I started building it. (And making mistakes while building it: ie. I know I installed the mixer and the Vortex device in the wrong screw holes on this rack, and some time I’m going to fix that…)

5. Rack configuration options. Before I started gaining firsthand experience with using the rack format, I also noticed something strange when I was initially shopping for my rack. There is a surprisingly wide variety of different options for racks available for sale.

• For example, you can get racks which extend in depth …

(Original product link.)

… swing open for easy access to cables …

… are designed to be mounted to a wall …

… fold up for storage/shipping …

… tilt for better ergonomics …

… or protect their internal mounted equipment with shock absorbers:

• In addition to the common settings where racks are found within data centers, IT closets, music studios and stages, I also found rack products that were marketed for use by the military …

… or in medical settings:

• There were also a wide range of adapters available to connect 19" racks together in different ways, and to connect them with other rack formats. For example, here’s some adapters for connecting to the less common 23” wide racks …

… and one for accommodating equipment extending outward beyond the front of a rack …

… and one for converting to the DIN rack standard:

• It almost looked like I had encountered a highly-adaptive protocol.

6. LEGO as an interchangeable protocol. On the SoP forum, Venkatesh Rao brought up LEGO as an example of a system which is flexible and adaptive enough to be a protocol rather than a platform. The 19” racks, I realized, might have a comparable range of adaptability, while also being used today in high-stakes as well as recreational applications. The relatively large dimensions of the rack system also intrigued me where they could be used to build structures operating on a larger spatial – ie. an architectural – scale. I liked the idea of translating some of my previous hobby-related experiences with computers and music production into a project that could also potentially contribute to my body of architectural work, and I decided to further explore the history and future possibilities of the racks as a protocolized system.

7. Misuse of existing protocols. As I thought about the range of different rack adapters fitting into a system of protocols, I wondered about how different rack components might be combined together (as with non-standard LEGO building techniques like those discussed in the SoP forum thread) in unofficial, contradictory ways. In the back of my mind I was reminded of the conceptual reference of a project the architects Diller/Scofidio did in which they ironed dress shirts in ways that made them no longer correspond to their intended use of accommodating the dimensions of a human body:

• You might say that they were distorting a normative protocol (the process of ironing / normal expectations of how clothing should appear) by doing it in a different order of steps, and then the outcome of that process transformation ended up producing an absurd result.

8. Non-standard racks. Similarly, I wonder how the rack systems could be misused by combining their components together in different non-standard ways. Given the rack’s spatial potential, I also am interested in placing it into a wider range of settings where it could come into interactions with other existing systems of dimensional standards. For example, how do the dimensions of the 19” rack line up with the general standard dimensions found among different sizes and configurations of household kitchen cabinets, or of the dimensional sizes used on plant pots sold in garden stores? My goal for this summer is to expand the possibilities of the rack protocol by looking for absurd ways that it could be integrated into our everyday lives.

So far, I’ve started my process by doing more background research into the history of the rack system, which will be one of the next installments in my process which I post here. I also am developing further outlines of my future project plans. I’m looking forward to seeing how this project develops next!

[chenoehart]

Rack History & Context
(To be further updated with additional information as I convert it into a forum post format.)

1. History
   
   I have been further researching the historical backstory on the origins of the racks as part of this project. Progress on that has been a little slower than expected since there isn’t a lot of information available at the surface level of what you immediately find from quick online sources; I’m finding more relevant references buried in older materials like old books and manuals.
   
   Some summaries of what I’ve found so far, and what I’m still looking into:

• I found a 1922 document from Bell Systems establishing their specifications for the 19" server rack format. (Internet Archive link.)
  It shows a record of how their equipment got consolidated over time onto increasingly organized and standardized racks.

• I need to look more into other rack standards which developed before/after/alongside the 19" rack, like the 23" rack standard.

• It looks like there may have been some parallel developments of rack systems for railroad signaling equipment alongside those of telecom equipment. I’ve seen speculation about that within blog posts + other kinds of online discussions which I need to verify.

• I’ve also found some primary sources describing railroad signaling equipment (at early as the turn of the century) being organized in racks (“relay rack” I’ve discovered is a commonly-used term). I’m wondering if that approach might have been a predecessor to the telecom rack model.
  
  

  
  

• I could also look into how telegraph equipment was mounted, prior to the arrival of more technologically advanced phone/radio-based communications equipment.
  (Source: “Richmond Terminal Interlocking” by C.J. Kelloway in Railway Signal Engineer Vol. 12, No. 1, January 1919. pg. 75-79)

2. Rack standards

• The 19” rack is also known as the EIA-310 standard. (EIA 310-D is the most recent widely recognized standard, and EIA/ECA-310-E looks to be a more recent standard developed after the consolidation of the EIA and ECA standards agencies.)

• There are also some parallel standards from other (ie. international) agencies, in the form of DIN 41494 and IEC 60297.

3. Related systems

• This research should involve considering the scales of objects smaller and larger than the racks, ie. like 1960s+ mainframe computers (with the conceptualization of their scaling organized in increments of modules at roughly similar size to a ~20-36U rack cabinet) or blade servers (organized as ~8-16 blade units within ~6-10U of rack space).
  
  
  
  
  (Blade server image source: Flickr use seeweb / Creative Commons.)
  
  The Computer History museum has a page with some links to images/advertisements of the IBM System/360 and its competitors which I’ve been referencing to look at how the mainframes were marketed.

[chenoehart]

2D Design Analysis

The first step in designing the fictional products used in my proposals for new rack configuration is an analysis of what existing places the rack’s dimensions allow it to fit into, and also what existing categories of objects it is capable of most efficiently storing. The studies are split accordingly into two series called “Installation Fit” examining how the rack fits into larger environments, and “Object Fit” examining how objects fit into the rack.

• Color-coding legend for the analysis:
  – Blue:19" rack hardware and annotation lines for dimensional clearances of the racks.
  – Purple: 23" racks and their dimensional clearances.
  – Red: Text/annotations indicating information about external non-rack objects and their dimensional clearances/parameters for test-fitting with the rack.
  
  
  You can click on the following drawings to view them at an enlarged size.

1. Installation Fits
   

• Kitchen Cabinets. The 19" rack fits far more efficiently into narrower standard sizes of kitchen cabinets compared with wider cabinet sizes. A kitchen designed to accommodate 19" racks would need to have its cabinet modules be artificially narrow in comparison to the sizes a designer would otherwise use to maximize efficiency. Upper cabinet modules (not shown) have the same sizes of widths as the lower cabinets being studied.
  

  
  
  
  The analysis resulted in a rough design sketch outlining some brackets to fit between the rack and the cabinet for installing the racks:
  
  
  
  
  
  The case of the 24" rack cabinet shows an example of a phenomenon I expect to continue seeing in the future: in situations where the rack fits somewhat awkwardly into an existing physical context, such as in this case where a physical gap occurs between the width of the rack and the cabinet it’s being mounted into, those disjunctions can investigated to see if they offer positive alternative design possibilities. In this case, I drew holes in my rough sketch of the side brackets connecting the rack to the cabinet with the idea that they might serve as openings for cable management (what electronic devices would someone even want to install in a rack under a kitchen cabinet?) in the future.
  
  

• Residential Closets
  

  
  
  This sketch is fairly basic so far. The closet width dimensions are rough generalizations given how closets in floor plans are often designed to encompass whatever width of available space is convenient to fill in their location.
  

• More scenarios to come…
  
  

2. Object Fits

• Dishes
  

  
  
  How different standard sizes of dishes would fit into the rack kitchen cabinet systems.

• Paper
  

  
  
  Standard sheets of 8.5x11 and 11x17 paper have a very tight fit into the rack. A proposed rackmount paper tray would have borders extending beyond the inner dimensions of the rack posts to allow for easy construction and usability.

• More scenarios to come…

[Timber]

This has me thinking of a different type of standards organization, like ISO. But rather than collecting a bunch of standards and cataloging them, it would be like gathering real world info to identify high-potential areas for standardization. Almost like an investment firm.

I feel like this is a pipe dream though. No solid revenue model for a private firm, maybe too entrepreneurial for a public sector bureaucracy. “Neither government nor market” - @davidtlang.

Anyway I’m kind of blown away by the thought process here. It’s like a really deep Venn diagramming exercise.

@celerae and @DButler curious if blueprints of waterfront infrastructure would be easy enough to parse for potential standardization hotspots… Or at least it could be another dimension for scoring different locations/adding to a rubric. Your project is interacting with the built environment more than the others in this cohort, thought I’d flag this in case it sparks anything

[chenoehart]

I like the idea of identifying new targets of standardization; seems like it would make sense in areas where the lack of standards is specifically causing problems, ie. like if different competing technical formats confuse consumers or create more overhead for businesses. I’ve been continuing to look in my research on the history of the racks for the moment where multiple organizations agreed on (or at least adopted) one standard.

[celerae]

Interesting. There are definitely elements of waterfront environments that are highly standardized. I mean, most obviously, containerization is a key example of this. It creates a very particular kind of waterfront context in most cities, because containers shape infrastructure of our cities in myriad ways. (There’s a ton of existing literature on this.) In terms of more relevant to our project examples, though, I’m sure there are many others. Standardized stuff is beloved by engineering, so of course it shapes the waterfront. Most agencies, local and federal, around the world that manage the shoreline of cities are lead by engineers. Given that, I feel quite sure we’ll see more waterfront infrastructure become standardized over time, even in the ecological space. To give a specific example that I’m very familiar with: My partner (life/romantic) is working on designing habitat modules that can be installed, pre-fab, on metal bulkheads that are used around the world on waterfronts. Unlike natural shorelines or wooden bulkhead, or even rip rap shores, these surfaces do not provide any habitat (they’re in fact designed that way on purpose, for longevity). Designing a habitat module that could be affixed to existing and new metal bulkheads (for which we have abundant engineering experience and infrastructure etc.) is about leveraging standardization to scale habitat in cities, rather than relying on wholly natural systems. It’s not an ideal solution from an overall ecology standpoint, but it’s definitely a step up from existing conditions. The corrugations in the bulkheads aren’t all exactly the same, and they get squished and stretched in order to adapt to the local environment (curves, depths, etc.), which causes some highly localized variability — but they’re close enough that he thinks pre-fab can work, so arguably the example applies well here.

I suspect that this is the kind of example that might be such a “hot spot” — standardization is common in a lot of construction and engineering applications, so I’m sure we’ll see some kinds of substrates or building blocks of both hard and soft shoreline infrastructure develop. Construction drawings might get you enough granularity to spot what these are.

[chenoehart]

Meant to reply to this sooner. That’s interesting to hear about the idea of adapting standardized modules to different local conditions; I’ve been definitely encountering an issue like that on my project at a smaller scale where I’m trying to fit standard modular components into different varying interior space conditions.

[chenoehart]

Content Brainstorming

I’ve been starting to think about planning backwards from this project’s final end products. I imagine I’ll do around six or so illustrations (conservative estimate) of different new ways of using the rack protocol, and I’ve started sketching out some ideas (not necessarily the final ones I’ll use) for what those images could be like.

I might end up, I am realizing, with three different potential categories of images:

• Technical – Relatively straightforward presentations of new rack hardware like adapters between different rack systems, or a catalog of all the variants of existing racks. This category could also include more straight-facesd presentations of new spatial uses for the racks, ie. like a diagram of a rack being used as a portable or space-saving storage space within a home which focuses on its practical features over its potential absurdity as a foreign object within the home. In either case, images would be shown from a relatively neutral point of view, ie. as simulated photos of fictional hardware and/or as axonometric/overhead perspective architectural drawings.
  
  Rough brainstorming sketches:
  

  
  • A kitchen based on rack geometry which didn’t end up looking that unconventional.
  • More to come… (Some of this content will also be more directly derived from some currently in-progress 3D models.)

• Humorous – Illustrating new uses of rack systems in the context of existing online meme cultures. ie. joking about a web server being used to store cat pictures, or there’s some recurring jokes within online synthesizer communities (which include the use of rack hardware) about people displaying succulents next to their synthesizers when playing them. I’ll keep my imagination open for more ideas of humorous references I can make. These will look like neutral product photo images with added inserted commentary.
  
  Rough brainstorming sketches:
  

  
  
  
  
  
  
  
  

• Contradictory Vignettes – Illustrations where the physical contradictions involved in installing racks in new locations are emphasized, without having to rely on appeals to external cultural memes to provide absurdity. I seem to be going through a pattern of particularly thinking about introducing plants and plant material into the racks (ie. like house plants, maybe with accompanying grow lights, or salad in a rack used as a salad bar), suggesting there could be some kind of underlying rhetoric of a nature vs. technology contrast involved. That’s a plausible direction, but I don’t want it to be my only one. These images could include both neutral backdrop/product photo-style content and also rendering where you’re immersed in the space of the new rack-based worlds.

  • Rough brainstorming sketches:
    
    
  • Rack-based shelves containing both household and non-household objects.
    
    
    
  • Rack units used to construct a restaurant salad bar. This was an especially spontaneous idea where there’s also cables being stored in an adjacent bay (an offhand brainstorm which makes no logical sense), but maybe the eventual illustration will contain some other more logical food equipment in that space.

Overall, I realize I should prioritize the meme-based & surreal content where I’d assume it has the potential to be particularly attention-getting, but I’ll try to do a mix of more technical content making more concrete spatial arguments alongside it. I’m planning to concurrently produce a batch of illustrations and then release them in stages during the last week of the month.

[chenoehart]

Catalog Development

Following last week’s researcher meeting, I’ve been reflecting and thinking about streamlining my plans for my final end product to really focus on the rack as a protocol and on its range of applications. I’m now thinking that my product at the end of this month, which I’m imagining as a catalog (stylized as being of the fictional FutureRack company’s “new products for 2024”), will show a larger number of simple and straightforward illustrations showcasing the range of rackmount products, with selected full-color mocked-up photos being retained to draw attention to particular products. That feels like a kind of visual hierarchy you already see within certain kinds of commercial and specialized catalogs, and it allows for an efficient work process where I can focus on describing either more technically-informative or more attention-getting “products” in the best ways to represent each type. IKEA instruction manuals have also come to mind for me as one source of inspiration, where they provide technical information to the general public in a way that’s accessible.

One reason for making a (partial) shift from absurdity to more straightforward technical descriptions: as I’ve been working more closely on the 3D design of the different rack systems, I’ve started to notice some moments where the introduction of the rack geometry doesn’t only complicate existing household objects/environments, but perhaps in fact also has the potential to improve them.

For instance, in this idea for a rack-based living room coffee table / side table, the customer would purchase a set of table legs, multiple rackmount plate covers to form the tabletop, and then a standard off-the-shelf rack rail* of varying lengths to determine how long they wanted their table to be. That means that the language of the rack system can easily scale to different sizes of tables, in an efficient way.

Similarly, I’m also tying that idea into this marketing text for the kitchen rack products; even in cases where the racks are relatively awkward or space-inefficient to introduce into a space, they could still provide advantages by being easier to reconfigure over time (or even more possible at all ie. if you’re a renter) compared with the alternative of remodeling. Some of my ideas which I started out thinking would primarily have value if I could turn them into absurd memes may be in some cases also practically useful.


*6U/8U/12U are more common standard rack rail sizes, but existing rails and rack products in 5U/7U/11U sizes are also available.

[chenoehart]

First draft of the my final document, imagined as a catalog of accessories to bring the rack format into your home:

FutureRack_Catalog.pdf