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.
…
A) We will continue to use the open-source platform OwnCloud as the main resource for our personal cloud prototypes (versions, branches, forks) and as stated, we will further develop the I&IC libraries (Processing, Javascript) for the purpose of this OwnCloud “branching”. As a result, our cloud platform will retain the feel of a default “OS” interface on the different platforms it will be accessible from (clients).
It has been indeed observed through our field researches and design workshops that this “OS” look-interact-feel interface was not the most adequate one to interact with cloud services (Lesson 3 in “I&IC ethnographic wrap-up” by N. Nova), somewhat misleading. We’ve decided nonetheless to not focus our final work on this aspect and try to answer this particular question in a different manner (point H below). A simplified visualization should also accompany the service (point P below as well), it will display the current data and processes going on in the system to help objectify them.
B) Servers hosting multiple and dispersed instances of I&IC’s OwnClouds should necessarily find their location in some king of 19″ personal/domestic cabinets… A set of open source modular elements could help assemble and grow small personal/home data centers (physical parts of the “servers’ cabinet” mainly, no electronic hardware). By doing so, we could take in consideration for our designs the heat produced by the servers, the fact that they dry the air, the noise and the static electricity they produce, the dust they attract, etc. Existing hardware should fit into our modular cabinet.
By moving the x-small data center into the house and make it become domestic, as well as spread into multiple instances and units, we will force the formal and functional vocabulary of the 19″ cabinet to evolve. It will possibly need to get combined with different contexts and offer new functions.
A set of physical “controllers” (interactive/networked data objects) could help objectify the functions of the personal cloud and the presence of one’s data.
C) Each instance or virtualization of OwnCloud will contain a definite number of root folders (7 in the sketch above, but we might rather have 5 or even 3 in the end). These instances will be installed on servers (this procedure was described in our Cookbook section). The servers will find their location in the retrofitted 19″ domestic cabinet.
D) We drop files and data in the cloud because of “Motivations“, we “Use” the service and sometimes “Problems” occur (misunderstandings, misuse, crashes, etc.) This has been shown in the I&IC ethnographic wrap-up and graphs about the field research.
The versions of OwnCloud we will develop by using the I&IC libraries will take these users and systems behaviors into account. They will propose a set of Root Folders that will encapsulate specific automated tasks for their sub-folders and contained files. They won’t be editable. These 5-9 Root Folders will incarnate the Motivations (let’s call them for this scenario Motivations Folders), in a natural or a objective language. What could be these motivations? To hide (some files)? To multiply (others)? To keep (the most important ones)? To universalize (all of them)? etc.
These folders will probably be the same in each new instance of the cloud, not editable and with dedicated automated behaviors attached to them (“motivations”). The contained sub-folders and files will be automatically affected by these behaviors and rules.
This will be an application of theI&IC OwnCloud libraries we’ll have developed and proposed. Anybody will be able to use these downloadable “versions” of OwnCloud, but moreover, anybody with DIY skills (Processing, Javascript) should be able to develop different versions of the personal cloud, with alternative functions.
E) Permanent visualization of data and processes that are undergoing in the personal cloud should help understand its inner life (new files? deleted ones? GB left? etc.) Datadroppers will certainly be of great use here.
F) We could develop versions of I&IC’s OwnCloud: the “Standard” one would be the one we all know -saved the contained set of root Motivation Folders–, the “Shrinking” one could reduce its size day by day, forcing its user to erase files one by one and keep the most important ones until the inevitable dead end, the “Greeny” one could automatically erase the sleeping files, etc. The principle of versions is inherent to the one of the open source libraries.
G) Retrofitted 19″ domestic cabinet, servers, Motivation Folders (Root), physical controllers, data visualization: the almost full scenario.
H) A set of physical “controllers” (Networked Data Objects) will stand in direct relation with the Motivations Folders: 1 “controller” for one root Motivation Folder. The”controllers” will act both as devices to embody a proximate, possibly domestic “presence” for the user’s files/data and as an aid to objectify the implicit behaviors of the system. They will help maintain basic interaction with it. We will take again in consideration the “Motivation – Usages – Problems” graph in this case and the controllers could be called for this scenario Uses & Problems Controllers.
Controllers could be passive (when they will be stored the cabinet) or active (standing out of it).
I) Could we maybe play with the controllers as well? And therefore play with the data and functions associated?
J) The controllers should mainly give physical “presence” to distant (cloud) files and data in our daily environment. They should help do some basic interaction (“Uses“) and materialize accidents (“Problems“). Tiny signs (vibrations, small movements, discrete visual outputs, etc.) could bring feedback, whil natural movements associated with the objects could trigger interactions.
K) … and all these Uses & Problems Controllers (objective data “controllers”) might be distributed and meshed in houses, flat, small offices, basements, etc. in a new era of Domestic Data Centers.
