II Ley del Feedback

A. Cuando se realizan cambios en un producto la gente los percibe de forma negativa en un primer momento si éstos introducen variaciones en la forma de manejarlo, aunque a la larga sean beneficiosos para ellos.

B. A la hora de dar feedback u opiniones sobre cambios en un producto siempre se esforzarán más en mostrarlas aquellas personas que tengan opiniones negativas.

Es decir, dado un grupo de personas que usan un producto, donde 1/3 no estan satisfechas con los cambios, 1/3 son indiferentes, y 1/3 están satisfechos, el tercio insatisfecho generará mucho más ruido que el resto, dando una imagen incorrecta sobre la percepción global de los cambios.

* * *

Notas:

  • El reciente rediseño de Facebook ha vuelto a poner de manifesto esta II Ley del Feedback. Se han creado grupos multitudinarios quejándose del cambio. Esto ya ocurrió hace años, cuando introdujeron el Newsfeed. Ese cambio introducía modificaciones severas en la forma en que se usaba el sistema, pero si hubiesen hecho caso a los usuarios y lo hubiesen quitado, lo que hoy es un patrón de diseño universal probablemente no se hubiese extendido.
  • Por tanto, es importantísimo saber escuchar el feedback de los usuarios, y no dejarse despistar.
  • La primera ley del feedback no se cual es, pero asumo que ya existirá y por eso bautizo la mía como la segunda.

Strange bugs are happening

Aviso a navegantes: este es un post über-técnico, aunque no por ello falto del cariño y habituales chascarrillos que harán de su lectura una experiencia relajante y encantadora. Para quien no se vea capaz, o para quien empiece y vuelva a este párrafo para reengancharse con esta linea, aquí tenéis otra historia que escribí excclusivamente para vosotros.

Entrando en materia: Si entras con IE 6 en http://www.chicadelatele.com… ¡crash! ¡biff! ¡bang! ¡bum! Tu navegador desaparece. Nos han escrito esta mañana -es uno de los blogs de La Coctelera, aunque con dominio propio- para contarnos que sucedía este problema.

chica-bug.png Entre los ratos que me dejaba el lanzamiento de un portal por aquí, el mantener un servidor a flote que ha recibido una avalancha de 10.000 mails en 10 minutos por allá y otras labores de este esquizofrénico web servidor de ustedes -que no servidor web-, me he pasado gran parte del día tratando de cazar esa mariposa (por cierto que tengo un borrador al respecto de esto de la esquizofrania web, vieniendo pronto).

Tengo estas extrañas aficiones: capturar un bug comienza siendo algo desagradable que acompaño con un picante aderezo de blasfemias. Pero una vez entro en calor, se convierte en un placer con el que disfrutar que culmina con la explosión de una cápsula de felicidad. Si la capturas.

La cápsula ha terminado por estallar, parcialmente: he dado con una solución para el problema, aunque no están del todo claras las causas del bug, o es un bug con demasiadas variantes como para dar una respuesta simple y contundente. El problema se produce por una esotérica combinación de CSS, HTML y la presencia de un tag < style > dentro del < body > (me ha costado horas llegar hasta aquí, no se vayan a pensar). No he encontrado nada parecido documentado, y no me extraña. Aunque si he tenido el placer de conocer otros bugs del IE igual de absurdos o más.

El tag style aparece dentro del body para que el badge de Flickr incorpore sus estilos, así que no es plan el obligar al usuario a prescindir de él.

Tecnicamente un tag < style > debe estar dentro del < head >, o sea que no puede estar en el < body >, aunque esto no debería mandarte a hacer puñetas como hace el IE. Así que hay que tirar del hilo.

Si quitas el tag style, todo funciona. Si quitas el CSS, todo funciona. Pero su combinación es fatal. La solución de meter los estilos enlazando una hoja de estilo con un link hacía desaparecer el bug, aunque eso hubiese sido demasiado fácil. Tenía que saber quien causaba el problema. Así que el proceso consistía en ir quitando y poniendo elementos de la CSS hasta localizar al responsable. Llegado un momento pensé que era una locura tratar de averiguarlo, ya que el bug es tan poco obvio que probablemente se debía a una compleja combinación de elementos.

