Blog with Sidebar

The place where we write some words

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

By Wednesday, December 14, 2016 Interaction Design, Projects, Sciences & Technology, X-Posts Tags: 0141, B, Clouds, Code, Engineering, fabric | ch, Library, Open source, Programming, Tools Permalink 0

Note: “I&IC OwnCloud Core Processing Library” (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.

-

motivations_usages_problems_01_02

One processing project with one cloud, while the server (OwnCloud) can still be accessed by a regular interface (OwnCloud client). The upper part (white) is the “network/server side” of the project (OwnCloud), hosted on a Linux server, while the bottom (grey dots) is user or “client side”. It can consists in connected objects or environments, interfaces, visualizations of different sorts.

 

The I&IC’s Owncloud Core Processing Library is now composed of a “client side” component and “server side” component (IICloud’s Addon).

The “client side” part of the library (“user side” vs. “network/server side” in the illustrations above and below) can be used from Processing, in order to get access to OwnCloud server(s) and manipulate files. The benefit of the core library resides in the fact that it mashups all together a set of heterogeneous functionalities in one single library (it has been therefore renamed I&IC OwnCloud Core Processing Library as it is more closely related to our research).

 

Files manipulation :

You can copy, move, delete, upload, download any file from your OwnCloud server from within Processing. These basic actions can then be triggered by any programs, external sensors or other monitorable activities, as soon as you have integrated I&IC’s OwnCloud Core Processing Library in your Processing project.

Files sharing :

Share your files with other people or/and be part of the IIClouds OwnCloud ecosystem (see below).

Files tagging :

Managing files metadata. Every single file can be enhanced/informed with particular tags, a tag being defined by a pair (tag name, tag value). A trivial example may be to define a author tag or a version tag attached to an article (pdf, word document etc.)

Then, by using the I&IC’s OwnCloud Core Processing Library, you can search your files for a given author or a given document version, etc.

 

OwnCloud server and account activity :

This is a brand new part of the library that extends the initial set of functionalities. One can get usage statistics from the OwnCloud server you are connected to (CPU usage, memory usage, disk usage (global or per account)), with the idea that it could be used for data visualization, interfaces, etc.

In order to have access to this extended functionalities from “Your Processing Project” (illustrations above and below), you will have to install the new “IIClouds Addon” on the side of your OwnCloud installation or connect your project to a OwnCloud server that did so. You can observe your OwnCloud server more precisely and use these statistics directly in “Your Processing Project”.

 

Specific IIClouds behaviours control :

This is a brand new part of the library as well that extends the initial set of functionalities. As mentioned in “From design research wrap-up to final artifacts”, the “IIClouds Addon” will enhance the OwnCloud interaction experience with a specific structure of directories.

 

Each directory will have a specific built-in behavior ensured by the “IIClouds Addon”. These behaviors can be managed/controlled via the “IIClouds Library”. Taking the example of the TO_FREEZE directory, by the use a the “IIClouds Library” you can decide to freeze content (zip every single file dropped in the TO_FREEZE directory) or let “melt” the content (unzip all archive files).

 

motivations_usages_problems_02_02

Several processing projects, several interfaces, etc. with several OwnCloud Servers (including addons) constitute an IIClouds ecosystem. A project (client) can exchange information with one or several servers.

 

OwnCloud federation to the IIClouds ecosystem :

Once your OwnCloud server is installed or from any eligible OwnCloud installation (version > 9.0.0), one can request that a OwnCloud user account may be part of the IIClouds ecosystem/network. By doing so, the concerned OwnCloud account will see a TO_MULTIPLY directory appear (so as To_Accumulate, To_Care, To_Freeze, To_improve that cover different sets of functions). Below, in the conventional interface). By deleting or adding a file in that particular directory, your change will be spread over the entire IIClouds ecosystem.

 

owniicloud_04

