A taxonomy for storage of data in the Cloud

TO DO: Add lots of practical examples. And graphics!

In a nutshell: Provide constant feedback for the state of all data in distributed on-line services ("the Cloud"), with respect to connection (synchronized, unsynchronized) and access speed (slow, fast).


The problem of storage in a connected world

Information in computers has been traditionally stored in filesystems. This is a storage model that worked well for mainframes and corporate networks, where an expert administrator took care of the filesystems, and that survived a transition to personal computers (somewhat transformed by the "desktop metaphor") where the amount of available data was reduced and limited to a single device.

Most programmers will not realize it most of the time, but files are by itself an abstraction model over a more complex technology model - that of persistent storage media, which handle blocks of electric signals in physical electronic devices.

The abstraction provided by filesystems is less than perfect for the typical data needs of people in the mainstream information sphere, where both corporate and personal users share information through the decentralized system that is the Internet. Not the smaller problem is that nobody will be responsible for administering data, or when they do, this creates a single point of control and failure - two undesirable traits.


The Cloud - on sunny days

The ideal data model for personal user data should be one of "always persistent, always accessible, anywhere". This puts users again in control of the information they own, using a simple centralized abstraction.

The problem is, current technology still doesn't support this directly. The proposed "cloud" metaphor has been marketed to users as an approximation of that model, but it still fails to deliver the promised experience because of abstraction leaks.

Abstraction leaks are situations where there is a mismatch between the model expectations induced by the metaphor and the actual system behavior. Sometimes the limits of underlying technology will skip through the details of the proposed model: network connection will fail, local storage disks will break... The resulting error situation and steps required to fix it are utterly difficult to explain to people not expert in the used technology.


The Cloud Storage taxonomy

There are two axis that directly affect user experience of data stored in the cloud, and thus should be included in the user model for cloud storage:
- Location: Connected vs Disconnected.
- Speed: Fast vs Slow.

Note that Location is not primarily about the physical position of the stored data (which is mostly independent to the problem of data storage, thanks to the Internet) but one of logical access: devices can be a part of the Net sometimes, but sometimes not. Connected/disconnected is the relevant fact to know about a device when thinking of retrieving the same data later.

So, the different and fundamental kinds of persistent data introduced by the Cloud, in addition to the abstraction of "Document" and "Media type" already supported by filesystems, are these four classifications:

* Connected data located in a fast medium.
* Disconnected data located in a fast medium.

* Connected data located in a slow medium.
* Disconnected data located in a slow medium.

Why are these four states relevant, and why should they be treated as different one to each other in the user model?

The first state (connected, fast) is the ideal situation, the one that best matches the promised Cloud metaphor of "always on, anywhere" data. But as soon as the technical limits appear, the experience degrades:

- Disconnected data is one that is created or modified in a device without a connection to the Internet. The problem with disconnected data is that it breaks the Cloud metaphor: if I move to a different device, my new data or recent edits will not be available. This problem is what prompted users to abandon mail clients in favor of webmail, and the reason why web services are the trend.

- Slow data is one that takes time to stabilize and get "imported" into the cloud; it's data I must wait for after I've finished my work. Fast data is instantly protected as soon as it's created; I can be confident that closing the application, unplugging the USB key or turning off the computer will not be a problem - I have enough feedback to be sure that the data is safe. On the contrary, with slow data, in all those scenarios I have babysit the data saving process before I can proceed with my life.

- Disconnected AND slow merits a separate because, in addition to the problems listed above, it shows an important trait: user data is at the highest risk of being lost. Any system problem may cause open data to be destroyed. A simple power glitch, or an application crash will destroy the user current session and all the ongoing work in it will be lost.

Connected slow data can protect against it by saving data in the background; in case of failure the latest online version can be retrieved, even if a bit outdated.

Fast disconnected is even safer in this scenario; a power failure or broken application will not destroy data, because fast data will already be saved to a persistent state. It doesn't protect in the case of a lost or broken device, but that's less severe because for cloud data, disconnected is supposed to be a transient state anyway; as soon as the device gets reconnected, it will synchronize to the cloud and the data will be safe again.


The sad thing is, disconnected slow data is the default storing model for desktop applications, so it's the most common. Online web applications may change this, but they are more likely to copy this dangerous model from desktop apps.


"Saved" state

There's a third dimension (saved / unsaved) that is relevant to system designers and programmers but should be transparent to users, following the principle by Jef Raskin of "treat user data as sacred" (see Your data is sacred, Always safeguard users' data) and its corollary "don't force users to input the same data twice". This means that all user-introduced data should be instantly saved in some way, and it shouldn't be lost except by catastrophic failure (and ideally, even in that case too).

Web Dogma

Danish webshop FatDux has created 10 simple Web Dogma for designing web sites, inspired by George Orwell's 5 writting rules (which are 6).

They seem tailored to convince stakeholders not falling into some very common 'business falltraps' and technicians into not overdoing it.

La amarga vida del trabajador freelance

O, cómo cobra un diseñador. Relación cliente - empresa.

JOLIE, un lenguaje para diseñar SOA

Jolie es un lenguaje específico de dominio (DSL) para programar aplicaciones con "arquitectura orientada a servicios" - permite conectar funciones publicadas en distintos protocolos (D-bus, DCOM, REST...) para conseguir una aplicación compleja. Es "como COM pero bien hecho, 20 años después".

Entrevista con el autor

Hash: Password checkword

Métodos y código/programas javascript para generar códigos hash a partir de claves.

Puede servir para programar una extensión Firefox para la usabilidad de formularios de login (mostrando la checkword para comprobar si ha habido errores al teclear)

http://wijjo.com/PasswordHasher
http://hashapass.com/
http://wijjo.com/passhash/passhash.html

Security vs usability in login passwords

Jakob Nielsen has a recent Alertbox against obscuring passwords with ****asterisks****. Some people has proposed several solutions, but none of them is both secure and usable. I think I've found a solution that is both.

Thinking of this as an information problem instead of (just) a security one,
what is needed to solve it is something like the hash codes as used in
cryptography.

You don't really need to show the *whole* password, just enough
information derived from it so that the user will notice if there was
an error. For an example on how it could work:

- Say, the chosen password is HOMELAND.
- As a simple hash, remove every second letter: HMLN
- Shift each letter one character down: GLKM
- For this result to be usable, combine each obtained letter with the
nearest vowel: GILOKOMO

If the user mistypes the password, a different check-word will be produced.
For example: HOPELAMD -> HPLM -> GOKL -> GIOUKOLO *error, the
password is wrong.


Of course, a real hash function should be used that utilizes *all* the
information in the original password, not half of it! The important
property of a hash function is that the original information can't be
recovered from it, so the password is safe. Much better for security
than a plain-text exposed password, isn't it?

This process has a small usability problem in that you'll have to
learn the check-word for every new used password, but login is such a
repetitive procedure that this learning should happen quickly.

PositLog: Un ZUI programado con Javascript y AJAX

Un gestor de contenidos GPL, con interfaz gráfica tipo Zoom User Interface. Y en AJAX.



PositLog A zoomable CMS implemented by Ajax.

Zooming User Interface - Wikipedia