Pero le encontré.

Se trata de un float: right aplicado a un div anidado dentro de otro par de divs (que tampoco tienen gran complejidad en cuanto a su posicionamiento). Quitando este float: right el navegador no se cuelga.

He tratado de reproducir el problema con un HTML más limpio para dejarlo publicado y documentado, aunque no lo he conseguido. Todavía. Algún otro elemento del HTML participa en la combinación, y tengo que dar con él. Mañana espero poder reproducir el bug en un esquema más simple, aunque más para mi gloria personal que para el uso y disfrute del respetable, porque la combinación que produce el error es tan específica que pasarán al menos 100 lunas (que no 100 lunes) hasta que otro primo como yo pierda un día entero con este bug.

Ah, se me olvidaba. Mañana tengo que terminar el CSS alternativo al float: right para dejar el blog funcionando de forma correcta. Pero eso es lo de menos…

Al @media y a la Guadec

atmedia2006.jpg

Esta semana estaremos en Londres para asistir a @media 2006, conferencia con lo más granado del panorama del desarrollo web con estándares, o desarrollo con estándares web.

guadec.jpg

Y la última semana de Junio estaremos en la GUADEC, la conferencia europea de Gnome que este año tiene lugar en Vilanova i la Geltrú, al sur de Barcelona.

Al contrario que con otras conferencias del ramo, o ramos primos, el programa de este año del @media pinta muy bien. No hay ni una sola sesión dedicada a temas introductorios o básicos: todas tratan sobre los temas con los que trabajamos a diario pero desde una perspectiva que mira hacia el futuro.

Lo que si cabrea bastante es que todas las sesiones se solapan con otra igual de interesante. Hay dos sesiones de las que podría prescindir… y, efectivamente, coinciden.

La GUADEC se aleja bastante de mis ocupaciones diarias, pero espero que sirva para seguir alimentando el gusanillo y descubrir oportunidades para hacer cosas.

El Mundo quiere que juegues

rss-disponible.png El Mundo ha renovado (no se cuando) su página de RSS. Y se abren. O tratan de abrirse. Proponen un reto: que hagas cosas con sus datos, al igual que otros medios internacionales como el Washington Post o la BBC.

Es un buen comienzo, pero la pieza fundamental para poder hacer cosas realmente chulas es una API. Unos cuantos feeds con los últimos N posts no dan para mucho.

Por el momento ellos mismos se han inventado algunos ejemplos de uso. Lo más interesante es su nube de términos de las noticias de elmundo.es. ¿Qué os parece? ¿Qué cosa interesante se podría hacer con los datos que proporcionan?

Criterios de posicionamiento en buscadores

A raiz de mi amable diatriba del otro día sobre los profesionales dedicados en exclusivamente al posicionamiento en buscadores, Pacoo escribió un interesante comentario, listando una serie de criterios de posicionamiento que son parte de la especialidad de este tipo de empresas, y que se salen del trabajo estándar (chiste! chiste!) de esas otras empresas o personas que hacen webs-como-dios-manda.

Pues bien, voy yo, más chulo que un ocho (¿yo?) y digo que el 80% del posicionamiento natural en buscadores se consigue simplemente utilizando de forma correcta estándares web (y algunas buenas prácticas que van de la mano). Lo cual, concretando poco, consiste en:

  • Separación de presentación (CSS), contenido (XHTML) y, con la llegada de las tendencias 2.0, comportamiento (JS)
  • Marcado semántico: utilización correcta del XHTML (un title pertinente, encabezados, etc. Hay toneladas de artículos por ahí sobre este asunto)
  • Aparición de las palabras clave en las URLs
  • Enlaces lógicos en tu site (que la sección “Productos” esté enlazada por el texto del mismo nombre, etc)

(Cumpliendo estos puntos, además, te llevas una dósis considerable de accesibilidad… ¡gratis!)

Otro punto muy importante, y que tiene relación directa con la arquitectura de la información de tu site, es la densidad de palabras en una pagina, que comenta Pacoo, y/o el ratio de código/contenido. Consideramos código todo el XHTML/CSS y el texto irrelevante (aquel que no tiene relación con el objeto a posicionar) que haya en el documento web.

