Naming the outputs of our design research: Cloud of Cards, a home cloud kit

PKELLER-018517_framed

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.

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)

04_IMG_5105_web

 

B) I&IC’s OwnCloud Core Processing Library (evolution)

iiclouds_005

 

C) A Personal Cloud (evolution)

owniicloud_04

D) My Data Controllers (evolution, models)

02_IMG_5119_web

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:

 

00_shaker_pegs

Towards applied object design and interaction

As we are now well into the second phase of Inhabiting & interfacing the Cloud(s), our aim is to materialize and verify our research. The intent is to work from two complementary perspectives: object design and interaction design. Lea Pereyre, object designer, and myself Lucien Langton, interaction designer and both assistants on the design research I&IC, will work on some parts of the physical hardware of the cloud as well as on it’s functions and usages.

Doing so, we are pursuing by design means the Learnings from the “I&IC design research wrap-up of sketches, towards artifacts” and “blabla”.

If the cloud as a medium has not yet been colonized by designers, expect of course in the applied case of user experience and interaction design practices, it is perhaps because it takes the place of a “blind spot” in our lives as front-end users. As soon as we make a gesture towards it’s nature it seems to vanish in a blur.

A first step in enabling designers to grasp the concept seems indeed to setup an enumeration of the building blocks composing the cloud. After all, it is a system of systems, optimized to perform certain tasks: upload, download, synchronize, share, compute, stream, and perhaps more. Many of them on third party hardware. The term “Cloud” is only a packaging for such terms, therefore it seems evident to investigate the possibility of a plurality of objects in order to create a relevant design for the somehow blurry term.

Moreover, the most flagrant incarnation of the cloud resides in it’s physical infrastructure. Colossal amounts of servers, electricity and cables are necessary to maintain this invisible yet crucial part of our contemporary society. This ecosystem built for machines to host and compute data is filled of objects, engineered in the never-ending quest for optimization: hubs, ventilators, connectors, etc. The most recognizable and useful object of this data paraphernalia is the 19″ server-rack. It is therefore natural to identify the server-rack as an obvious subject of product design in this research, especially also because it was “unblackboxed” almost at the beginning of this research.

 

The 19″ Server Rack and the “U” unit: object design

Historically, the invention of the 19″ server rack is a mystery. It was first standardized by Bell Telephone Company (later  AT&T), but was probably introduced beforehand in the railway infrastructure. Anyhow, it has always been an object dependent of the technology it supports in it’s evolution. This strange object has constantly evolved through the quest for performance optimization in electronics but it was until recently never questioned in it’s mobility aspects, let alone in itself as a designed object. The cloud’s physical infrastructure is a hostile environment for humans, even though it is meant to provide end-users with an abundant set of resources.

This hostile hardware is defined by a peculiarly standardized characteristic:
- The unit U  is specifically used to standardize server-rack heights and inner vertical spacings. One U is equivalent to 4.445 cm, or 1.75 inches.

This unit is of specific interest for our research as a formal constraint in object design. Other standards of interest were already introduced and documented in a previous post here.

It is necessary to acknowledge that these standards are maintained in order to keep in place a technological (and therefore economic) compatibility and interoperability within the infrastructure. It is difficult for non-technical users to gain access to the hardware necessary to setup their own infrastructure, precisely because the technical aspects aren’t communicated to encourage public use. This is why we need to re-appropriate these standards as designers with an open-source approach in mind. The first step towards this re-appropriation is to get familiar with the technical aspects of server-rack.

Considering the personal cloud as a paradigm serves primarily the need for users to store their “memory” (storage is by far the most popular function of the personal cloud), it is crucial to notice that by externalizing our “memory” to the cloud we have actually  displaced it to distant data centers. In this regard, re-appropriation is also a way to become conscious of this phenomenon.

Two references (out of the datacenter field) were identified as interesting design tracks according to our research questions (didn’t we wonder in this document about inhabitable shelter/data center in the chapter “What is the most appropriate approach?”)

The first reference, then, is Living Structures, Ken Isaacs, 1974, in which the author investigates our daily domestic micro-environments and synthesizes modular counter-proposals under the form of an open-source manual. The second comes from Shaker furniture, in which the aim was to design a universe of objects which all share a common function: to optimize the surroundings in order to liberate space for spirituality.

 

