“A Personal Cloud”: a home cloud kit for personal data (centers) / “reappropriate your dataself”!

We’re entering the final straight of the research project Inhabiting and Interfacing the Cloud(s) and we can give at this point a first glimpse of the four design artifacts we are working on at the moment. They will constitute the main outcomes of our joint experimental effort (ECAL, HEAD, EPFL-ECAL Lab) and a kind of “personal cloud kit” (explained below). These creations will be accompanied by two books: one will present the results of the ethnographic research about “the cloud”, the other will present the design research process and its results – both in pod/pdf.

We already pointed out in the recent post “Updated Design Scenario” where we were heading. Since then, the different projects were better identified and started to get shaped. Some got eliminated. Prototyping and further technical tests are running in parallel at the moment.

 

IMG_1239ct

From the original “final scenario” sketch to …

iiclouds_006

… a “Personal Cloud Kit”, composed of various physical and digital modular artifacts.

 

What emerged reinforced from the main design scenario is that we seek to deliver four artifacts (some physical, some digital, some combined) which themselves will constitute the building blocks of what we’ll call “A Personal Cloud Kit”. All four parts of this kit will be openly accessible on a dedicated website (e.g. in a similar way to what OpenDesk is doing).

The purpose of this “home kit” is to empower designers, makers and citizens at large who would be interested to start develop their own cloud projects, manage or interact with their data or even to set up small scale personal data centers at their places (homes, offices, garages …)

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),

 

IMG_1239ct

IMG_1244ct

 

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

 

IMG_1644ct

 

… 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.

 

I&IC design research wrap-up of sketches, towards artifacts

Following Nicolas Nova’s wrap-up regarding the ethnographic research about Cloud Computing which came to an end last April (publication to come) in the frame of Inhabiting and Interfacing the Cloud(s) (I&IC) and learning from it, it is also time for me to write a midterm status report about the design aspects of this ongoing work. It is the occasion to resume what we’ve been through along the process and highlight the most important elements.

 

founding_doc

“No-Stop City” (A. Branzi, 1969) used as an illustration in the founding document of the I&IC design research.
Image retrieved from the post “I&IC Preliminary Intentions” (05.09.2014).

 

We are therefore trying to put in evidence in this article what we’ve learned so far during the process and where this might lead us as design strategies during the last year of this design study. This while knowing that our plans are to produce design artifacts and functional prototypes as results of this research process — among other ones (books, tools, etc.)

Cookbook > Setting up your personal Linux & OwnCloud server

Note: would you like to install your personal open source cloud infrastructure, maintain it, manage your data by yourself and possibly develop artifacts upon it, like we needed to do in the frame of this project? If the answer is yes, then here comes below the step by step recipe on how to do it. The proposed software for Cloud-like operations, ownCloud, has been chosen among different ones. We explained our (interdisciplinary) choice in this post, commented here. It is an open source system with a wide community of developers (but no designers yet).

We plan to publish later some additional Processing libraries — in connection with this open source software — that will follow one of our research project’s objectives to help gain access to (cloud based) tools.

Would you then also like to “hide” your server in a traditional 19″ Cabinet (in your everyday physical or networked vicinity)? Here is a post that details this operation and what to possibly “learn” from it –”lessons” that will become useful when it will come to possible cabinet alternatives–.

Setting up our own (small size) personal cloud infrastructure. Part #3, reverse engineer the “black box”

 

At a very small scale and all things considered, a computer “cabinet” that hosts cloud servers and services is a very small data center and is in fact quite similar to large ones for its key components… (to anticipate the comments: we understand that these large ones are of course much more complex, more edgy and hard to “control”, more technical, etc., but again, not so fundamentally different from a conceptual point of view).

 

SONY DSC

Documenting the black box… (or un-blackboxing it?)

 

You can definitely find similar concepts that are “scalable” between the very small – personal – and the extra large. Therefore the aim of this post, following two previous ones about software (part #1) –with a technical comment here– and hardware (part #2), is to continue document and “reverse engineer” the set up of our own (small size) cloud computing infrastructure and of what we consider as basic key “conceptual” elements of this infrastructure. The ones that we’ll possibly want to reassess and reassemble in a different way or question later during the I&IC research.

However, note that a meaningful difference between the big and the small data center would be that a small one could sit in your own house or small office, or physically find its place within an everyday situation (becoming some piece of mobile furniture? else?) and be administrated by yourself (becoming personal). Besides the fact that our infrastructure offers server-side computing capacities (therefore different than a Networked Attached Storage), this is also a reason why we’ve picked up this type of infrastructure and configuration to work with, instead of a third party API (i.e. Dropbox, Google Drive, etc.) with which we wouldn’t have access to the hardware parts. This system architecture could then possibly be “indefinitely” scaled up by getting connected to  similar distant personal clouds in a highly decentralized architecture –like i.e. ownCloud seems now to allow, with its “server to server” sharing capabilities–.

See also the two mentioned related posts:

Setting up our own (small size) personal cloud infrastructure. Part #1, components

Setting up our own (small size) personal cloud infrastructure. Part #2, components