Si incluimos toneladas de menús o referencias a mil secciones dentro de nuestro site, o código prescindible (tablas para maquetar, fonts, etc), estaremos disminuyendo el ratio de código a contenido, y con ello disminuyendo la relevancia de nuestro documento.

Yo me preocupo de hacer buen código, y consigo unos resultados buenos (o eso me dicen y yo me creo). Y con muy poco esfuerzo ; el mismo que cuesta hacer las cosas bien, ni más ni menos. Aunque ahora que lo pienso, también añado un poco de mi pócima secreta.

PS: Otro día desarrollo el concepto de “posicionamiento natural” que he citado hoy, y que tiene que ver con ese épico tema, La Falacia De la Indexación.

Propuesta para un avatar estándar

Introducción prescindible

Cada vez es más habitual que en los servicios en los que te creas una cuenta de usuario te ofrezcan la posibilidad de añadir una imagen a la información de tu perfil. Igual que tenemos que repetir nuestros nombres y apellidos y otros datos personales en estos servicios, también nos encontramos con que acabamos subiendo la misma foto una y otra vez. Igual que no se ha conseguido un servicio de identidad universal para que cada vez que tengas que rellenar tu información personal puedas apuntar a una URL y el sistema cargue automaticamente tu información, es igual de utópico pensar en que si se proporciona una servicio universal de avatares vaya a ser implementado por los diferentes fabricantes.

/Introducción prescindible

Reducimos nuestro ángulo de visión para, en genuina tradición ala-microformatos, concentrarnos en tratar de resolver el problema más simple de la forma más abierta y asequible posibles.

Se trata de crear un estándar (¿microformato? ¿microestándar? ¿convención?) en el ámbito de las herramientas de publicación personal para permitir el autodescubrimiento del fichero que contiene el avatar del usuario.

Al principio pensamos en plantear el micro-estándar de modo que teniendo como URL del blog del usuario http://www.example.com/myblog/, el avatar fuese un archivo que siempre estuviese en una misma ubicación, del tipo http://www.example.com/myblog/avatar.* (siendo * una extensión de archivo gráfico, probablemente jpg o png).

Pero analizando brevemente la actual estructura de marcado de numerosos blogs, no es fácil que pase desapercibido en el head de dichos documentos un mecanismo que bien nos podría ayudar, que ya se usa para cosas equivalentes y que ofrecería más flexibilidad que la idea inicial. Presentamos al elemento link y su atributo rel. Al igual que tenemos otros muchos rels que nos apuntan la ubicación de los feeds, del pingback, del EditURL, etc., podemos utilizarlo para apuntar al avatar.

Se trataría simplemente de añadir un elemento link con un rel=”avatar” . Ej:

	< link rel="avatar" href="http://www.example.com/miblog/avatar.png" / >

Inspirados por la funcionad que ofrece gravatar.org, las herramientas de publicación personal podrían buscar y colocar automaticamente el avatar del usuario al lado de sus comentarios, a partir de la URL que este introduzca. Es decir, cuando yo escribo un comentario en un blog, y relleno los cambos “Nombre”, “Correo-e”, y “URL”, la herramienta iría a buscar el link rel=”avatar” en la URL que haya introducido. Si el link rel=”avatar” le proporciona un href, ya tendría la URL del avatar y podría pintarlo al lado del comentario.

Quedaría al gusto del fabricante la creación de mecanismos de cacheo para no tener que realizar el parseo del blog del comentarista por cada nuevo comentario, el almacenamiento del avatarUrl en su propia BD, etc.

Ventajas

  • Sistema absolutamente descentralizado que no plantea problemas de ancho de banda
  • Universal y abierto
  • Fácil implementación por parte de las herramientas de publicación

Objecciones

  • Si un usuario no tiene blog no puede disponer de esta funcionalidad
  • Un usuario puede querer disponer diferentes avatares

Comentarios a las objecciones

Ya vendrán, y ya se irán. Permanezcan atentos a sus receptores.

Sobre lenguajes XML (y más OPML)