Federation works like a subscription. By subscribing to the IIClouds ecosystem, you will receive all files that any participant to the ecosystem will drop in the TO_MULTIPLY directory, and reversely, any file deletion will be spread over the entire IIClouds ecosystem, meaning that, by deleting a file, it will completely disappear from the IIClouds ecosystem.

 

All described operations/functions can be triggered manually just by manipulating files from your favorite OwnCloud application as well as being controlled/triggered from a Processing application based on any kind of inputs you may want to use.

Functionalities and available control will be refined and completed and a full documentation and a complete set of how-to posts will be produced as soon as the version 1.0 of the I&IC’s OwnCloud Core Processing library will be released.

 

The entire code source will be made available to the community.

I&IC design research at “Bot Like Me” conference, Centre Culturel Suisse, Paris

By Thursday, December 8, 2016 Architecture, Design, Ethnography, Publications, Society, Thinking Tags: 0140, Algorithmic, Clouds, Code, Conferences, Data, Datacenter, Networks Permalink 0

Note: At the invitation of Sophie Lamparter (Swissnex San Francisco) and Luc Meier (EPFL ArtLab), we had the pleasure to present the current process and outcomes of our joint design research project in Paris, at Centre Culturel Suisse (CCS). This helped us collect meaningful impressions and comments about the ongoing work.

The conference was given last Friday and Saturday (02-03.12) in the company and attendance of an excellent line up (!Mediengruppe Bitnik, Nicolas Nova, Yves Citton, Tobias Revell & Nathalie Kane, Rybn, Joël Vacheron, Gwenola Wagon, Hannes Grasseger, I&IC’s research assistants Lucien Langton & Léa Pereyre,  so as many others!)

Together with Nicolas Nova, we presented the almost final state of our joint research project Inhabiting & Interfacing the Cloud(s), at a time when we are entering the prototyping of the final artifacts (deliverables).

 

Via Centre Culturel Suisse (in French)

—–

 

Du vendredi 2 au samedi 3 décembre 2016

—————————————————————————————

Bot Like Me
interventions en anglais

—————————————————————————————

A l’occasion de l’exposition de !MedienGruppe Bitnik, et avec la complicité du duo d’artistes zurichois, Sophie Lamparter (directrice associée de swissnex San Francisco) et Luc Meier (directeur des contenus de l’EPFL ArtLab, Lausanne) ont concocté pour le CCS un événement de deux jours composé de conférences, tables rondes et concerts, réunissant scientifiques, artistes, écrivains, journalistes et musiciens pour examiner les dynamiques tourmentées des liens homme-machine. Conçues comme une plateforme d’échange à configuration souple, ces soirées interrogeront nos rapports complexes, à la fois familiers et malaisés, avec les bots qui se multiplient dans nos environnements ultra-connectés.


Vendredi 2 décembre / dès 19h30
-
Conférence, 19h30-21h : Bot Like Me kick-off
avec Rolf Pfeifer (AI Lab de l’Université de Zurich / Osaka University), Carmen Weisskopf et Domagoj Smoljo ( !Mediengruppe Bitnik). Modération : Luc Meier et Sophie Lamparter

Performance musicale live, 21h30 : Not Waving

 

Samedi 3 décembre / dès 14h30
-
Tables rondes
-14h30-16h : Data Manifestos
avec Hannes Grassegger (auteur de Das Kapital bin ich), Hannes Gassert (Open Knowledge Network) et le collectif RYBN. Modération : Sophie Lamparter et Luc Meier

-16h30-18h : Cloud Labor, Petty Bot Jobs
avec Nicolas Nova (HEAD-Genève, Near Future Laboratory), Yves Citton (Université de Grenoble) et Patrick Keller (ECAL, fabric | ch). Modération : Marie Lechner

-18h30-20h : Botocene & Algoghosts
avec Tobias Revell et Natalie Kane (Haunted Machines), Gwenola Wagon et Jeff Guess (artistes). Modération : Joël Vacheron et Nicolas Nova
Concert 21h : performance live de Low Jack et carte blanche au label Antinote

 

