Recent Posts by Lucien Langton

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:



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


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.



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.

I&IC Workshop #5 with random International at ECAL: work in progress


Our workshop with Dev Joshi from rAndom International is going on well during the week, with different ideas cast into the direction of digital shadows, traces and footprints.

The students are encouraged to produce objects, although it has been suggested that they take advantage of space as well (installations), as the workshop takes place in a large studio (cinema studio at ECAL).

I&IC Workshop #5 at ECAL, tips: RaspberryPi’s and the GrovePi+

By Monday, November 16, 2015 Tags: 0120, ECAL, Hardware, Tools Permalink 0

If you are not familiar with the Raspberry Pi and remote access, a previous post was written here and here.


School’s specials:

Your RaspberryPi is preconfigured with an updated version of wheezy (2015.03.20_Dexter_Industries_wheezy.img) specifically designed to work with the GrovePi+.

If during the week you need to re-run updates just type in the following:

sudo apt-get update
sudo apt-get upgrade

Note also that you can access a few tutorials and “how to’s” on the same Dexter Industries website. “Get Started with the Grove Pi” and “Example Projects” have been already linked on our resources section out here.

However beware, the school network might not let you do this, you might have to choose another network for that (like your phone’s).


The easiest way to access your Pi is via VNC with an Ethernet connection. First you need to install VNC viewer for your mac. During the installation process just check install viewer, no need to install server.

Once done and your Raspberry booted, you should be able to VNC into it through Ethernet connection:

Note that :5901 indicates to connect to shared-screen number 1, if you configure other screens the number 2 would be :5902, and so on.

Once connected, to configure wifi go to wpa_gui on your desktop and configure the wifi network details (with your wifi-dongle plugged in ;).

Your RaspberryPi was configured for remote access, to ssh it via Ethernet (if it doesn’t work, unplug your wifi  dongle and plug it back in once done):
ssh pi@


Once connected you can check if you have an active connection:

If you don’t, you can check if you Raspberry Pi is at least scanning the right networks:
sudo wpa_cli scan && sleep 5 && wpa_cli scan_results

For more wifi troubleshooting follow this guide


To set screens, or kill them via the command line there are these commands:

sudo tightvncserver :1
sudo tightvncserver -kill :1

If for some reason you need to change the static IP set for ethernet connection, you can edit it via a simple card reader by editing the IP set in cmdline.txt situated in the root folder of your card. (if it doesn’t work, check if your computer has a dynamically allocated IP for ethernet connection, in this case we’ll check it out together)

As the week goes on I’ll update this post with new ressources. Enjoy!

Decentralization tools – links

By Thursday, April 2, 2015 Tags: 0103, ABCD, Links, Tools Permalink 0

A brief post on additional open-source services, software, hardware, community and art projects we stumbled upon during our ongoing research: (service) enables users to retrieve their Facebook data, anonymize it and sell it back for market value. We’re not sure it’s legit (there’s a security warning while loading the site). It however seems to be the same people behind another service of the sort: (community) is a community-powered free wireless network originating from Germany. (community) is an open, free and neutral telecommunication network built piece by piece (by literally deploying cables and antennas) by the community. The project originates from Spain. (service, community) is a free tool to build and host your website at home. The project seems ambitious as it combines self-hosting hardware standards with a custom-made WYSIWYG webpage builder and a template repository fed by users (all webpages built become open-source templates). (software) is a mobile messaging app for Windows and Android. It uses Bluetooth and the movement of crowds to spread data and suppresses the need for operators, a bit like the Firechat app. It however seems that the project has been abandoned in 2009.

Uncloud (software) is an application that enables anyone with a laptop to create an open wireless network and share information. Users can connect wirelessly while remaining disconnected from the internet.

GoTenna (hardware) is a product enabling users to text and share their location even when there is no telecom tower or satellite coverage.

AirChat (software, hardware) is a free, secure and open-source telecommunication network built by LulzLabs working a laptop and a hacked radio. (speculative design) is a free and secure communications network hypothetically built and maintained by the community.

Project Maelstrom Last but not least, Project Maelstrom is BitTorrent latest proposition to decentralize web hosting through the BitTorrent protocol – We cannot help to ask ourselves: Is it still decentralization if it’s owned by a company?

Project Fi While we’re in the corporate sphere: Google is apparently aiming to take over the front-end costumor away from telecom companies. Perhaps decentralization is becoming just another marketing argument for companies who actually want centralize (read: capitalize on) your data.

We will continue to add links as our research goes forward. In the meanwhile, you can find all the links mentioned in the research project on Delicious under the tag “i&ic_designresearch” (note: also mentioned in this previous post, “Public Survey on Delicious“, within the Resources category on this blog).


For additional and updated resources, a Github is maintained that lists tools:

Heating homes with Clouds – links


Using excess heat generated by data centers to warm homes isn’t a new idea. Earlier in our research we stumbled upon Qarnot, a french company proposing to decentralize the data center into meshed radiators to distribute computing resources across people’s homes (we’re guessing they took their name from Carnot’s Limit ;). They announced a partnership with the city of Paris to heat 350 low-income housings in 2013.

However, they are not the only rats in the race…

I&IC Workshop #4 with ALICE at EPFL-ECAL Lab: output > Distributed Data Territories

