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:

 

00_shaker_pegs

 

Shaker furniture as well as their household objects were designed to be suspended to pegs in the living room, in order to make space for spiritual ceremonies. Interestingly, this design also suggests an active state for objects (i.e. when the chairs are oriented “naturally”), and a passive one when hooked, where their main function is somehow “paused”. This status resonates with connected objects and somehow questions their presence in the private sphere, where they’re usually always on, always gathering information, and always connected.

We also noticed that this could help connect cloud interactions to natural gestures connected to objects that can happen in a domestic environment, on a regular basis. Like opening or closing a door, switching a button, having an object that fall, roll or that you need to clean, maybe store in a special place like those chairs, etc. Connecting simple physical interaction with abstract digital behaviors could be both helpful and meaningful to help understand what is going on.

A second important reference is perhaps quite more practical, in the sense it concerns the objects assembly. As explained in the post about our Do-It-Yourself server cabinet, an important concern in our process is to define a simple and accessible assembly process for future users.

 

01_FOBricated

 

This bench by FOBricated needs no glue or screws, it is solely held by a ratchet strap.

 

The assembled five prototypes still need corrections and improvements, however they were extremely useful to reconsider each object’s assembly process which strongly influences their weight.

Below in the same alphabetic order as their related and connected folders appear in the standard interface of OwnCloud, pictures from the five data controllers (TO_ACCUMULATE, TO_CARE, TO_FREEZE, TO_IMPROVE and TO_MULTIPLY). These five folders will be automatically created in the “alternative version” of the cloud we are currently working on (“A Personal Cloud”), they carry specific interactive behaviors.

The reasons and relations between these five objects and their counterparts as folders and contained files in the cloud have been detailed in the previous post “A Personal Cloud: a home cloud kit for personal data (centers) / reappropriate your data self“.

 

owniicloud_04

Five cloud folders (above) embodied within the five following networked objects, acting as physical counterparts:

 

TO_ACCUMULATE

03_IMG_5127_web

Interaction behavior: if or when the object falls, all the files that have been accumulated in the “TO_ACCUMULATE” folder over time will be deleted, literally “vanished”!

Rem.: the object still seems too massive here, perhaps the impression of its instability will be enhanced by making it a bit taller and thinner, like a stick.

 

TO_CARE

04_IMG_5124_web

Interaction behavior: the top (missing in the above image) made of acrylic glass will attract dust with the help of a ionizer. It will need to be cleaned and taken care of regularly. This action will help take care of the files contained in the TO_CARE folder by creating backup of them. Yet without this natural interaction, the backups will be deleted and in the end, the last ones automatically moved into the TO_MULTIPLY folder, ready to become “neglected”!

Rem.: (here also without the top) the networked object still needs to be reconsidered to be easily suspended to TO_IMPROVE (below), while avoiding the present asymmetry in the assembly between the two main parts.

 

TO_FREEZE

05_IMG_5125_web

Interaction behavior: the networked object that consist in the simple original “brick” needs to be maintained at low temperature and in the dark. It should be located in the fridge (!) and kept at low temperature. If this is achieved, the files and data contained in the TO_FREEZE folder will be automatically kept compressed (zipped).

From time to time, the brick’s battery will need to be recharged and moved out of the fridge… If it is left too long out of freezing temperatures, then its files will be unzipped, “melted”! And then moved into the “TO_ACCUMULATE” folder, ready to be deleted …

Rem.: the object consists only in the main elements that brings interaction to objects, the original “brick”. We’ll be rethinking the box’s assembly to orient it towards the same type of assembly described for our server cabinet.

 

TO_IMPROVE

06_IMG_5128_web

Interaction behavior: the object physically holds the four other networked objects and serves as a hook rail. When these are deployed in the home space, the cloud is enhanced by additional functionalities provided by these objects and therefore “improved”. The files contained in the TO_IMPROVE folder are themselves subjects to unpredictable “improvements” and updates, only when these other four objects are deployed and according to their file types (images, sounds, texts files, etc.)

Rem.: the object, still lacking the pegs here, will be totally redesigned to be much lighter, as well as to set up a standard way of fixing it to a wall.

 

TO_MULTIPLY

07_IMG_5126_web

Interaction behavior: no physical interaction in the case of this networked object but only visualization. All the files located in the TO_MULTIPLY folder will be automatically duplicated and spread over the entire network of Personal Clouds! The files deleted will be deleted everywhere in the same way, the volume of the containing folder “shrinked”!

Rem.: the object still too small here will become bigger, in order to accommodate a decent sized screen for visualizations as well as to differentiate it from other objects.

 

All the prototypes above are still at a quite early stage, however it seems we can easily start to conceive them as a family, with for each one of them either a suggested interaction or role in the domestic environment.

Comments are closed.