Entrée libre sauf concerts (12 €) / Réservations :  billetterie en ligne / 01 42 71 44 50 /reservation@ccsparis.com

 

—————————————————————————————

Post note:

Following the conference, the Swiss Cultural Center in Paris put up a video documentation of the full conference on their Youtube channel.

In particular below the part when we’re talking together about the research project Inhabiting and Interfacing teh Cloud(s) with Nicolas Nova.

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

By Thursday, November 24, 2016 Design, Interaction Design, Projects, X-Posts Tags: 0139, A, ABCD, Art direction, B, C, Cabinets, Clouds, D, Data, Datacenter, Domestic, ECAL, Experience, Infrastructure, Interface, Library, Open source, Personal, Tools, Wrap-up Permalink 0

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

 

Based on the existing open source cloud software OwnCloud and our I&IC’s OwnCloud Core Processing Library, the four elements of the kit will be:

—

A) A set of infrastructure furniture (“A Personal Data Center“), to assemble your own small scale and home based (or office based) data center! Pieces should be cnc cut from plywood by following the blueprints and instructions that we’ll be published online, then assembled to set up 19″ computer cabinet(s), or even small scale data centers with additional “domestic” functions. These later should take benefit of the heated and dried air coming out from the home computers/servers.

With Léa Pereyre.

 

cabnt_001_M

 

cabnt_002a_M

 

cabnt_003b_M

 

cabnt_004_M

 

cabnt_012_M

 

A modular / diy furniture set (to be built and assembled in a “modest” way: cnc cut-outs, plywood, colored straps — no screws, no glue –). It is a 19″ computer cabinet for IT servers (one of the main formal building blocks of data centers, which is usually quite expensive, made out of metal and very heavy > in this case it will cost and weight far less).

It is extended to new domestic functions that should benefit from the heat and dry air released by the computer servers. Cold air is entering from the front and bottom , then heated air is released from the back and top. The air flow is created by natural convection. Assembled and adequately apertured (note: various apertures not drawn in teh above illustrations), these 19″cabinets can trigger hot and cold aisles or areas in an large room.

 

B) A set of five cloud data controllers (“My Data Controllers“), directly linked to the five folders and their data in “A Personal Cloud” (below), will help control them (or not) … To be cnc cut from plywood as well and then put together, along with pieces of electronics (Raspberry Pis and sensors), for which the code will be distributed as well.

The controllers will be “dormant” when hanged on the wall and become active once placed in the space.

With Lucien Langton.

 

cntrlr_000_M

cntrlr_001_M

cntrlr_002_M

 

The data controllers embody and allow a simplified, natural interaction with one’s data, hosted in one’s cloud (version “A Personal Cloud” below, whose servers are placed in “A Personal Data Center” for a full use of the kit). A direct link exists between each physical object and its alter ego as a folder with its contained files and data in the cloud. For example in the above illustrations, would the vertical bar fall (second object from left), then all the files contained in the related or linked folder would be deleted.

These objects are therefore “controllers” of personal data and will constitute new functions in the domestic environment.

 

C) Developed on the basis of open-source software OwnCloud, this element of the kit is an alternative version of the cloud (“A Personal Cloud“) with automated behaviors, chains of events. Five folders bring together the main motivations that generally push us to place our files and data in the cloud (e.g. because it’s convenient, to make backup, to shares one’s files, to preserve data, to multiply files or share them, etc.) These motivations have been identified in our ethnographic field research about the cloud.

This alternative version of OwnCloud, developed thanks to I&IC’s OwnCloud Core Processing Library, will be openly accessible as well.

With Christian Babski (fabric | ch)

 

owniicloud_04

There will be direct links between these five folders in “A Personal Cloud” and the five controllers above (e.g. if the plate of the table is not taken care of and its dust cleaned, all the files in the concerned folder will be first unzipped, then displaced in a publicly shared folder!)

