No sin mis datos

Uno de los axiomas del What is Web 2.0 de Tim O’Reilly es que «data is the new Intel Inside». Mis datos son míos son míos son míos. ¿Sí? La cuestión de la propiedad de los datos, que tanto se ha puesto de moda con el embrollo de Robert Scoble y Facebook, es una de las que debería preocuparnos a todos.

Last.fm y yo compartimos el historial de cuatro años de música escuchada. eMusic sabe qué música le he comprado. Amazon sabe qué compras he hecho en los últimos años. Facebook o LinkedIn tienen un montón de información mía. Meebo tiene un historial de múltiples conversaciones privadas que he mantenido en los últimos meses. Fuera de la red hay muchos más ejemplos. Mis operadores de telefonía saben con quién he hablado, cuándo y cuánto tiempo. Visa y MasterCard saben tanto de mi vida… Ahora que me he comprado un abono trimestral de Transports de Barcelona, no sería nada complicado seguirme con una precisión que a veces provoca vértigo…

  • Compartir los datos es bueno: que Last.fm conozca mis gustos personales les permite ponerme música a mi medida. Es comodísimo y extremadamente conveniente saber que en cualquier ordenador con el que pueda navegar puedo acceder a todas esas conversaciones de Meebo.
  • Compartir los datos no es ninguna novedad: el quiosquero sabe qué prensa compro, el camarero del bar qué suelo tomar y me encantaría tener un librero que conociese mis gustos. En la red son los papeles que han ido adquiriendo mi lector de RSS, Amazon y tantos otros servicios.
  • Compartir los datos es bastante inevitable: quien quiera vivir en un mundo sin tarjetas de crédito puede hacerlo (con dificultad, cierto es), pero yo no quiero. Por nada del mundo. Mis datos están en manos de Visa, Google, Yoigo… Mientras me fíe de ellos, es algo con lo que puedo vivir. Más si tenemos en cuenta las cosas que me perdería si no les cediese parte del control.
  • Pero, obviamente, compartir los datos tiene sus riesgos (y por ello hay una legislación sobre protección de datos y otra para proteger la intimidad de las personas). Por un lado, y aún sin hacer nada ilícito en la red, mis datos son míos, y nadie tiene por qué divulgarlos. Por el otro, y aunque Amazon, por ejemplo, sea depositaria de mi historial de compras, este es mío y por tanto, debería ser capaz tanto de exigírselo como de solicitarles que lo eliminen. Aunque use Google Browser Sync (fantástica herramienta, por cierto), debería poder acceder a mi historial (puedo, desde luego) y poder borrarlo (también se puede hacer, aunque no es la cosa más cómoda del mundo borrar el historial de un día entero).

Lo que estaba haciendo Scoble vulneraba, claramente, los términos del servicio de Facebook. Pero a veces los términos del servicio no son demasiado comprensibles. Ni justificables. Ni aceptables. Cuando me apunté a Facebook, el servicio entró en GMail (con mi permiso y sin vulnerar los términos de servicio de GMail, ciertamente), tomó nota automáticamente de todas las direcciones de correo de mis contactos (unos cuantos centenares, no habría sido nada cómodo hacerlo a mano), me dijo cuáles estaban dados de alta en Facebook (ninguno de mis contactos dio su permiso explícito para hacerlo, aunque muy probablemente sí lo ponga en el acuerdo ese que nadie se lee al darse de alta en cualquier web) y se ofreció muy amablemente a ‘espamear’ al resto para invitarles a unirse al servicio. ¿No debería Facebook devolverme el favor si lo deseo?

El caso Scoble pone de manifiesto la necesidad, cuando menos, de un código ético para todos aquellos que actúan como depositarios de nuestra información personal. Como suele pasar, alguien no ha necesitado de la evidencia para comenzar a actuar: el Project VRM (de Vendor Relationship Management, por oposición a CRM) del Berkman Center for Internet & Society de la Harvard University, bajo el liderazgo de Doc Searls (que escribe sobre «Scoble vs Facebook» en Linux Journal). El reto al que se enfrentan no es sencillo bajo ningún punto de vista: técnicamente es una pequeña pesadilla, el abanico de posibles posiciones morales es enorme y muy difícil de armonizar y, finalmente, van a topar con la opsición de múltiples empresas que, como Facebook, opinan que buena parte de su patrimonio perdería mucho valor si se viesen obligadas a compartir sus datos con sus usuarios (y, no lo olvidemos, propietarios legítimos de esa información). Pero esperemos que el embrollo Scoble-Facebook sirva como mínimo para sacar a la luz un debate que debería ser candente.

Vía.

Design, otro bookmarklet para desarrolladores web

Captura de pantalla del bookmarklet design en acción

Apunte rápido para enlazar Design, un fantástico bookmarklet para diseñadores que da las funcionalidades de tomar medidas y dibujar rejillas y reglas sobre la página web que estemos visitando, algo que resulta muy útil en muchas ocasiones…

PS Compañero ideal, por cierto, para Jash otro bookmarklet que, en esta ocasión, nos da acceso a un poderoso shell de JavaScript.

