Photography by Daniela & Tonatiuh.
Design by Léa Pereyre, Lucien Langton and Patrick Keller
Cloud of Cards. Early pictures from the final artifacts, a photo shoot with Daniela & Tonatiuh
Naming the outputs of our design research: Cloud of Cards, a home cloud kit
Cloud of Cards, a personal cloud kit. Scattered 19″ hybrid server racks, elements and kit to assemble and play with. (Photo.: Daniela & Tonatiuh)
We’re coming close to an end with the joint design research Inhabiting and Interfacing the Clouds and we’re becoming impatient to deliver the results: a diy small scale data center and cloud kit made of various elements (both physical and digital), to freely assemble at home or in your “garage”. Accompanied by two books documenting our work in print-on-demand!
At this stage though, we’ve given new and final titles to the design artifacts and tools that we’ve been working on lately, together with the research team (for the design & code part: Lucien Langton, Léa Pereyre, Christian Babski and myself).
Therefore…
Cloud of Cards, is a home cloud kit to help re-appropriate your data self. Obviously a distant tribute to House of Cards, the toy project by the Eames (“Toys and games are preludes to serious ideas”), the kit will consist of four artifacts:
19″ Living Rack is an open source server rack with a few functional hybridations, declined in four versions. Cloud of Cards Processing Library consists in a programming tool to help develop cloud applications with the Processing development language. 5 Folders Cloud is a version of the Cloud (ownCloud) with automated behaviors and cascades of events. It is an implementation of the processing library directly linked to the outputs and learnings of the ethnographic research about uses of the cloud. Finally, 5 Connected Objects physically interface the five automated folders in our version the cloud (5 Folders Cloud) with five “smart” objects and try to embody distant data in some kind of everyday domestic presence.
I&IC’s public survey of 356 links related to “Clouds” on Pinboard – last updated 03.2017
…
Along the design research, we are going through many different types of references that we don’t necessarily post or document on the blog. We usually only post about the ones that we consider relevant to the research process, which doesn’t mean the other ones are not interesting. We’ve just decided not to dig deeper into them at some point, or to keep some of them for later.
Yet, this is a consistent amount of survey that we are leaving on the side of the road and that could possibly be useful for similar or later researches. At least a good starting point… That’s why we’ve created this i&ic_designresearch tag on Pinboard.
Interestingly, some new thematics emerged along the way within these links, like for example on the technological branch, the combination of personal cloud based services, peer to peer protocols and blockchains that were not on the radar when we started our research.
A “Home Cloud Kit” (evolution)
Note: the purpose of a “Home Cloud Kit” (working title) has been described in a previous post. It will be composed by four artifacts which will become the main outcomes of the design research Inhabiting and Interfacing the Cloud(s), along with one book about the ethnographic field study and another one about the design research process.
Below are four links leading to four posts describing and analyzing the current state of evolution for each part of this kit. We expect the research and the “kit” to be finished by the end of March 17.
The “kit” will be distributed freely at the end of the project.
-
The final phase of our research consists in the prototyping of artifacts which relevance have been identified along the process. Tools, infrastructures and services are therefore addressed and will constitute a “Home Cloud Kit”.
This final phase is organized into the four following lines of work:
A) A Personal Data Center (evolution, models)
B) I&IC’s OwnCloud Core Processing Library (evolution)
C) A Personal Cloud (evolution)
D) My Data Controllers (evolution, models)
A Personal Data Center (evolution, models)
Note: “A Personal Data Center” (working title) is part of a home cloud kit, which was described in a previous post and that will be composed by four various artifacts, both physical and digital.
The kit will be distributed freely at the end of the project.
-
After a few design iterations through sketches and a bit of 3D modelling, we recently produced a set of first prototypes of what our domestic 19″ server rack could look like and how it could handle domestic functions as well. As a matter of facts, we can consider this work an alternative approach to what was set up and analyzed at the beginning of our research, when we assembled our own “(small size) personal cloud infrastructure“.
Our approach was fueled by several references, the first one being House of Cards, by Ray and Charles Eames :
The modular, simple and intuitive assembly process guided us for its adequacy within a Do-It-Yourself user context.
This part is critical and brings us to the second main reference which is an hybrid of contemporary startup culture (with a sustainable twist) and DIY local manufacturing processes. In this particular case, Opendesk appeared as an relevant example of this smart balance between design and accessibility (although you still need access to a industrial-scale CNC milling machine to “Do-It-Yourself”!
However it isn’t OpenDesk’s business model which got our attention as much as their aesthetics, with apparent hints of the fabrication process used and assumed in the object’s visual identity.
On this base we prototyped our first domestic 19″ rack and kept along the way a few core features. We also kept in mind the different contexts and functional modularity (technical base, office, home) we desired to address. We also took into account some “climatic” parameters that needed to be moderated or exploited within a domestic context (production of hot and dried air by the computer servers, mainly).
A 3d view and design iteration of the technical base for our server rack, as modeled following the constraints of CNC fabrication (image above). We chose to assemble elements following the simple “House of Cards” principle (below).
The assembly is solely based on a perpendicular “card” system, which is in turn held together by straps maintaining a regular tension between elements.
In order to avoid any metal parts, screws and folding (which usually make regular server racks heavy and expensive) we chose plywood, which also makes things easier to directly produce with a CNC mill, based on drawings. We also chose to go for straps to maintain the server cases in between the two main vertical sides of the rack, as this solution offers extreme modularity and reliable resistance (below).
This approach offers a totally modular approach as the racks’s sides are milled every “U” unit in height, enabling users to slide in any height of servers. Due to the shape of the rack, long and heavy servers will sit at the bottom of the rack while shorter ones will stand at its top.
Note that the servers cannot be secured (the server is open) as we supposed it is installed at home or inside a small office, mainly accessible by family members and friends.
Over the main “body” of the cabinet, a 1U slot has been designed to fit in a router or perhaps a firewall.
The back of the rack lets an easy access to cables as well as space for the heat to flow up. Overall this whole 19″ cabinet could be a simple structure enabling users to hack it to their convenience, perhaps adapting it to the different rooms they choose to set in in.
Indeed, setting the server rack as a standardized piece of networking hardware in the living space opens up to several possibilities of “co-existence” between the rack itself and it’s situation in the domestic space.
…
We’ll continue to work on the final models from now on, focusing on solving adaptability to different user contexts (basic technical needs combined with home and office situations. Exploitation of heat as well as air humidification and “cleaning”). We will also optimize the models for a minimum material loss during the milling process.
My Data Controllers (evolution, models)
Note: “My Data Controllers” (working title) is part of a home cloud kit, which was described in a previous post and that will be composed by four various artifacts, both physical and digital.
The kit will be distributed freely at the end of the project.
-
Continuing our design process, we milled the first prototypes of the five connected objects, which consist in tangible versions of the five main folders present in our alternative version of Owncloud (“A Personal Cloud”, working title as well).
As explained in this post, each object is based on the same elementary brick which brings and manages a natural interaction between the connected object, the personal cloud and its contained data, files and folders –therefore becoming a controller–. This elementary brick holds the Raspberry Pi, sensors and hardware necessary to physically interact with Owncloud. This interaction will be slow and discrete.
Furthermore than the identified objectives through the ethnographic field study and design sketches we’ve lead along the research, our approach to these networked objects was fueled by complementary meaningful references. The first one (image below) consisting in a different approach to the behavior users adopt in their interaction with the “technological home”, Shaker furniture:
Shaker furniture as well as their household objects were designed to be suspended to pegs in the living room, in order to make space for spiritual ceremonies. Interestingly, this design also suggests an active state for objects (i.e. when the chairs are oriented “naturally”), and a passive one when hooked, where their main function is somehow “paused”. This status resonates with connected objects and somehow questions their presence in the private sphere, where they’re usually always on, always gathering information, and always connected.
We also noticed that this could help connect cloud interactions to natural gestures connected to objects that can happen in a domestic environment, on a regular basis. Like opening or closing a door, switching a button, having an object that fall, roll or that you need to clean, maybe store in a special place like those chairs, etc. Connecting simple physical interaction with abstract digital behaviors could be both helpful and meaningful to help understand what is going on.
A second important reference is perhaps quite more practical, in the sense it concerns the objects assembly. As explained in the post about our Do-It-Yourself server cabinet, an important concern in our process is to define a simple and accessible assembly process for future users.
This bench by FOBricated needs no glue or screws, it is solely held by a ratchet strap.
The assembled five prototypes still need corrections and improvements, however they were extremely useful to reconsider each object’s assembly process which strongly influences their weight.
Below in the same alphabetic order as their related and connected folders appear in the standard interface of OwnCloud, pictures from the five data controllers (TO_ACCUMULATE, TO_CARE, TO_FREEZE, TO_IMPROVE and TO_MULTIPLY). These five folders will be automatically created in the “alternative version” of the cloud we are currently working on (“A Personal Cloud”), they carry specific interactive behaviors.
The reasons and relations between these five objects and their counterparts as folders and contained files in the cloud have been detailed in the previous post “A Personal Cloud: a home cloud kit for personal data (centers) / reappropriate your data self“.
Five cloud folders (above) embodied within the five following networked objects, acting as physical counterparts:
TO_ACCUMULATE
Interaction behavior: if or when the object falls, all the files that have been accumulated in the “TO_ACCUMULATE” folder over time will be deleted, literally “vanished”!
Rem.: the object still seems too massive here, perhaps the impression of its instability will be enhanced by making it a bit taller and thinner, like a stick.
TO_CARE
Interaction behavior: the top (missing in the above image) made of acrylic glass will attract dust with the help of a ionizer. It will need to be cleaned and taken care of regularly. This action will help take care of the files contained in the TO_CARE folder by creating backup of them. Yet without this natural interaction, the backups will be deleted and in the end, the last ones automatically moved into the TO_MULTIPLY folder, ready to become “neglected”!
Rem.: (here also without the top) the networked object still needs to be reconsidered to be easily suspended to TO_IMPROVE (below), while avoiding the present asymmetry in the assembly between the two main parts.
TO_FREEZE
Interaction behavior: the networked object that consist in the simple original “brick” needs to be maintained at low temperature and in the dark. It should be located in the fridge (!) and kept at low temperature. If this is achieved, the files and data contained in the TO_FREEZE folder will be automatically kept compressed (zipped).
From time to time, the brick’s battery will need to be recharged and moved out of the fridge… If it is left too long out of freezing temperatures, then its files will be unzipped, “melted”! And then moved into the “TO_ACCUMULATE” folder, ready to be deleted …
Rem.: the object consists only in the main elements that brings interaction to objects, the original “brick”. We’ll be rethinking the box’s assembly to orient it towards the same type of assembly described for our server cabinet.
TO_IMPROVE
Interaction behavior: the object physically holds the four other networked objects and serves as a hook rail. When these are deployed in the home space, the cloud is enhanced by additional functionalities provided by these objects and therefore “improved”. The files contained in the TO_IMPROVE folder are themselves subjects to unpredictable “improvements” and updates, only when these other four objects are deployed and according to their file types (images, sounds, texts files, etc.)
Rem.: the object, still lacking the pegs here, will be totally redesigned to be much lighter, as well as to set up a standard way of fixing it to a wall.
TO_MULTIPLY
Interaction behavior: no physical interaction in the case of this networked object but only visualization. All the files located in the TO_MULTIPLY folder will be automatically duplicated and spread over the entire network of Personal Clouds! The files deleted will be deleted everywhere in the same way, the volume of the containing folder “shrinked”!
Rem.: the object still too small here will become bigger, in order to accommodate a decent sized screen for visualizations as well as to differentiate it from other objects.
All the prototypes above are still at a quite early stage, however it seems we can easily start to conceive them as a family, with for each one of them either a suggested interaction or role in the domestic environment.
A Personal Cloud (evolution)
Note: “A Personal Cloud” (working title) is part of a home cloud kit, which was described in a previous post and that will be composed by four various artifacts, both physical and digital.
The kit will be distributed freely at the end of the project.
-
The “alternative version” of the cloud (client, interface) and the way we interact with it is still under development.
Strongly connected to the ethnographic field research that was achieved earlier during the research process regarding cloud usages, the purpose of this project is to exemplify a different way of handling or even playing with one’s data and files in the cloud, as well as to demonstrate an implementation of “I&IC’s OwnCLoud Core Processing Library” that will also be part of the final delivery “cloud kit”.
“A Personal Cloud” is also in tight connection with the objects controllers project, “My Data Controllers” (working title as well), because these networked objects will directly interact with the files and data contained in it.
A version of OwnCloud developed with the help of “I&IC’s OwnCloud Core Processing Library” and containing five root folders, each with a singular automated behavior.
As already stated in previous drawings, cloud usages scheme and overall scenario sketches, each of the five folders contained in “A Personal Cloud” will encapsulate and automate specific behaviors related to “cloud computing” (third party computation, distant data handling and file storage or management). Some cascade of events and file transfers might even happen.
As we can see, the focus as been set on the interaction rather than the visual interface. Especially as our research drove us in the direction of physical interaction, a line of work which became the project “My Data Controllers”.
The five folders cloud and its behavior:
TO_ACCUMULATE:
Corresponds to the regular storage function of the cloud, like to keep or to store files (“motivations”). Unless this folder is connected with its counterpart physical object from “My Data Controllers“, nothing particular happens to the contained files and the usual function of the cloud is not modified or improved.
If it is indeed connected, then all files could be suddenly deleted if a special action is taken, files and data could literally be “vanished!” (“problems”).
TO_CARE:
Matches user’s desire to protect its files in an automated way (“motivations”). Therefore to backup or to privatize: each file placed in this folder is automatically backuped and privatized.
If the folder is connected with its physical counterpart, its files could be un-backuped, “neglected!” and them moved into the TO_MULTIPLY folder (“problems”).
TO_FREEZE:
When a user wishes to keep a file or some data “forever”, he places it in this folder (“motivations”). It can be understood as to compress, to “zip” or to store files endlessly.
When linked to its physical interface and not paid attention to, files can be uncompressed, “melted!” and then move into the “TO_ACCUMULATE” folder, where they might then end deleted (“problems”).
TO_IMPROVE:
It is a more random and possibly surprising process. Files being placed in this folder will be almost arbitrarily transformed by algorithms according to their types (text, image, sound files).
TO_MULTIPLY:
Corresponds to the user’s desire to make copies of its own files on many other devices (to universalize) or to share them with others persons (“motivations”). Only in this case the process is pushed to its limit: all the files in this folder are being automatically shared with other users that are also federated to “A Personal Cloud”. Files deleted by a user somewhere will be deleted everywhere in the cloud and for all users (“problems”).
Next steps in development will be to further test the interaction and fine tune it without adding too much complexity to the system. We’re trying not to add another layer (like for example another client-server that would keep track of the status of this and that in the cloud), which might force us to drop some options.