Note: the post I&IC Workshop #4 with ALICE at EPFL-ECAL Lab, brief: “Inhabiting the Cloud(s)” presents the objectives and brief for this workshop.


The week of workshop with ALICE finished with very interesting results and we took the opportunity to “beam” the students presentation to LIFT15, where Patrick Keller and Nicolas Nova were presenting the research project at the same time. The EPFL architecture laboratory already published a post about the workshop on their blog. The final proposals of the intense week of work were centered around the question of territoriality, and how to spread and distribute cloud/fog infrastructures. You can check out the original brief here and a previous post documenting the work in progress there.


Data territories – a workshop at EPFL-ECAL Lab with ALICE from design research on Vimeo.




The students Anne-Charlotte Astrup, Francesco Battaini, Tanguy Dyer and Delphine Passaquay presenting their final proposal on friday (06. 02) in the workshop room of the EPFL-ECAL Lab.



Proposing to make these infrastructures visible raised a flood of questions concerning their social and architectural status. Similarly, it questions several fields about the presence of private data in the public space. How do we represent the data center as a public utility? What types of narratives/usage scenarios emerge from such a proposition? By focusing on different but correlated territorial scales, participants were able to produce scenarios for each case.



The overall Inhabiting the Cloud(s) research sketches on the wall.


Swiss territoriality and scale(s)?

The three distinct territorial scales chosen were the following: the national/regional scale, the village/town or city, and the personal/common habitat scale. The proposals were established on the basis of an analysis of the locality where the workshop was held: the small city of Renens and its proximities. The research process focused on preexisting infrastructures which responded to several criteria necessary to implement server rack structures: access to regular and alternative power sources, access to cooling sources (water and air), preexisting cabled networks and/or main and stable access routes (in the mindset that the telegraph/telephone lines were setup along the train lines), and finally seismic stability as well as a certain security from other natural disasters.

Doing so, it also speculates about the fact that data centers could (should?) partly become public utilities.


Water, water mills?

The first proposition was to rehabilitate old water mills along existing rivers on the countryside leading to cities and villages in the role of “data sorting centers” or “data stream buffers” facilities. As there is no cabling this proposition may seem odd, however especially concerning Switzerland’s topography, the idea is interesting as it investigates several culturally rich aspects, not to mention the abundance of water. The analogy between water streams and network flows seems obvious, but water is also a necessary cooling source for data infrastructures. It could also be considered as a potential energy source. One could even go further and speculate on the potential interactions between the building and wildlife, as in the image used to cover this article published by Icon magazine just a few days ago.


8_IMG_5593_web 12_IMG_5453_web

Water Mills, water cooling scenarios and their local position on the map (around the city of Renens).


Disused post offices?

On the scale of the city, the preexisting infrastructure chosen was the Post Office. Postal services are still functioning, but the buildings are deserted of much of their social interaction with the public since the coming of age of internet access. The buildings are also identically structured on a national scale, which could facilitate implementation. They are strategically positioned and already well equipped with network standards. Moreover, it could revive the social role of the village square, or redefine the city as a radial organization around data (versus spirituality). Amongst the implementations discussed were the ability to use the excess heat to create a micro-climate over the square and the possibility of redefining the public space inside the post office as a Hackerspace and Makers Lab, a bit in the same way libraries function.


17_IMG_5461_web 18_IMG_5465_WEB

The “front” and “back ends” of most villages’ disused post offices offer quite interesting and appropriate spatial organization, if not metaphors.


Neighborhoods’ nuclear shelters (from the cold war period)?

On the scale of the office or housing building, the nuclear shelter was immediately proposed. In Switzerland, every home is to have a nuclear bomb shelter. This situation is unique in the world, and most obviously, better serves local metal groups and wine cellar enthusiasts then security. Nevertheless, however awkward this may seem, these shelters are almost a blueprint for a personal data center. Every one of them is equipped with high-end air filtering systems, generators for use in case of power outings, and solidity and stability standards set to resist a nuclear attack. This couldn’t become a model for the other countries though…


22_IMG_5514_web 23_IMG_5517_web


The building would therefore embed the capacity to develop it’s own thermal ecosystem alongside the usage of private, communal and public dataspaces.


26_IMG_5478_web 27_IMG_5470_web 29_IMG_5468_web


This last proposition is finally interesting as it would redefine the organization of the habitat as a radial one, a bit like the students-researchers suggested earlier above for the city. The building could therefore become a transition space in itself between public space, community space and private space. Different directions were also explored with a particular interest on the vernacular “chalet” as a possible candidate for an alpine “meshed data harvesting facilities” scenario.

For now, we’ll stick to the dream that one day, every family in Switzerland will be able to send their kids play in the data center downstairs. But remember: No Ovomaltine on the ethernet hub!





Many thanks to the ALICE team in general and to Prof. Dieter Dietz in particular, Thomas Favre-Bulle for leading the workshop, Caroline Dionne and Rudi Nieveen for organizing it. Thanks to Nicolas Henchoz for hosting us in the EPFL-ECAL Lab, Patrick Keller and Nicolas Nova for their introduction to the stakes of the overall project, Lucien Langton for its hard work, good advices and documentation along the week and last but not least to the students, Anne-Charlotte Astrup, Francesco Battaini, Tanguy Dyer and Delphine Passaquay for their great work and deep thinking proposals.

Recent Comments by Lucien Langton

    No comments by Lucien Langton yet.