ken isaacs chair

shaker-chair-pegs

Ken Isaacs, Super chair (top) and Shaker chairs (bottom).

 

The Functions: interaction design

As users, we often use the cloud without even knowing it. The reason for this is that the cloud is a system engineered to assure a constant access to data and other users regardless of their position on the planet. This goal to access everything whenever and from everywhere relies on key functions which are kept hidden (“blackboxed”) in the user’s experience. Therefore, our clouds, phones, computers and connected devices constantly upload, download, synchronize, compute, stream and share data in the background.

The closest way in which these functions exist for the users are in the form of buttons, icons & notifications in the user’s interface. We can see these actions are always triggered by the same user interactions: click, tap, swipe down to sync, scroll down to load more data (in essence download), etc. On one hand the user has an extremely restrained contact with these actions, but on the other hand an ever-increasing universe of connected objects embodies the granular appliances of these actions.

These connected objects, often referenced to as the “Internet of Things”, decline cloud functions under every form. These remain nevertheless opaque to the user’s eyes, which is once again a flagrant proof of the vacuous engagement in the design process to produce these objects.

Connected devices of the internet of things are often the only ambassadors of the cloud under tangible form. However, one cannot help to notice their aesthetic and interactive aspects are often disappointing. Indeed, these objects are only designed with the purpose to add market value to a technology, but very rarely does it question or reduce the system’s technical opacity. We believe designers have a strong responsibility in this.

 

iot

Iotlist entered as a search term in Google images gives a quick glimpse of the trend in connected object design.

 

Designing a family of connected objects seems like a good lead at this stage, because it resolves several conceptual problems. First of all, it enables to kickstart a debate on the bundled nature of cloud functions. Dissecting the cloud into a list of functions is already a first step towards the establishment of an honest familiarity with the concept. In the second place, we need to give the cloud a body. One of the major difficulty with cloud computing is it’s invisibility. By embodying these functions we give place to commentary on each one of them.

Finally, objects are interesting in their different sizes and physicality. What would happen if instead of launching an upload with a click, it would be launched by temperature, location or proximity? What would happen if the object could be transported in a pocket? Or on the inverse, would be too heavy to move but very fragile? These are the tracks we are digging and interrogating at this stage in the research, enabling us to envision a personal family of objects related to the cloud.

Oracle, Bastien Girshig & Martin Hertig’s workshop #3 project at Milan Furniture Fair 2016

Glad to see that Oracle, the project that Bastien Girshig and Martin Hertig made in the context of the workshop organized with Matthew Plummer-Fernandez, will be exhibited during next Milan Furniture Fair.

The project will be part of a group show entitled Poetry, organized by Logotel Italy and curated by Sefano Maffei.

Faced with the complexity of modern art, the design world tends to seek certainty and comfort. Producing, as a result, reassuring uniformities and unvarying expectations. Landscapes, environments, behaviours, democratic and functional objects that feed desire yet fail to surprise and often leave us cold.
They lack the transgressive energy of a détournement.
Or a stroke of originality bringing with it the power of poetry.

Curatorial statement.

 

More about this exhibition on www.designpoetry.it

 

I&IC Workshop #3 with Algopop at ECAL: output > “Botcaves” / Networked Data Objects

Note: the post I&IC Workshop #3 with Algopop at ECAL, brief: “Botcaves” presents the objectives and brief for this workshop.

 

The third workshop we ran in the frame of I&IC with our guest researcher Matthew Plummer-Fernandez (Goldsmiths University) and the 2nd & 3rd year students (Ba) in Media & Interaction Design (ECAL) ended last Friday with interesting results. The workshop focused on small situated computing technologies that could collect, aggregate and/or “manipulate” data in automated ways (bots) and which would certainly need to heavily rely on cloud technologies due to their low storage and computing capacities. So to say “networked data objects” that will soon become very common, thanks to cheap new small computing devices (i.e. Raspberry Pis for diy applications) or sensors (i.e. Arduino, etc.) The title of the workshop was “Botcave”, which objective was explained by Matthew in a previous post.

 

Botcaves – a workshop with Matthew Plummer-Fernandez at ECAL on Vimeo.

 

