Some use cases for the TABADA! semantic information system.
- TABADA! Multiselect + TABADA! Multiedit: Add an ordering number to all the images taken at the Mexico pyramids.
- TABADA! Dataflow + TABADA! InfoPanels: Show on the desktop all the technology news from the three main online newspapers.
- TABADA! Action!: Publish all items tagged with "keep" to my Facebook account.
Mostrando entradas con la etiqueta Ideas. Mostrar todas las entradas
Mostrando entradas con la etiqueta Ideas. Mostrar todas las entradas
domingo, mayo 23, 2010
lunes, enero 25, 2010
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).
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).
viernes, enero 15, 2010
SocialDesktop4KDE
Leyendo este post de ASeigo sobre ayudar a los proyectos de KDE en problemas, se me ha ocurrido una idea para el Social Desktop:
-
Update:
Hay nuevo movimiento en forma de proyectos para poner al día y relanzar los sitios web de KDE:
http://blog.lydiapintscher.de/2010/01/17/help-needed-with-kde-org-relaunch/
http://community.kde.org/Scratchpad/www-rework/
... y para integrar la web con las aplicaciones de escritorio (Silk):
http://thread.gmane.org/gmane.comp.kde.devel.core/60677
Integrar en un menú de cada aplicación un diálogo estándar (como el Visor de Ayuda o el About) que permita conectar directamente con las conversaciones de los usuarios, filtrados por cada aplicación.Esto permitiría:
- que los desarrolladores tengan acceso directo de los usuarios reales de su aplicación, en un sitio centralizado. (Gracias al API de Social Desktop, el diálogo estandar podría publicar a cualquier servidor que quieran configurar para su proyecto - o por defecto al servidor público de Social Desktop).
- que los usuarios tengan un sito fácil desde el que reportar bugs y feature requests (la inspiración me la ha dado una propuesta similar de un usuario para Basket). Esta propuesta es una generalización de aquella idea.
- que los usuarios puedan conectar con otros usuarios de la misma aplicación - para compartir trucos, recursos (como el "Get more...", pero social).
-
Update:
Hay nuevo movimiento en forma de proyectos para poner al día y relanzar los sitios web de KDE:
http://blog.lydiapintscher.de/2010/01/17/help-needed-with-kde-org-relaunch/
http://community.kde.org/Scratchpad/www-rework/
... y para integrar la web con las aplicaciones de escritorio (Silk):
http://thread.gmane.org/gmane.comp.kde.devel.core/60677
martes, junio 30, 2009
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
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
sábado, junio 06, 2009
Metáfora para programación
Tradicionalmente se ha equiparado los programas de ordenador con las recetas de cocina.
Otra metáfora quizá más expresiva para referirse a la programación en general y a la programación de interacción en particular, es el mundo de la moda y la alta costura. Los programadores tienen mucho de artistas que utilizan una base muy técnica para hacer creaciones, que deben ser prácticas a la vez de atractivas.
Otra metáfora quizá más expresiva para referirse a la programación en general y a la programación de interacción en particular, es el mundo de la moda y la alta costura. Los programadores tienen mucho de artistas que utilizan una base muy técnica para hacer creaciones, que deben ser prácticas a la vez de atractivas.
lunes, febrero 16, 2009
Idea para un idioma de programación universal usable
Idea clave: reificar los conceptos de "enlace" y "colección".
Explicación:
Igual que la web revolucionó el almacenamiento de información gracias a hacer visible la idea del "enlace" entre documentos, se podría revolucionar la Programación por el Usuario Final creando una entidad "enlace" y otra "colección" que funcionen:
Explicación:
Igual que la web revolucionó el almacenamiento de información gracias a hacer visible la idea del "enlace" entre documentos, se podría revolucionar la Programación por el Usuario Final creando una entidad "enlace" y otra "colección" que funcionen:
- como entidades genéricas
- con una "API" visual sencilla y homogénea
- que funcionen SIEMPRE, sobre cualquier otra entidad manejable por el usuario (ésto es lo más difícil, haría falta un clasificador universal de información de usuario tipo Nepomuk + URIs).
- los lenguajes de programación son demasiado abstractos - la separación código/datos es un salto conceptual difícil para no programadores. (El caso más sencillo, el Apple Automator es un lenguaje de scripting, es difícil hacer flujos más allá de lo estrictamente trivial)
- el Excel es el paradigma más programable a nivel de usuario, pero sólo maneja relaciones numéricas - y no es aplicable a los objetos de interfaz, sólo a bases de datos.
- Un Enlace entre dos objetos permite definir acciones asociadas a eventos (desde un extremo "Origen" está accesible el otro "Destino") con un esquema mental sencillo. Como los enlaces se pueden aplicar a objetos de la interfaz, los enlaces se pueden usar para acceder a información no visible en el estado actual de la máquina.
- Una Colección permite automatizar una tarea repetitiva (sin las complicaciones del uso de bucles): aplicar una acción a todos los objetos de la colección, o a todos los que quedan tras aplicar un filtro.
- Tanto Enlaces como Colecciones soportan la "programación basada en ejemplos": los programas se pueden definir sobre datos reales, no como una entidad abstracta separada ("programa") sino como una serie de ediciones de manipulación directa sobre información. El feedback es mucho mayor que con un entorno/lenguaje de programación.
- Ver la "metáfora del pintor" para crear agrupaciones automáticas:
- Now, for the following let's think of nodes being white bricks placed in an ordered row on the floor. These bricks can be painted with one (or even several – think: spotty!) colors. The color indicates the element by which the bricks should be grouped.
- The grouper does one very simple thing: It wraps all adjacent, likewise colored nodes in a parent element (think of this being some kind of bag) that has the same name as the color of the nodes it wraps.So the essential part to be done beforehand is to color the nodes in the desired way. This is a two-step process: First, you need to check the role of each node as far as grouping is concerned and assign it that role by placing a painter on it that knows how to go about painting for this specific role. Second, the painting is actually performed.
jueves, febrero 14, 2008
Propiedad imaginaria
Una subversión/perversión de la tan mentada "propiedad intelectual". Si las corporaciones abusan de este concepto, es lógico que el lenguaje popular refleje las implicaciones.
Imaginary Property
miércoles, febrero 13, 2008
Killer app: gestor de atención
Los gestores de bookmarks de los navegadores están mejorando.
Sin embargo, aún les falta una funcionalidad que los convertirá en realtmente útiles para controlar el flujo de acceso a la información: registrar el nivel de atención prestada por el usuario a cada elemento archivado.
Sin embargo, aún les falta una funcionalidad que los convertirá en realtmente útiles para controlar el flujo de acceso a la información: registrar el nivel de atención prestada por el usuario a cada elemento archivado.
Suscribirse a:
Entradas (Atom)