“A Personal Cloud” as well as “My Data Controllers” are direct implementation of the development library below. Its is an illustration of an alternative to the existing: a different cloud, based on the tools that have been developed or expanded in the frame of this design-research.

 

D) The least visible but probably the most useful part of the project: it is a development library in Processing language (now widely used in the design and makers communities), for the open source cloud software OwnCloud. It is adapted and then extended with new functions according to our needs (it concatenates two libraries and add our own), directly from their own.

This will allow everyone with Processing skills to develop their own projects (client side). A tool that was missing so far.

The kit that has been developed is made possible mainly by the use of this development library.

With Christian Babski (fabric | ch)

 

iiclouds_005

The new library will be made accessible on Github for further forks and iterations.

 

 

A), B), C) & D) will become the four elements that will constitute “A Personal Cloud Kit“, to be openly accessed/downloaded on a dedicated website.

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

By Friday, September 2, 2016 Design, Interaction Design, Projects, X-Posts Tags: 0138, ABCD, Art direction, Cabinets, Clouds, Data, Datacenter, Domestic, ECAL, Experience, Ideas, Infrastructure, Interface, Open source, Personal, Tools, Wrap-up Permalink 0

 

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.

 

…

IMG_1642ct

002_IMG_1603ct

003_IMG_1604ct

A) “Motivations <-> Usages <-> Problems” graphic from the ethnographic field study is replaced by 5 “natural” terms (verbs of actions) that cover and segment a technical terminology of files manipulation and processing: To_Care = to backup, to copy, to privatize / To_Accumulate = to store, to keep / To_Multiply = to share, to universalize, to publicize / To_Freeze = to store compressed “forever”, to hide / To_”Pimp” = to process, to update, to improve.

As already stated, these five terms (verbs) will be subject to further modifications depending on the exact final direction the project will take.

 

004_IMG_1610ct

B) The overall Cloud service and its real time behavior can be visualized and somehow moderated. An Overall View would give information about the filling percentage of the hard drives –by doing so, it could help moderate its use– while a Flux View would only give information about the quantity of data stored or erased.

 

005_IMG_1615ct

006_IMG_1613ct

007_IMG_1614ct

C) Cloud visualization and moderation #1, Overall view: the idea would be to redesign the long power strip and give it a behavior twist.

This behavior would be directly linked to the filling percentage (%) of each user’s Our Cloud: The more the cloud is full, the less plugs are active and opened (give electricity). Connected to standard home’s devices like lights or other electric furniture would turn the overall setup into visualization device (of the filling of the hard drives). By extension, we could even plug the Cloud itself into this plug and turn it into an autonomous, yet risky self moderator.

 

008_IMG_1616ct

D) Cloud visualization and moderation #2, Flux view: a GigaBytes cookoo clock! It would act like a mural clock, unless for gigabytes in your personal cloud. Every 10 GB it rings, makes a special sound for 100 GB and a concert every 1T.

 

009_IMG_1605ct

010_IMG_1607ct

E) To_Care (vs. Neglected!), To_Accumulate (vs. Vanished!), To_Multiply (vs. Shrinked! ), To_Freeze (vs. “Melted!”), To_”Pimp” (vs. “Jumbled!”): 5 root folders in Our Cloud.

The combination of 5 pairs of verbs (actions) vs. past participles would drive the design of 5 controllers (smart objects or networked data/bot objects, similar to the ones designed during Botcave workshop). The 5 controllers drawn here evoke roughly the ideas of vibrating objects, unstable sticks, of file retrieval, of natural manipulation and feedback. What they can concretely become is sketched with more details below.

 

011_IMG_1618c

012_IMG_1620ct

013_IMG_1623ct

014_IMG_1625ct

015_IMG_1627ct

016_IMG_1628ct