Después de AJAX, Comet

No será por falta de tecnologías nuevas. Me entero por el blog de Simon Willison de la existencia de una nueva «hype word» en el desarrollo web: Comet (acuñada por Alex Russell, hace ya un año y medio, que en esta casa nunca hemos sido especialmente rápidos). El problema a resolver es similar al que ataca AJAX: comunicación de baja latencia entre cliente y servidor. La técnica la ejemplifican la integración de Google Talk en GMail o Meebo. De lo que se trata es de mantener viva una conexión HTTP de manera que no es el navegador quien pide datos al servidor, sino que el servidor puede enviar en cualquier momento datos al navegador. Una especie de «streaming de eventos», si se quiere. «Push» donde AJAX es «pull».

Está claro por qué los ejemplos más claros son de mensajería instantánea en el navegador: con el correo podemos esperar unos segundos entre actualización y actualización, pero en mensajería instantánea necesitamos que el programa nos abra una ventana tan pronto como alguien nos envíe un mensaje. Podríamos llamar al servidor una vez por segundo, pero parece que la cosa escala mejor con conexiones HTTP persistentes que con múltiples httprequests.

Como con todo, se trata de una nueva herramienta en la caja. Ni AJAX es mejor que Comet ni al revés: dependiendo del tipo de aplicación una tecnología será más útil que otra. En el caso de aplicaciones multiusuario, en cualquier caso, Comet apunta muy buenas maneras. Y, además, la integración de Comet con AJAX ya la ha demostrado Google.

Los que estén interesados podrán encontrar más recursos en Comet Daily.

Diseño web

El diseño web es la creación de entornos digitales que posibilitan y fomentan la actividad humana; reflejan, o se adaptan a, voces individuales y contenido; y cambian grácilmente con el tiempo reteniendo siempre su identidad.

No me parece la definición definitiva de diseño web, pero sí un magnífico punto de salida. Es del último artículo de Jeffrey Zeldman en A List Apart, Understanding Web Design. De lectura obligatoria.

Y otro pedazo más del artículo, que me parece aún mejor que la definición:

Los grandes diseños web son como los grandes edificios. Todos los edificios de oficinas, por especiales que sean, tienen lobbies y baños y escaleras. También los sitios web comparten elementos comunes.

Aunque un gran diseño para un sitio es completamente individual, también se parece mucho a otros diseños con funciones similares. Lo mismo se aplica a los grandes diseños para revistas y diarios, que difieren de los diseños banales para revistas y diarios en un centenar de detalles sutiles. Pocos celebran los grandes diseños de revista, pero millones, consciente o inconscientemente, los aprecian, y nadie lamenta que no sean posters.

El diseñador sin experiencia, o poco reflexivo, se queja de que demasiados sitios web usan parrillas, demasiados sitios usan columnas, demasiados sitios son «cuadrados». Se vienen haciendo esfuerzo por evitar las cajas desde 1995; aunque a veces han tenido éxito, la mayoría ha dado pie a diseños estéticamente funestos e innecesariamente poco usables.

El diseñador web experimentado, como el director de arte de diario con talento, acepta que muchos de los proyectos en que trabaja van a tener cabeceras, columnas y pies de página. Su trabajo no es protestar sobre esos puntos comunes emergentes, sino usarlos para crear páginas distintivas, naturales, adecuadas a la marca, sutilmente memorables y discreta pero inequívocamente atractivas.

Si consigue todo eso y suda en los detalles, su obra será hermosa. Si no todo el mundo aprecia esa belleza ?si no todo el mundo entiende el diseño web? no deberíamos llorar por el diseño web, sino por los que no saben ver.

PS Para los que se queden con ganas de leer más, un buen punto de inicio es Design doing en Adactio, un artículo tan bien escrito como hiperenlazado.

Media Queries…

Vía el blog de Russell Beattie (esta entrada, en particular) llego a Media Queries, un «W3C Candidate Recommendation» de junio de este año. Traduzco (más o menos) el «abstract»:

HTML4 and CSS2 soportan hoy en día hojas de estilo a media para diferentes tipos de medios. Por ejemplo, un documento podría usar fuentes de palo seco al mostrarse en pantalla y romanas en la impresión. «Screen» y «print» son dos de los tipos de medio definidos. Las Media Queries extienden la funcionalidad de los tipos de medios permitiendo un etiquetado más preciso de las hojas de estilo.

Una Media Query consiste de un tipo de medio y una o más expresiones para limitar el ámbito de la hoja de estilo. Entre las características que puede usarse en una media query están «width», «height», y «color». Usando Media Queries las presentaciones pueden personalizarse a un rango específico de dispositivos de salida sin cambiar el propio contenido.

A ver si la iniciativa tiene éxito, porque en un mundo lleno de móviles con Opera Mini 4, Safari para iPhone y demás alternativas que no se identifican «correctamente» (porque… ¿es correcto que esos navagadores tan sofisticados se identifiquen como «handheld»?) el desarrollo web se está poniendo más complicado que en los tiempos de Netscape Navigator…