Tim Bray (Atom, Sun) escribe un post titulado No Inventes Lenguages XML. En él, además de hacer un repaso al complicado proceso de creación de uno de ellos, opina que disponiendo de DocBook, ODF, UBL, y Atom y XHTML/Microformatos, no necesitas más (aunque eso ya lo dijeron Nacha Pop).

Es decir: con casi total probabilidad cualquier información que necesites proporcionar al mundo de forma estructurada para que sea tratada programaticamente en un proceso mecanizado encajará en alguno de esos lenguajes. No te hace falta inventar el tuyo propio.

Yo añadiría OPML (ya hablamos de ello aquí), otra irreverente obra de Dave Winer. Un mecanismo lo más simple posible para marcar listados de cosas. Precisamente en su simplicidad está la clave de su importancia: es muy fácil de implantar (y cuanta más gente lo implante, más utilidad tendrá, ya saben, eso de que el valor de una red está en el cuadrado del número de nodos), y se puede hacer multitud de cosas con ello (esto último no es muy preciso, si vuelvo a estar tan aburrido como para escribir un post de este tipo, listaré los usos que se me ocurren al efecto).

Todo este tiempo he vivido engañado, pensando en que la herramienta de OPML que hacía el señor Winer no tenía versión para Windows. Pero si la tiene. Investigando.

El diseñador web 2.0

¿Qué es un diseñador web? ¿Un diseñador gráfico, con formación, por ejemplo, en Bellas Artes, o un maquetador HTML sin un criterio estético demasiado desarrollado? A estas alturas de la partida va siendo hora de establecer unos rasgos generales para un diseñador web, y que todos entendamos lo mismo (lo de diseñador web 2.0 es un chascarrillo, que luego desarrollamos).

En mi humildísima opinión, un diseñador web tiene que tocar moderadamente cada uno de estos palos, y estar especializado en un uno de ellos (o más de uno):

Arquitectura de la información

  • Organización de contenidos, metadatos, taxonomías, navegación (más)
  • Usabilidad
  • Investigación y análisis, métricas e indicadores
  • Wireframes, prototipos, árboles de contenidos

Diseño Gráfico

  • Uso del color, composición, simbolismo
  • Fireworks, Photoshop, ilustración…

Programación cliente / Estándares web

  • Marcado semántico
  • Separación de presentación y contenido
  • Accesibilidad
  • XHTML / HTML
  • CSS
  • DOM, un poquito de Javascript

¿Programación servidor?

  • Con este punto tal vez estamos ampliando demasiado el espectro, pero en muchas ocasiones saber un poquito de programación servidor puede darte mucha cancha. Hay algunas herramientas muy sencillas de instalar y de personalizar que te permitirán montar webs de arriba a abajo, ya sea para algún encargo pequeño o para tu uso personal. En mi lista estarían: Drupal, Movable Type, WordPress, MediaWiki, phpMyAdmin

PS. En otro orden de cosas, desde hace tiempo me ronda la idea de crear un plan de estudios para curritos web. Lo había pensado montar en un wiki con licencia GPL para que aquellos centros de estudios que lo deseen, lo implanten. Quedaría chulo. ¡O montar la Universidad Furilo!

Lista de paises ISO

Hace tiempo en Blogold, el weblog de Ávidos, publicaron un interesante post sobre las listas ISO con los países del mundo, con un apunte a esta página donde te puedes descargar el código SQL para insertar esa lista de paises en una base de datos.

La única pega de esa lista es que los paises están en inglés.

Buscando brevemente una lista en castellano de esos países he llegado hasta la Wikipedia: http://es.wikipedia.org/wiki/ISO_3166-1. Justo lo que necesitaba.

Mi primer destino dentro de la Wikipedia fue esta lista de países del mundo, que tiene interesantes tema relacionados: Países imaginarios y países extiguidos.

Recopilación de recursos sobre estándares web

Estándares web – general

Layout

HTML/XHTML

CSS

Accesibilidad

Listas de Correo (en castellano)

Weblogs

Otros recursos

Organizaciones – Grupos

Ejemplos Sites diseñados con CSS

Más…