The choice of this context of work was defined accordingly to our overall research objective, even though we knew that it wouldn’t address directly the “cloud computing” apparatus — something we learned to be a difficult approach during the second workshop –, but that it would nonetheless question its interfaces and the way we experience the whole service. Especially the evolution of this apparatus through new types of everyday interactions and data generation.

 

_MG_7469_m

Matthew Plummer-Fernandez (#Algopop) during the final presentation at the end of the research workshop.

 

Through this workshop, Matthew and the students definitely raised the following points and questions (details about the projects are below):

Small situated technologies that will soon spread everywhere will become heavy users of cloud based computing and data storage, as they have low storage and computing capacities. While they might just use and manipulate existing data (like some of the workshop projects — i.e. #Good vs. #Evil or Moody Printer) they will altogether and mainly also contribute to produce extra large additional quantities of them (i.e. Robinson Miner). Yet, the amount of meaningful data to be “pushed” and “treated” in the cloud remains a big question mark, as there will be (too) huge amounts of such data –Lucien will probably post something later about this subject: “fog computing“–, this might end up with the need for interdisciplinary teams to rethink cloud architectures.

Stored data are becoming “alive” or significant only when “manipulated”. It can be done by “analog users” of course, but in general it is now rather operated by rules and algorithms of different sorts (in the frame of this workshop: automated bots). Are these rules “situated” as well and possibly context aware (context intelligent) –i.e. Robinson Miner? Or are they somehow more abstract and located anywhere in the cloud? Both?

These “Networked Data Objects” (and soon “Network Data Everything”) will contribute to “babelize” users interactions and interfaces in all directions, paving the way for new types of combinations and experiences (creolization processes) — i.e. The Beast, The Like Hotline, Simon Coins, The Wifi Cracker could be considered as starting phases of such processes–.  Cloud interfaces and computing will then become everyday “things” and when at “house”, new domestic objects with which we’ll have totally different interactions (this last point must still be discussed though as domesticity might not exist anymore according to Space Caviar).

 

Moody Printer – (Alexia Léchot, Benjamin Botros)

_MG_7581_m

Moody Printer remains a basic conceptual proposal at this stage, where a hacked printer, connected to a Raspberry Pi that stays hidden (it would be located inside the printer), has access to weather information. Similarly to human beings, its “mood” can be affected by such inputs following some basic rules (good – bad, hot – cold, sunny – cloudy -rainy, etc.) The automated process then search for Google images according to its defined “mood” (direct link between “mood”, weather conditions and exhaustive list of words) and then autonomously start to print them.

A different kind of printer combined with weather monitoring.

 

The Beast – (Nicolas Nahornyj)

_MG_7454_m

_MG_7617_m

Top: Nicolas Nahornyj is presenting his project to the assembly. Bottom: the laptop and “the beast”.

The Beast is a device that asks to be fed with money at random times… It is your new laptop companion. To calm it down for a while, you must insert a coin in the slot provided for that purpose. If you don’t comply, not only will it continue to ask for money in a more frequent basis, but it will also randomly pick up an image that lie around on your hard drive, post it on a popular social network (i.e. Facebook, Pinterest, etc.) and then erase this image on your local disk. Slowly, The Beast will remove all images from your hard drive and post them online…

A different kind of slot machine combined with private files stealing.

 

Robinson – (Anne-Sophie Bazard, Jonas Lacôte, Pierre-Xavier Puissant)

_MG_7464_m

_MG_7507_m

Top: Pierre-Xavier Puissant is looking at the autonomous “minecrafting” of his bot. Bottom: the proposed bot container that take on the idea of cubic construction. It could be placed in your garden, in one of your room, then in your fridge, etc.

Robinson automates the procedural construction of MineCraft environments. To do so, the bot uses local weather information that is monitored by a weather sensor located inside the cubic box, attached to a Raspberry Pi located within the box as well. This sensor is looking for changes in temperature, humidity, etc. that then serve to change the building blocks and rules of constructions inside MineCraft (put your cube inside your fridge and it will start to build icy blocks, put it in a wet environment and it will construct with grass, etc.)

A different kind of thermometer combined with a construction game.

Note: Matthew Plummer-Fernandez also produced two (auto)MineCraft bots during the week of workshop. The first one is building environment according to fluctuations in the course of different market indexes while the second one is trying to build “shapes” to escape this first envirnment. These two bots are downloadable from the Github repository that was realized during the workshop.

 

#Good vs. #Evil – (Maxime Castelli)

_MG_7481_m

_MG_7619_m

Top: a transformed car racing game. Bottom: a race is going on between two Twitter hashtags, materialized by two cars.

#Good vs. #Evil is a quite straightforward project. It is also a hack of an existing two racing cars game. Yet in this case, the bot is counting iterations of two hashtags on Twitter: #Good and #Evil. At each new iteration of one or the other word, the device gives an electric input to its associated car. The result is a slow and perpetual race car between “good” and “evil” through their online hashtags iterations.

A different kind of data visualization combined with racing cars.

 

The “Like” Hotline – (Mylène Dreyer, Caroline Buttet, Guillaume Cerdeira)

_MG_7496_m

_MG_7604_m

Top: Caroline Buttet and Mylène Dreyer are explaining their project. The screen of the laptop, which is a Facebook account is beamed on the left outer part of the image. Bottom: Caroline Buttet is using a hacked phone to “like” pages.

The “Like” Hotline is proposing to hack a regular phone and install a hotline bot on it. Connected to its online Facebook account that follows a few personalities and the posts they are making, the bot ask questions to the interlocutor which can then be answered by using the keypad on the phone. After navigating through a few choices, the bot hotline help you like a post on the social network.

A different kind of hotline combined with a social network.

 

Simoncoin – (Romain Cazier)

_MG_7533_m

_MG_7568_m

Top: Romain Cazier introducing its “coin” project. Bottom: the device combines an old “Simon” memory game with the production of digital coins.

Simoncoin was unfortunately not functional at the end of the week of workshop but was thought out in force details that would be too long to explain in this short presentation. Yet the main idea was to use the game logic of the famous Simon says to generate coins. In a parallel approach to the one of the Bitcoins that are harder and harder to mill, Simoncoins are also more and more difficult to generate due to the inner game logic: each time a level is achieved by a user on the physical installation, a coin is generated and made available to him in the cloud (so as a tweet that says a coin has been generated). The main difference being that it is not the power of the machine that matters, but its user’s ability.

Another different kind of money combined with a game.

 

The Wifi Oracle - (Bastien Girshig, Martin Hertig)

_MG_7548_m

_MG_7586_m

_MG_7598_m

Top: Bastien Girshig and Martin Hertig (left of Matthew Plummer-Fernandez) presenting. Middle and Bottom: the wifi password cracker slowly diplays the letters of the wifi password.

The Wifi Oracle is an object that you can independently leave in a space. It furtively looks a little bit like a clock, but it won’t display time. Instead, it will look for available wifi networks in the area and start try to crack their protected password (Bastien and Martin found online a ready made process for that). Installed on the Raspberry Pi inside the Oracle,  the bot will test all possible combinations and it will take the necessary time do do so. Once the device will have found the working password, it will use its round display to display it within the space it has been left in. Letter by letter and in a slow manner as well.

A different kind of cookoo clock combined with a password cracker.

 

Acknowledgments:

Lots of thanks to Matthew Plummer-Fernandez for its involvement and great workshop direction; Lucien Langton for its involvment, technical digging into Raspberry Pis, pictures and documentation; Nicolas Nova and Charles Chalas (from HEAD) so as Christophe Guignard, Christian Babski and Alain Bellet for taking part or helping during the final presentation. A special thanks to the students from ECAL involved in the project and the energy they’ve put into it: Anne-Sophie Bazard, Benjamin Botros, Maxime Castelli, Romain Cazier, Guillaume Cerdeira, Mylène Dreyer, Bastien Girshig, Martin Hertig, Jonas Lacôte, Alexia Léchot, Nicolas Nahornyj, Pierre-Xavier Puissant.

 

_MG_7558_m

From left to right: Bastien Girshig, Martin Hertig (The Wifi Cracker project), Nicolas Nova, Matthew Plummer-Fernandez (#Algopop), a “mystery girl”, Christian Babski (in the background), Patrick Keller, Sebastian Vargas, Pierre Xavier-Puissant (Robinson Miner), Alain Bellet and Lucien Langton (taking the pictures…) during the final presentation on Friday.