F) 5 controllers, 5 responsive objects. These controllers could also possibly be plugged in the Overall View device (power strip), therefore working or not depending on the cloud’s filling.

To_Care (vs. Neglected!) could be an electrostatic shiny large plate that attracts dust. Doing so, it would help clean the air for the servers possibly located in the same room. It would ask to be cleaned regularly otherwise files contained in the To_Care folder would become “Neglected!” (backups erased and files publicized!)

To_Accumulate (vs. Vanished!) could be a long stick in precarious balance. It could also possibly be an electro-magnet acting like a pin tray plugged into the power strip. If the stick falls, all your accumulated files would be erased, “Vanished!”, except one that could be retrieved from the bottom usb port.

To_Multiply (vs. Shrinked! ) could be linked to a folder in Our Cloud from which all the contained files would be multiplied on all your devices and on fellow cloud users disk (same folder) and their devices. When an other user on a different cloud would add or remove files, it would also act in your own To_Multiply folder, by adding or removing files. Therefore, the files would be “multiplied” or the folder “shrinked” depending on common actions. The device would only visualize the process of multiplication or shrinking behind a two-way mirror through the visualization of a dynamic voronoi graphic.

To_Freeze (vs. “Melted!”) could be a device that helps you keep your files “stored forever compressed and private”. You would need to put this device in your fridge and keep it at low temperature. When 4°C would be reached, the files in the To_Freeze folder would be compressed and privatized. If the temperature rises, the files would first be uncompressed, then made accessible and finally be publicized (Melted!). A few files could be retrieved fro the box itself by turning it.

To_”Pimp” (vs. “Jumbled!”) could be a mural console with a glowing UV light. The more processes on the files the more it would glow and transform the appearance of the images exposed.

 

 

Complete “Our (House) Cloud” Scenario, resume:

017_IMG_1629ct

IMG_1643ct

018_IMG_1630ct1) Based on the open source software OwnCloud and with the help of I&IC OwnCloud Core Processing Libraries, an alternative version of the cloud (“Our (House) Cloud”) would be built.

 

019_IMG_1631ct

020_IMG_1632ct

IMG_1644ct
2) “Our (House) Cloud” would always contain the 5 same root folders (To_Care / To_Accumulate / To_Multiply / To_Freeze / To_”Pimp” ). Some of these folders and their content would be shared between all “Our (House) Cloud” users. It would be hosted on conventional servers within a retrofitted 19″ Cabinet (“Our 19″ Cabinet”), a mix between a living structure, a house data center and a 19″ computer cabinet.

2 responsive objects would help monitor the overall cloud.

 

021_IMG_1637ct

022_IMG_1636ct3) 5 controllers (responsive objects) would help give a domestic and continuous presence to your files and folders.

 

023_IMG_1638ct

024_IMG_1639ct

025_IMG_1640ct

4) 5 responsive objects as controllers: A low table (To_Care), a long vertical stick (To_Accumulate), a voronoi-like screen and dynamic visualization (To_Multiply), a box in the fridge (To_Freeze), a mural console (To_”Pimp”).

Towards applied object design and interaction

By Thursday, September 1, 2016 Design, Interaction Design, Projects Tags: 0137, Cabinets, Data, Datacenter, Furnitures, Infrastructure, Networks, Smart, Things Permalink 0

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.

Three summary drawings

By Thursday, September 1, 2016 Design, Interaction Design, Projects, X-Posts Tags: 0136, ABCD, Art direction, Clouds, Data, Datacenter, Domestic, ECAL, Experience, Ideas, Interface, Open source, Personal, Tools Permalink 0

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)

By Friday, August 19, 2016 Design, Interaction Design, Projects Tags: 0135, Art direction, Cabinets, Clouds, Data, Datacenter, Domestic, ECAL, Experience, Ideas, Infrastructure, Interface, Open source, Personal, Tools, Wrap-up Permalink 0

 

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.

 

IMG_1220ct

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.