From design research wrap-up to final artifacts, updated design scenario (in scribble mode, #2)


This post consists in an important update to the previous note “From design research wrap-up to final artifacts, a design scenario (in scribble mode, #1)“.

It’s main purpose is to narrow down the previously sketched scenario and become more precise about the possible artifacts we will develop. In doing so, the present description shows a likely path and tries to keep some coherence within the overall design that is segmented in four different areas, often combined (software, hardware furniture, responsive objects, visualization). Yet and even so several objects and functions are described and named in this post, it will continue to serve only as a general blueprint for the last phase of our I&IC joint design research, while the final outputs could still largely evolve, based on the same ideas and plan.


These ideas keep their importance though:

Based on the graphic “Motivations <-> Usages <-> Problems” and its description of procedures, based on our “Design Learnings” too, we’ve tried to translate and objectify these into “natural language” of actions (and problems). At this stage, this is still a trial, but we’ve listed five pairs of words that work in opposition (verbs vs. past participles) and that cover the spectrum of functions and procedures: To Care (vs. Neglected!), To Accumulate (vs. Vanished!), To Multiply (vs. Shrinked! ), To Freeze (vs. “Melted!”), To “Pimp” (vs. “Jumbled!”) — all these corresponding to a set of cloud actions and explained with more details below, after the break —

These 5 pairs of terms will drive the development of an alternative, domestic and hopefully objective Cloud (“Our Cloud”), built upon the open source software OwnCloud with the help of our own I&IC OwnCloud Core Processing Library (which will be further edited and editable therefore). This personal Cloud will have the opportunity to be hosted into a new type of diy (and domestic as well) 19″ Cabinet.

The 5 pairs of terms will further drive the implementation of 5 Controllers or Network Data/Bot Objects (“Smart Objects”). The aim of these “controllers” will be to give an everyday physical presence to each user’s personal Cloud, to its 5 main folders, contained files or data and the processes they undergo. The manipulation of some of these objects will include the idea of “natural interface” or “gestures”.

In addition to these 5 physical controllers, 1 or 2 “root objects” could help monitor and possibly moderate the overall behavior of “Our Cloud”.

For the development of these “smart objects”, we’ve decide to take into account the kind of objects or infrastructure that are already present in a domestic environment, things like single functional objects (i.e. lamps, electric plugs, consoles, mirrors, clocks, etc.) and revisit them with a slight sculptural approach. We’ve also decided to consider a “language” that takes into account “invisibility” or “immateriality” (i.e. electricity, electrostatics, magnets, light, reflections, air currents or temperature, dust).

Finally, all of the above should be distributed as open source.

Three summary drawings

Three drawings from the previous series of scenario that resume quite well what we intend to do:


An objectified cloud (a combination of open source software, automated behaviors and physical data controllers),





… that would find its physical location in a kind of retrofitted and open source 10″ cabinet,




… to let anyone create and manage its own “tiny” and personal/home data center, based on existing or newly created open source technology.

From design research wrap-up to final artifacts, a design scenario (in scribble mode, #1)


Based on the design guidelines drawn from the wrap-up (recently published on this blog) and following a logic of “branching” from the existing (forks, branches, hacks, versions, etc.), we’ve identified in collaboration with the research team four main design projects/artifacts to further investigate in the context of Inhabiting and Interfacing the Cloud(s), following the questions addressed by the research project.  These design artifacts are intended to become the major outputs from our joint research:


1° We will continue develop the open source tools, the related procedures and our OwnCloud Processing library, possibly developing a Javascript version of it as well. (Christian Babski)

2° By way of practical applications about these libraries, we will design and develop I&IC’s “branches” of OwnCloud (OwnCloud + scripts). They will favor alternative ways to operate and interact with the Cloud in direct link with the identified “motivations” to use this universal service. (Patrick Keller, Christian Babski)

3° A set of networked data objects (“controllers”, kind of…) will be developed directly in connection with the above “branches” of OwnCloud. In order to embody the usually hidden processes and data so as to trigger objective interactions with the personal cloud. (Lucien Langton)

4° We will retrofit the 19″ server cabinet built around the standard unit “U” with the purpose to create a domestic version, a kind of modular and highly decentralized “house/personal data center”. (Léa Pereyre)

In order to address the maker and designer communities, users will be able to openly access the blueprints, the parts, the files or the code of these elements (librairies, OwnCloud versions, “controllers”, 19″ Cabinet and develop or adapt their own versions from them).


I drew a series of scribbles lately to sustain our investigations towards this final design scenario. It will serve to frame the development range for our design artifacts (points 1° – 4° above and top slideshow). It is further explained with additional information and images below, after the break.



Virtualization, in computing, refers to the act of creating a virtual (rather than actual) version of something, including but not limited to a virtual computer hardware platform, operating system (OS), storage device, or computer network resources.

Virtualization began in 1960s mainframe computers as a method of logically dividing the mainframes’ resources for different applications. Since then, the meaning of the term has broadened.[1] 

… it continued and now this concept and technology is widely used to set up system architecture within data centers. Virtualized (data) servers populate physical servers. A well known company that is specialized around these questions is VMware.

I&IC Workshop #2 with James Auger at HEAD: Design Implications

Based on the concepts and scenarios produced in our second workshop, we decided to work on the design implications of such projects. More specifically, we realized the set of contexts (religion, music, etc.) the workshop participants worked on share common traits: the needs for a cloud infrastructure was fairly similar and let to the idea of a basic “data unit”. Such a mobile system would act as a mini-data center.


I&IC Workshop #2 with James Auger at HEAD, brief: “Cloudy”

At HEAD – Genève today, we started the first workshop of the research project with James Auger (from Auger-Loizeau design studio and the Royal College of Arts in London). We’re going to spend this week with the first year students of the Media Design MA exploring cloud computing, personal cloud systems, objects and user interfaces.

In order to address this, the workshop started with a background description of the project’s purposes, the evolution of computers and network infrastructures, as well as an introduction to the current state of design objects and architectures related to cloud Computing: NAS systems, servers combined with heater, speculative projects related to such technologies. From this broad list of material we wondered about the lack of artefacts that go beyond purely functionalists goals. Cloud computing systems, especially in the context of people’s context is generally a commodity… hence a need for design interventions to re-open this black box.

Following Eames’ quote “A plan for arranging elements to accomplish a particular purpose” (as a definition of design), we asked students to start with a basic activity: to create a map of “elements” related to cloud computing. They had to choose a domain of everyday life (cooking, communication, etc.), begin by compiling “their” elements (material scale, cultural, historical, list people’s motivations, objects used to achieve it, situations, behaviors, etc.), sub-themes.

From this we discussed this ecology of elements and what aspects or user contexts they could focus on. Interestingly, students chose very broad topics: religion, communication, cooking, art performances, animal-computer relationships or music-making.   Based on this map, we then asked students to explore the role of cloud computing into these elements by looking at these questions:

  • How elements of the diagram might work with the cloud? How the cloud may influence each of these elements/the relationships between two of these elements?
  • How relationships between the elements on these maps may evolve with cloud computing?
  • What are the new situations/problems that may arise with the cloud? Implications?
  • What kind of objects will be linked to the cloud? Why? (From products to the role of the product and situations that arise)

The (many) answers to these questions led the groups to highlighting design opportunities to be discussed tomorrow.