He aquí algunas semanas que me llamaron la atención.

La interfaz como parte de la comunicación

El blog  comienza su primer semana con el primer axioma de la comunicación de Paul Watzlawick (psicólogo constructivista referente de la teoría de la comunicación humana).

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

La escritura, el formato y los signos de puntuación

La escritura supuso un nuevo paradigma con respecto de la tradición oral, demandando al escritor una mayor atención sobre lo escrito, la elaboración de los enunciados, la organización de los contenidos, la puntuación de los mismos.

Si consideramos a las interfaces como componentes que permiten la interacción entre sistemas, quizás podríamos pensar en la escritura como la interfaz entre las personas y el conocimiento. Si nos tomamos esta licencia, (Sr. Juez si continúo un poco más, verá cual es mi punto) podemos pensar en la función de los signos de puntuación (punto, punto y aparte, punto y coma, coma) como aquellas que reproducen las pausas, largas y cortas, expresiones de admiración y  dudas necesarias para el correcto entendimiento de la palabra escrita.

Los signos de puntuación requieren de un uso conocedor; si se ponen en el lugar equivocado, las palabras y las frases pueden no tener significado o adquirir uno completamente distinto.  Esto se puede ver en el siguiente ejemplo.

En un texto de la Eneida, de Virgilio, época en la que todavía no se utilizaban los espacios para separa las palabras, se podía leer:

C O L L E C T A M E X I L I O P U B E M

Lo cual tenía dos lecturas posibles:

1. collectam ex Ilio pubem –> un grupo de personas procedentes de Troya
2. ocollectam exilio pubem –> un pueblo reunido para el exilio

La lectura de los libros antiguos fue, durante mucho tiempo, una real odisea.

El siguiente es otro ejemplo acerca de cómo los signos de puntuación ayudan o desalientan la comprensión de los textos.

Historia Signos de Puntuacion

El texto como interfaz

En un contexto web el texto adquiere una nueva función más allá de interactuar con el contenido, se convierte en interfaz.

Como contenido, el texto cumple la función de informar, comunicar, describir, enseñar, guiar, como interface el texto brinda información sobre el contexto. el formato del texto, ayuda a reforzar esta idea ya que las diferencias que aporta el mismo muchas veces sirven para guiar la atención del usuario hacia ciertos espacios o ayudarlos a escanear la información en pocas barridas.

Con el surgimiento y asentamiento de la web 2.0  aparece el rol proactivo del usuario como generador de contenidos, con lo cual también debemos considerarlo como generador de interfaces, sobre todo pensando en el uso exhaustivo que los mismos hacer de plataformas como facebook, twitter, blogs, etc., ya no se “escribe”, se “habla en formato texto”.

Como diseñadores de interacciones no debemos descuidar la importancia de los textos dentro de la misma, hay que tener en cuenta los nuevos formatos, las restricciones sociales y tecnológicas, los significados y contradicciones que estas nuevas formas de interacción textuales están generando.

Enlaces recomendados

• Henciclopedia: Textura de laberinto
• Paraorthographic Linkage Hypothesis: Orthography and Eye Movements
• A list apart: Calling All Designers: Learn to Write!
• Information Architects: Web Design is 95% Typography
• UseIT: Twitter Postings: Iterative Design

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Enlaces recomendados:

• Microsoft Office Labs: Envisioning

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

“El diseño de interfaces sociales  es aún un campo en pañales…

… En los comienzos de la usabilidad, las compañías de software reclutaban expertos en ergonomía y en factores humanos (¿antropometría?)  para ayudar a diseñar productos usables….

… Eventualmente el diseño de interfaces de usuario recibió el lugar que le correspondía respondiendo con conceptos tales como consistencia, afordabilidad, respuesta, etc., los cuales se convirtieron en la piedra angular de la ciencia del Diseño de Interfaces de Usuario…

…Durante la próxima década, espero que las compañías de software contraten antropólogos y etnógrafos para trabajar en el diseño de interfases sociales en vez de construir laboratorios de usabilidad…”

Es una buena reflexión sobre la intervención de diferentes perfiles en las nuevas disciplinas que tienen que ver con diseño, internet y sobre todo lo social, el diseño de la interacción social (SxD) recoge retazos de sabiduría de varias disciplinas algunas bastante nuevas: Arquitectura de la información (IA), diseño de la experiencia de usuario (UxD), Diseño de la Interacción (IxD), Usabilidad, Psicología cognitiva, Sociología, Antropología y muchas otras.

En este sentido se hace una crítica a los expertos que colocan la usabilidad como la solución a todos los problemas y el testing de usuario como el camino pavimentado directo al paraíso al exponer que dentro del diseño de interfases sociales la usabilidad no lo es todo, ya que aún teniendo resuelta la usabilidad de una interfase,  todavía hay que resolver los temas que involucran el diseño social, éste último es más importante.

Una aplicación que brinde un servicio muy apreciado por los usuarios puede tener un muy bajo nivel de usabilidad y aún así los usuarios la adoptarían, de la misma manera una aplicación puede ser muy usable pero si no hace algo que alguien quiera, no tendrá éxito, esto un poco explica como algunas interfases terribles  no solo fueron adoptadas sino también usadas hasta el hartazgo más allá de la pobre usabilidad que presentaban. Y en franco desafío a los postulados de Jakob Nielsen (Ojo, no estoy en desacuerdo con él en el contenido, quizás un poco en la forma) sostienen que una experiencia realmente buena puede transformar el medio en irrelevante.

¿Entonces la usabilidad no sirve? No, nada de eso, simplemente que en estos nuevos escenarios donde la interacción pasó de human-computer a human-human el aspecto social de las interfaces cobra una gran relevancia, lugar que antes estaba destinado única e indiscutiblemente a la usabilidad.

En el medio social prima la experiencia social sobre la experiencia del usuario, la interacción es más compleja que en un contexto no-social, en el diseño centrado en el usuario se le da un lugar de importancia a los objetivos y las necesidades de los usuarios, en un contexto social no existen estos parámetros o suelen ser lo suficientemente diversos como para no servir de patrón, el usuario no interactúan solamente con un sistema, hay otros usuarios interactuando a su vez con el sistema y entre sí.

Joshua Porter, autor del libro  Designing for the social web, define la interacción social como lo que posibilita que los usuarios se relacionen entre sí y mediante esta relación mejoren su experiencia a través de la actividad social que se les propone, el diseño de esta interacción es algo más integral que añadir funcionalidad, es comprender cómo los usuarios interactúan socialmente y diseñar inteligentemente para alentarlos.

En IDEA 2009 Christian Crumlish y Erin Malone autores del libro Designing Social Interfaces de la editorial O’Reily  presentaron: Designing Social Interfaces: 5 steps, 5 principles, 5 anti-patterns. La presentación contiene una serie de principios de diseño web y patrones de interacción para ser tenidos en cuenta para los encargados de delinear la experiencia de los usuarios.

Designing Social Interfaces: 5 steps, 5 principles, 5 anti-patterns

¿Puntos a destacar de la presentación?

Los 5 pasos:

1. Brindarle a los usuarios una forma de identificarse y ser reconocidos
2. Que la red social tenga un objetivo válido, las personas suelen agruparse en torno a intereses.
3. Darle a los usuarios algo para hacer, taggear, armar galerías de fotos, comentar, recomendar, son acciones que logran la pertenencia de un usuario a la comunidad a la vez que lo entretienen y lo definen también.
4. Habilitar un puente con los eventos de la vida real, dejar que la vida real se nutra de las experiencias de la red social y viceversa
5. Permirtir que la comunidad juzgue y premie a pares y contenidos que les resulten de valor

Los 5 principios

1. “Pavimente los “senderos de las vacas” la gente  no siempre va por donde se espera, averigüe qué están haciendo y facilítelo.
2. “Hágalo personal”, hable como una persona, converse, a las personas les gusta escuchar a otras personas, no robots.
3. Sea abierto, interactúe con los demás, genere idas y vueltas
4. Aprenda de los juegos, la reputación o los sistemas de puntaje lo hacen más divertido
5. Respete la dimensión ética. Hay una línea muy delgada entre la dispersión viral del spam, tenga en cuenta que a la gente no les gusta el spam y lo odiarán si lo pone en práctica.

Los 5 anti-patrones (lo que hay que evitar)

1. No intente imitar sin entender cómo o por qué los modelos originales tienen éxito
2. No destierre el email, las personas lo usan y lo aman. Saque ventaja de los comportamientos, hábitos y herramientas que utilizan los usuarios
3. No fuerce a los usuarios a entregarle los passwords de sus cuentas en otras comunidades, hay muchas formas de lograr las conexiones entre las personas.
4. Permita a los usuarios agrupar amigos y establecer permisos basados en esas agrupaciones para la visualización e interacción de los contenidos o acciones entre los usuarios. A esto lo llaman el bug del ex novio :)
5. Finalmente lo que denominan Pueblo Potemkin o la posibilidad de generar espacios (o funcionalidades también podemos interpretar) vacíos para impresionar a los usuarios, esto generalmente no funciona, la mejor estrategia es dejar que los usuarios vayan construyendo esos espacios o demandándolos a medida de sus necesidades.

Hasta aquí llegamos hoy es un tema muy amplio e interesante, me acaba de llegar (tarde pero seguro) la invitación para testear Google Wave así que estoy ilusionada como nene con juguete nuevo, ya les contaré!

Hasta la próxima.

Enlaces recomendados:

• Wiki: Designing Social Interfaces
• Joel on software: It’s Not Just Usability
• Bokardo: A simple illustration of social design
• Johnny Holland Magazine: A Social Interaction Primer

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Una de las primeras impresiones que tuve fue de desconcierto. Digo desconcierto porque me costo muchísimo entender como se realizaban las acciones en la aplicación. Creo que cometieron todos los errores de usabilidad y diseño existentes.

Esta aplicación posee, además, la funcionalidad de carga de horas a dichas solicitudes. Es decir, permite registrar cuantas horas una persona le dedico a una solicitud en particular.

En este articulo analizaremos en profundidad esta función de carga de horas.

Cuando un usuario desea registrar las horas de su trabajo, ingresa a la siguiente pantalla:

Ilustración 1- Interfaz de Carga de Horas

¿Qué tiene de malo esta interfaz?

Si de un único intento, logra entender como registrar horas de su actividad, entonces forma parte un selecto grupo de iluminados.

Hemos realizado pseudo pruebas de usabilidad con gente interna del equipo y hubo quienes no pudieron ingresar sus horas correctamente. Veamos que tiene de malo esta imagen y que acciones podríamos tomar para mejorarla.

1. ¿Cómo está pensada la interfaz?

Primero, antes que nada, analicemos más detalladamente en que consiste la interfaz.

En el caso de que no lo hayan notado, hay una cierta lógica en la interfaz. La misma se encuentra dividida en 5 zonas, a saber:

• Zona 1: Encabezado de la Aplicación
  Contiene el nombre de la aplicación (Qué ocultamos en la imagen) y el nombre de la funcionalidad que estamos ejecutando, en nuestro caso, la “Carga de Horas”
• Zona 2 : Filtro de Solicitudes
  Aunque este confuso, en esta zona se pueden filtrar las solicitudes que se listan en la zona 3. Hay 2 filtros, uno por palabras clave y otro por área de la Software Factory. Cabe destacar que hay dos comportamientos diferentes. Si se busca por palabra clave, se debe presionar el botón filtrar. Si se busca por área, solamente se selecciona una opción del combo box.

  De más esta decir que al utilizar cualquiera de los 2 filtros el sistema no muestra ningún mensaje acerca de si se aplicaron los filtros o no, violando una de las reglas de oro de Schneiderman, la de ofrecer feedback al usuario.

• Zona 3: Carga de Horas
  Está es la sección que más le importa a un usuario. Aquí se registran las horas de su actividad. Todo en una línea. Las solicitudes seleccionables son las que resultan de aplicar el filtro de la zona 2.

  Por defecto, se encuentran en el combo todas las solicitudes activas. Un problema de esta decisión de diseño es que cuando hay más de 200 solicitudes activas, el combo no es la mejor opción para buscar algo ya que la lista se torna muy larga. Creo que es por ello que se decidió implementar el filtro de la zona 2.

  Para guardar el registro, en el extremo derecho están las clásicas acciones de todo formulario: Aceptar o Cancelar

• Zona 4: Listado de horas previamente registradas
  Quizás, al ver la pantalla por primera vez, se preguntaron porque había botones de “Duplicar” o “Eliminar”. Bien, es porque al final de la pantalla, si hubieran, se listan todos los registros de carga de horas del usuario. Ese listado lo veremos más adelante.

  Las acciones de los botones actúan únicamente sobre los elementos de ese listado.

• Zona 5: Menú de Navegación de la aplicación
  Por último, un botón de volver. Este nos permite ir al menú principal de la aplicación y así poder acceder al resto de las funcionalidades. En cierta forma, es un history.back() del navegador. No nos permite saltar directamente a otra funcionalidad, tenemos que pasar siempre por el menú principal.

2. Problemas que existen en esta Interfaz

Bien, ya dimos una vista rápida a que es lo que se puede hacer en la interfaz. Ahora veamos que puntos débiles tiene. Antes de seguir, recordemos que el objetivo es registrar las horas de nuestro trabajo
Interfaz Visual y Separación de Conceptos

El primer problema que podemos encontrar es que, a simple vista, no se puede definir dónde tengo que trabajar. Todas las acciones están en el mismo bloque. Alta, consulta, edición y el filtrado.

Parte de la causa es que la interfaz no resalta los diferentes elementos que la componen. Todo incluido en lo que parece ser un único bloque. Se utilizan colores muy suaves que hacen que la pantalla sea “plana”. Otro problema que hay es que tanto los combos seleccionables como los botones de acción tienen el mismo estilo. Esto dificulta el reconocimiento de que elementos se utilizan para accionar y que elementos se utilizan para completar información.

¿Qué sucede entonces? El usuario debe primero ver la interfaz, leer toda la información que hay en ella, pensar y recién después de realizar todo ese trabajo, encontrará la sección en donde debe cargar las horas. En los usuarios menos experimentado, este punto fue el más débil. La pregunta más común termino siendo:

¿Y donde registro las horas?

Veamos un ejemplo de la pantalla con toda la funcionalidad expuesta.

En esta imagen aparece el listado de horas ya registradas por el usuario. Sobre ese listado, se selecciono un elemento. La selección de este elemento dio error. ¿Pueden verlo? (Si no lo ven, sigan leyendo)

Otro problema que se divisa aquí es que, con el listado de horas ya registradas, la edición no se realiza sobre el registro seleccionado, sino que se realiza sobre los campos para dar el alta del registro. O sea, una misma zona cumple dos funciones diferentes.

Los engañe, ¿Creían que la zona 3 era solo para dar de alta registros?. Se equivocaron. Sirve también para modificarlos. Ahora bien, ¿Qué sucede con los botones de aceptar/cancelar? ¿Qué estoy aceptando o cancelando ahora? ¿Creación o edición?

No lo sabemos con certeza, tenemos que pensar que estábamos haciendo para poder deducir que significan el aceptar y el cancelar.

Estos son algunos de los problemas que surgen cuando reutilizamos mal los componentes que tenemos. Noten además, que el registro seleccionado, si bien está “resaltado”, no tiene el checkbox seleccionado, generando la duda: “¿Estoy trabajando con este registro o no?”. Esto es una inconsistencia en la interfaz.

Modelo conceptual de acciones

Otro punto, es la forma conceptual que se definió para realizar la acción. En principio, el modelo seleccionado es el de: filtrar -> completar registro -> guardar

¿Qué significa esto?, que para poder realizar la acción de cargar horas, primero tenemos que filtrar la información existente. Una vez que filtramos, podemos completar el registro con nuestra información y de ahí guardamos. Es decir, al clásico ABM (Alta-Baja-Modificación), para poder hacer el alta, anteponemos el Filtrado, convirtiéndose en un FABM (Filtro-Alta-Baja-Modificación).

Esto tiene como problema que el usuario no esta acostumbrado a filtrar para poder dar de alta un registro. La tarea que quiere hacer es dar el alta y es por ello que busca dónde dar el alta. No imagina que primero tiene que filtrar, aún cuando el filtro es el primer elemento de la interfaz. Filtrar no forma parte en su modelo mental de la acción que quiere hacer, qué es guardar.

Mensajes de Error

Algo que no se pudo mostrar en la primer pantalla es la presentación de errores. La aplicación no diferencia cuando una acción se realizó correctamente y cuando no y utiliza la misma zona de la pantalla para mostrar mensajes de resultado correcto e incorrecto.

A continuación una imagen que muestra el mensaje de error asociado a la selección incorrecta de una fecha:

¿Fácil de notar, no?

El texto nos indica que hay un error en el formato decimal de horas, cuando lo que hicimos fue registrar una fecha incorrecta (35/35/2009). El primer problema es el mensaje en sí ¿Formato decimal para horas? ¿El error no es que deberíamos ingresar una fecha en formato dd/mm/aaaa y que sea válida?. En esta aplicación, los mensajes de error no condicen con el error en sí mismo.

El segundo problema, es que el sistema no destaca el error ni nos posiciona donde ocurrió, queda a criterio del usuario determinar cual fue la causa del error y dónde se produjo.

Y por último, todos los errores de las diferentes zonas se muestran en el sector remarcado en la imagen, por lo que resulta muy difícil determinar de que zona proviene el error. ¿De un alta de registro?¿Al filtrar?¿Al consultar?

Este problema con los errores es quizás el más crítico, ya que lo que deseamos es que se registre correctamente las horas. Ante esta liviandad en el tratamiento de errores, un usuario pudo haber pasado por alto un error y no haber registrado las horas, creyendo que si lo había hecho.

3. ¿Qué mejorar?

Tenemos ahora una lista de temas que podríamos mejorar. Veamos como podemos solucionar estos puntos encontrados.

No hacer pensar al usuario
El primer problema que nos encontramos es que el usuario tiene que pensar como tiene que hacer lo que quiere hacer.

Steve Krug, en su libro “Don’t Make Me Think! A Common Sense Approach to Web Usability” plantea una serie de principios para el diseño de sitios web que bien podrían trasladarse a esta aplicación. Dentro de los conceptos introducidos en el libro plantea que el usuario no debe tener dudas acerca de donde se encuentra lo que quiere hacer.

En esta aplicación, cuando el usuario ingresa por primera vez, intenta identificar donde tiene que registrar horas y queda mareado con la interfaz. Hay muchas cosas todas juntas, y demora un tiempo en determinar donde debe registrar las horas. Obviamente, luego de un tiempo, se acostumbra y ese tiempo inicial perdido disminuye.

Centralizar el foco en la tarea que quiere hacer el usuario

Alineado con la idea anterior, se debe lograr focalizar al usuario en la tarea que debe hacer. En este caso, el principal caso de uso es el registro de horas. El resto (consultar, editar registros) son secundarios.

La interfaz lo debe posicionar donde tiene que trabajar y el resto acompañar a la tarea. Aquí sería la zona de carga de horas. Esa es la zona más importante de esta interfaz. Deberíamos reposicionarla para que sea lo primero que el usuario vea en la pantalla.

El filtrado es otro punto que debería desaparecer. El filtrado solo debería usarse para realizar consultas sobre registros existentes. En este caso, se lo utilizo como mecanismo para acotar las solicitudes en las que el usuario puede registrar horas. Lo recomendable es que el mismo sistema sepa en que solicitudes está trabajando el usuario y por defecto en los combos de carga sólo aparezcan esas solicitudes (En el caso real, se muestran en el combo todas las solicitudes activas).

Dividir conceptos

Cerrando el punto anterior, si queremos agregar los casos de uso secundarios, como ser la edición y la consulta de registros, estos deberían aparecer como conceptos separados y como una funcionalidad aparte.

Se tienen que separar lo que es alta de consultas y separaciones, aún cuando esto no implica que no puedan compartir la misma pantalla. Una opción sería el uso de menús de acciones, aunque no es la única opción.

Lo importante aquí es las diferentes funcionalidades no mezclen componentes de otras zonas. Si hay que editar, se debe utilizar elementos diferentes que los de alta. O bien, si queremos reutilizar el alta, tenemos que dejar en claro que esos elementos ya no se utilizan como alta sino como edición. Esto implicará, seguramente, cambiar las etiquetas de los botones de acciones o resaltar en algún lugar que se esta editando y no.

La mejora del “Look And Feel” también puede ayudar en la división de conceptos. Utilizando estilos bien definidos y diferentes para cada acción se logrará el efecto de separación de acciones.

Una propuesta de Mejora

La siguiente imagen muestra una opción de mejora aplicando los conceptos mencionados anteriormente. Es una opción, puede haber otras, pero la idea es mostrar como reordenando conceptos y aprovechando tecnologías existentes (Estilo Web 2.0) se puede mejorar una interfaz existente, con el fin de facilitar la tarea del usuario.

En esta interfaz, se modifica drásticamente los estilos de la aplicación. Se aprovecha al máximo el uso de AJAX para recuperar la información asociada al usuario y se divide la interfaz en 4 zonas bien definidas, a saber:

• Zona 1: Registro de Horas
  Al ingresar, se posiciona al usuario en esta zona. Registra la información completando el formulario y el sistema le presenta únicamente las tareas y proyectos en los que participa y puede registrar horas. No es necesario filtrar, el sistema se encarga de ello.
• Zona 2: Consulta de registros existentes
  En esta zona, se listan, separados por día, los registros de horas que el usuario ya creo. La edición se realiza sobre el mismo registro.

  La idea es utilizar el concepto de vistas planteado por diversas aplicaciones, principalmente las de correo electrónico como por ejemplo Outlook o Gmail.

• Zona 3 : Acciones disponibles sobre el registro
  Al igual que en Outlook, al seleccionar un registro de la zona 2 se habilitan las acciones existentes para ese registro. Cualquier funcionalidad extra que se puede realizar sobre los registros, se lista en esta zona. Un ejemplo es la eliminación de registros o la repetición de registros.

  Zona 4: Navegación
  La última zona contiene el menú de navegación de la aplicación. Este menú permite navegar las diferentes funcionalidades que brinda la aplicación.
  En este caso, se puede saltar a diferentes funciones sin necesidad de ir al menú principal.

  Además, se muestra información de soporte al usuario (Cuanto le falta registrar en el día, exportación de registros, información del usuario, etc).

Si bien esta interfaz también puede mejorarse, plantea un salto muy grande respecto del punto inicial.

4. Conclusión

Hemos visto como una aplicación resolvió una problemática de registro de horas. Vimos también que puntos débiles tenia y como mejorarlos.

Siempre durante el mantenimiento se plantea si es necesario realizar mejoras de interfaz. La realidad indica que depende mucho del contexto en que se use la funcionalidad.

En este caso planteado, la funcionalidad es critica y utilizada por varios usuarios. La interfaz original no fue “diseñada” con una visión de usabilidad ni se intento disminuir el tiempo que tardan los usuarios en registrar su esfuerzo, por lo cual un cambio en la interfaz sería significativo e importante para los usuarios. Con lo cual, si sería necesario el cambio.

Como idea final, desde mi punto de vista, a veces es muy importante analizar el uso que se le dará a una interfaz y diseñarla para que sea los más simple de utilizar como sea posible, ya que cualquier cambio en la etapa de mantenimiento puede inducir a un esfuerzo demasiado grande para poder realizar el cambio deseado.

En otras palabras, hacer bien las cosas desde el principio.

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

En 2014 Google lanza EPIC (Evolving Personalized Information Construct) que es un sistema informativo en donde cualquiera puede contribuir a través de sus blogs, imágenes, videos, reportajes caseros, etc. y por sus aportes reciben beneficios en forma proporcional a la popularidad de éstos (algo cercano a la teoría de la larga cola que se da con adsense). Estos aportes se concentran y son usados para crear información a medida de cada usuario (utilizando la inteligencia de las redes para recabar datos de preferencias, consumo, datos demográficos, datos sociales) por parte del sistema sin intervención alguna de periodistas.

EPIC 2014 nos muestra la evolución de los medios de comunicación y cómo la industria de las noticias en papel es afectada  por el crecimiento de las noticias en línea, plantea una guerra entre los nuevos medios y los tradicionales (representados por  Google+ Amazon y en la otra esquina The New York Times). Esta guerra termina con la desaparición de los medios de comunicación tal como los conocemos dejando su espacio a los contenidos generados por el usuario en ambientes colaborativos.

Por supuesto que GoogleZon no existe, tampoco existen EPIC o el Museum of Media History, los hechos reales se relatan desde 1989 a 2004, luego de ello, es especulación basada en las tendencias, mucho de lo que se propone en esta suerte de ensayo sobre el futuro tiene un asidero en la realidad, y es allí donde reside la relevancia de este video más allá de que sus predicciones no se cumplieron tal cual… por ahora…

Aquí está la  actualización de Epic 2014, llamada Epic 2015:

Pero todo esto pasó en 2004, todavía recuerdo el asombro al verlo, ese tipo de videos no eran moneda corriente como hoy en día, era algo tan… real que se quedó muy profundo impreso en mi memoria, y volvió a surgir  cuando recibí la noticia del lanzamiento de Google Wave.

Google wave es un nuevo producto todavía en etapas de desarrollo y por ende, no abierto al público, según ellos mismos es un producto mágico: una herramienta personal de comunicación y colaboración desarrollada por las mismas personas que hicieron posible Google maps.

Durante el video de presentación, de 1:30 hs de duración  los líderes de este proyecto desarrollaron la idea de cómo luciría mi mailer si fuera diseñado hoy, con el conocimiento actual de la web 2.0, los mensajes instantáneos, sms, redes sociales, blogs, y todas las formas de comunicación que hoy en día son tan naturales para nosotros.

Mostrando funcionalidades en las que se mezclan el mail y el chat, sin saber al final cuales son los límites de cada herramienta (con ciertas reminiscencias de Facebook) , mostrando una suerte de convergencia de herramientas propias de la web 2.0 (wikis, blogs, herramientas de construcción colaborativa, hosting de imagenes, de videos, entre otros.),  incorporando funciones de drag and drop todo integrado en tiempo real (verdadero tiempo real) en un producto open source, que corre integramente dentro de un navegador integrando servicios que hasta hoy siguen fragmentados, Google podría posicionarse en la cresta de la próxima ola (valga la redundancia).

Aquí va el screenshot de Google wave que aparece en todos lados:

Y aquí el video de presentación (interesante, si se bancan lo que dura):

Hay quienes dicen que este tipo de plataforma podría dejar obsoletas aplicaciones como Facebook, Flickr, los Wikis, MSN Messenger, inclusive aplicaciones de weblog tan importantes como WordPress, el tiempo dirá si habrá guerra o integración, es muy probable que esta última si queda en manos de comunidades open source.

También es probable que Wave se constituya como una nueva forma de pensar la interacción con otros, unitaria y colaborativamente, sobre todo por su potencial integrador de herramientas y funcionalidades que hoy no se comunican entre sí o no lo hacen de una forma transparente, así como ubiquity se convirtió en una herramienta para mí indispensable a la hora de gestionar información, parece que Wave será la manera en que esa información se distribuya, convirtiéndose en la próxima plataforma de comunicaciones masiva, no estaría mal una integración más estrecha entre estas dos fabulosas herramientas.

EPIC 2014 termina su narración diciendo “Quizás hubo otra manera” y así parece finalmente no será GoogleZon, será Google Wave. Soy conciente que hay temas más de fondo sobre Google y su avance hacia el monopolio, cuestiones que no niego ni acepto, sino que dejo que aquellos que conocen del tema  se explayen sobre ello.

Hasta la próxima!

Enlaces recomendados

• Wikipedia: EPIC 2014
• Poynter On Line: EPIC 2014: The Future is Now
• ISACA: When Chaos Rules, Only the Fittest Survive: The Impact of Disruptive Technologies on Organizational Survival
• Pub-chews: The new and shiny
• WWWhat’s new: Google Wave – La guía definitiva
• CristaLab: Google Wave, todo lo que tienes que saber
• Internet.com: Google Wave: Faster Response Times
• Lifehacker: The Google Wave Highlight Reel

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

De seguro que las empresas que lanzaron estos equipos tomaron un gran riego al hacerlo con la esperanza de quedar en la cresta de la ola. Los modelos son diversos, algunos carecen de funciones escenciales otros suman features de última tecnología, también hay diseños bizarros, pero como se dijo en el artículo sin estos nobles fracasos, quizas el iphone no hubiera sido posible.

¡Hasta la próxima!

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Este es otro de los soplos que me pasa Diego Ferreyra, que no se como hace para encontrarlos.  Además muy bueno el prototipado, simple y claro.

¡Hasta la próxima!

Enlaces Recomendados

• YouTube: GMail Art – Google

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

En el corto presenciamos el entrenamiento de un extraterreste tratando de abducir a un humano dormido de su casa a través de unos tableros de comando de pesadilla, mientrar un superior lo evalúa con cara inmutable anotando en su libreta cada paso en falso.

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Este tipo de semilla tiene una especie de ala adosada que le permite, al desprenderse del árbol ser arrastrada por el viento lejos de su origen, este mecanismo permite que las especies se diseminen.  En honor a la verdad no es que el ala ayude a la semilla a volar, sino que su forma helicoidal retrasa la caída de forma que pueda ser arrastrada por el viento.

En la imagen se ve muy clara el ala, muchos diseños de la naturaleza son asombrosos y resuelven problemas tan importantes como la supervivencia de las especies de forma simple.

La  biomimética es la disciplina que se encarga de estudiar y aplicar los sistemas de la naturaleza en la ingeniería y la tecnología, desarrollando, a través de los años numerosas innovaciones aplicadas a problemas de todos los días que la naturaleza ha sabido resolver en forma efectiva. Robert Full ha estudiado durante años las extremidades de las cucarachas y lagartijas para crear un pie de robot eficiente basado en la evolución de la naturaleza

Andrew Parker, biólogo evolucionista opina que cada especie, incluso las extintas, representa una historia de éxito perfeccionada a través de millones de años de selección natural. ¿Por qué no aprender de lo que ha creado la evolución?

Es un tema apasionante, y del cual no tenemos que mirar muy lejos para ver ejemplos.

Enlaces recomendados:

• National Geographic: Biomimetics: Design by Nature

• Wired: Ideas Stolen Right From Nature

• La Versión Cuántica: ¿Qué es y para qué sirve la Biomimética?

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Si bien el estudio abarca muchas áreas que van desde las interfaces hasta los precios de las aplicaciones que se pueden agregar, algunos pocos puntos me llamaron la atención, acerca de cómo los usuarios entienden e interactúan con el dispositivo, por ejemplo:

Ninguno de los usuarios principiantes entendió cómo se usaba el botón (x) que se encuentra a la derecha de la barra de direcciones del navegador, es más  confundían su funcionalidad (resetear la info de la barra) con el botón “ir” del explorer que carga en el navegador la url ingresada, en este caso los resultados obtenidos eran lo opuesto a lo buscado, esto tiene que ver con el hecho del mapeo que los usuarios hacen de las funcionalidades y lugares comunes de un navegador tradicional.

Se puede ver también que documentan confusiones del usuario con la iconografía, en un dispositivo que posee una pantalla diminuta para navegar en internet, la posibilidad de magnificar lo que se está viendo se convierte en una necesidad, en los casos testeados se ve que los usuarios (no mencionan la proporción pero sería interesante conocerla) confunden tanto el ícono de buscar (que es una lupa) como el de más funcionalidades (que es el símbolo de la suma +) con el zoom de la aplicación.

Otra cuestión a destacar es la falta de consistencia tanto en la ubicación de las acciones como en la funcionalidad detrás de los íconos. Se ve, por ejemplo cómo el ícono más (+) es utilizado en la aplicación Calendar para añadir entradas, en World clock para añadir un nuevo reloj, pero en el browser se usa para mostrar otras acciones que se pueden realizar.

Este tipo de información sólo es posible conseguirla a través del testeo con usuarios, es muy importante poder ver al usuario interactuando con la interfaz real, con usos y tareas reales, esto nos ayuda a detectar problemas que probablemente no saldrían a la luz hasta poco despues del lanzamiento de los productos en el mercado.

Hasta la próxima!

Enlaces recomendados:

• Uselog.com: iPhone Usability Studies
• The design of everyday things

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Hace poco más de un año Microsoft presentó Surface, una interfaz interactiva que permite el manejo de contenidos digitales a través de movimientos y gestos de las manos,  así como manejo integral de las comunicaciones o la interconexión con otros dispositivos , un abanico que va desde teléfonos móviles hasta tarjetas de crédito, cámaras de fotos, etc, las posibilidades? Se pueden vislumbrar en este video:

También a principios de este año ya hablábamos del Morph Concept desarrollado por el Nokia Research Center y la Universidad de Cambridge, el cual muestra las potenciales funcionalidades de un dispositivo móvil flexible gracias a la integración de nanotecnología. Quizás ya dentro de no mucho podremos ver estos conceptos aplicados a la interacción diaria entre las personas y las TIC.

En estos días se regó la noticia de que una empresa llamada Oblong Industries, de la cual uno de sus fundadores trabajó como consultor del equipo de Spielberg para la película Minority report, ha  desarrollado un entorno operativo llamado g-speak el cual plantea una interacción con el mundo digital a través de movimientos espaciales de los guantes que se representan en las pantalla.

Este escenario plantea toda una serie de mapeos entre gestos y acciones, como por ejemplo mover objetos para un lado u otro de la pantalla con el simple movimiento del brazo o girarlo con una rotación de la mano, atraerlo hacia uno con el movimiento de retraer la mano hacia el cuerpo, o asir un objeto cerrando un puño a su virtual alrededor, que replantean los movimientos en dos dimensiones de un mouse para darle la bienvenida a movimientos en 3 dimensiones:

g-speak overview 1828121108 from john underkoffler on Vimeo.

Enlaces recomendados:

• YouTube: Microsoft Surface Parody
• petitinvention: Better Designs for a Better Life
• Interaction design: Interaction design a la minority report
• TechEblog: G-Speak: Gestural Interface Technology

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Los formularios vienen acompañados de botones para realizar acciones en combo, por ejemplo Aceptar/Cancelar.  Si tomamos en cuenta el perfil general de nuestros usuarios: occidentales que leen de izquierda a derecha, los comportamientos más frecuentemente usados del combo deberían estar a la izquierda y los no tanto a la derecha, entonces, ustedes qué creen? en un formulario, el botón de aceptar debería estar a la derecha? o a la izquierda? y el de cancelar?

A mi entender, “Aceptar” es la opción principal, a menos que se equivoquen, se arrepientan o pase algo excepcional, los usuarios no suelen cancelar formularios luego de empezar a llenarlos, entonces la acción de Aceptar debería estar a la izquierda y la de Cancelar a la derecha, no?

Hace unos días, al tratar de suscribirme a un Journal no entendía por qué, luego de terminar de llenarlo, me mostraba de nuevo el formulario vacío en vez de una página de confirmación, luego de que me pasara 2 veces, decidí prestar atención al proceso y me di cuenta que estaba apretando el botón de cancelar en vez del de guardar porque los habían puesto al reves de mis suposiciones.

He aquí la impresión de pantalla del formulario, como se ve en el área donde están los botones con las acciones (Clear form a la izquierda y Send Form a la derecha) hay un cartel resaltado en rojo que dice: Usted debe hacer clic en el botón “Send form” para completar el registro. Esto me hace pensar en que mucha gente debe equivocarse, al llenar el formulario. Pero no nos confundamos, los usuarios no son los que están errados, los que están errados son quienes realizaron esta página y cuando vieron que el número de errores crecía en vez de solucionarlo cambiando los botones de lugar, lo parcharon con un cartel.

Sin embargo no es el único ejemplo que encontré, en la siguiente imagen, de las interfases del MT 4, podemos observar que cuando se abre la ventana para publicar el sitio la acción más a mano que ofrece el formulario (contrario al imaginario popular) es Cancelar, la diferenciación por color (Gris para cancelar y azul para publicar) no sirve en este caso porque el gris del botón cancelar no es lo suficientemente claro como para darme la idea de segunda opción.

Este año llegó a mis manos los secretos del futuro de Arthur Clarke, escrito en 1962, en el  que especula con el futuro y próximos descubrimientos para fechas tan lejanas en ese entonces como 1982, si es que la humanidad no se ha destruido para esas épocas como reza la contraportada. Al final del libro  hay una suerte de calendario de inventos y progresos en una línea de tiempo que va desde el 1800 hasta el 2100, como habrán imaginado, todo lo que esa línea de tiempo expresa a partir de 1962 es futurología casi en estado puro. Podemos encontrarnos entonces que para el año 2000 se predijo la Colonización de planetas o para el 2010 el control del clima.

¿A qué viene todo esto? no soy tan pretenciosa del futuro como Clarke, no espero viajes interplanetarios, pero plantada en el año 2000 yo hubiera firmado que a 2008 ya tendríamos una web más organizada, basada en partones, en estándares para GUI, que proporcionaran  ayuda a los usuarios a través del reconocimiento de los elementos de una interfaz y su comportamiento esperado. La consistencia siempre ha sido uno de los elementos más importnates de la usabilidad, en ese sentido esta se logra por la mayoría, el comportamiento usual, o normal parte de la norma, que no es otra cosa que la regla fijada por la mayoría, todo aquello que entra dentro de la curva normal.

Jakob Nielsen, con la modestia que lo caracteriza, promueve la “Ley de la experiencia del usuario web de Jakob” en la cual postula que: los usuarios pasan mucho tiempo en otros sitios, entonces, cualquier cosa que sea usada por la mayoría de los otros sitios será grabada a fuego en los usuarios y si te desvías de esa senda tendrás grades problemas de usabilidad.

Si bien esto es cierto, creo que la falta una parte porque también es cierto que el usuario no adopta comportamientos, funciones o interfases que no tengan que ver con su modelo mental por más mayoría de sitios lo usen, entonces podríamos redefinir la ley de Jakob sosteniendo que lo que sea que se repita en la gran mayoría de los sitios también debe coincidir con la lógica de la mayoría de los usuarios para contar con su asimilación. En este sentido parece ser una serpiente que se muerde la cola ya que, a causa de las leyes estadísticas, los diseñadores, muchos de ellos por lo menos, arribarán a una solución coincidente también.

Volviendo a los botones, Jakob Nielsen sacó un artículo donde también plantea la posición de los botones OK/CANCEL, que retuerce una vuelta más el tema: ateniéndose a los estándares según las plataformas que usen sus usuarios, entonces, en lo que respecta a los botones:

• Microsoft pone el Ok a la izquierda
• Apple pone el Ok a la derecha

¿Entonces qué hacer? Nielsen propone, salomónicamente, que para aplicaciones de escritorio se utilice la convención que cada una de ellas propone, pero ¿qué pasa con aplicaciones web? que son casi independientes del sistema operativo, la propuesta es similar, propone mirar los logs y tomar parte por la plataformas que más te visita, en la mayoría de los casos: Windows. No sabría explicar por qué pero esta respuesta no termina de cerrarme.

Pasando a otra persona que sabe mucho del tema, Luke Wroblewski sostiene que, dentro de un formulario, las acciones de Guardar, Enviar, Continuar, son primarias ya que son las que habilitan la acción más importante dentro del form que es la finalización del mismo. En la misma dirección las acciones menos usadas como Cancelar, Borrar, o Ir Atras, son consideradas secundarias.

Debido a que muchas veces los usuarios utilizan las acciones secundarias por error, lo ocasiona muchas veces pérdida de datos es que muchos diseñadores están en contra de considerarlas en las interfaces, pero muchos otros creemos que es mejor que estén, para determinados casos y como salvaguarda para los usuarios. (ver post El botón reset en formularios web de octubre de 2003).

La situación que se presenta es la siguiente, necesitamos posicionar dos acciones, una primaria y una secundaria, una que nos llevará al éxito y una que podría ser letal para nuestros planes en un mismo sector, pero de manera tal que queden perfectamente diferenciadas. ¿Cómo podremos lograr esto?

Una estrategia muy usada es reducir la importancia visual de las acciones secundarias acompañadas o no, por un resaltado de las acciones primarias, esto ayudará a enfocar la atención del usuario hacia las acciones importantes pero sin dejar de ofrecerle un escape por si lo necesita.

Esta imagen es un buen ejemplo, pertenece a Feedly y muestra en la esquina derecha cómo el botón de la acción primaria “Suscribe” es visible y la acción secundaria “Cancel” ni siquiera es un botón, sino que es un link en donde además de haber perdido jerarquía de acción de formulario, el que sea un link reduce el área clicleable y de esta manera también la posiblidad de accionarlo por error.

Mientras que los estándares en la web siguen rondando en torno a código palpable (CSS, HTML, XML, incluso accesibilidad) cuesta mucho ponerse de acuerdo en cuanto  a los mecanismos que proporcionan la experiencia del usuario en la web, cuestiones como navegación, interacción, y acciones complejas son quizás demasiado subjetivas para un único criterio, para el “diseño centrado en el usuario” porque lo primero que hay que preguntarse es ¿quien es mi usuario?

Hasta la próxima!

Enlaces recomendados:

• UseIt: OK–Cancel or Cancel–OK?
• UseIt: Do Interface Standards Stifle Design Creativity?
• LukeW: Primary & Secondary Actions in Web Forms
• Peachpit:Creating Bulletproof and Easy to Complete Web Forms
• IBM DeveloperWorks: Using Web widgets wisely
• IxDA: Next & previous button order

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.

Cuando me sumergí en el mundo de la usabilidad, hace más de 10 años ya, ésta no estaba tan extendida como ahora, ni existían tantos libros, ni tantos sitios u oradores, ni etc, etc, etc, teníamos el Designing web usability de Nielsen, el The design of everyday things de Norman y otros tantos que provenían más de sus raíces de ingeniería. Estábamos ante una disciplina que nueva y que en el tiempo fue mutando, creciendo y cambiando al ritmo de las necesidades de los usuarios.

Les propongo que recorramos algunos alertbox de useit.com, (El sitio de Jakob Nielsen) para hacer un corte cronológico de los tipos de errores que se cometieron (yo nunca :) en nombre de la modernidad y el ciberespacio.

En 1996 Nielsen escribió un artículo conocido como Web design mistakes en el cual publicaba un decálogo de los errores más comunes, hoy, doce años después nos es fácil inferir que esos errores tenían mucho que ver tanto con la pobre banda ancha de los usuarios que se reflejaba la necesidad de mantener los pesos de las páginas lo más bajos posible, como con la necesidad de reutilizar el código, no había muchas tecnologías para dinamizar sitios y se recurría mucho a los frames para que las páginas compartieran secciones comunes como headers y botoneras.

También se reflejaba el desconocimiento que tenían los webmasters del código HTML y el uso intensivo que hacían de programas tales como FrontPage en el cual se abusaba de los blinks y las marquesinas. Vemos a continuación los puntos salientes de 1996:

1. Uso de frames
2. Uso innecesario de tecnología de punta
3. Texto que se desplazan, marquesinas, y animaciones en perpetuo movimiento
4. URL complejas
5. Páginas huérfanas
6. Páginas largas con mucho scroll
7. Falta de soporte para la navegación
8. Colores no estándares para los links
9. Información desactualizada
10. Tiempos de descarga excesivos

En 1999, viendo que sus prédicas habían caído en saco roto, Nielsen decide sacar una nueva versión que llamó The top ten web design mistakes of 1999, para esta época parece ser que los problemas de conectividad de los usuarios no se habían solucionado (ni mucho menos aquí en la Argentina) pero ya la cosa no viraba tanto para el lado de la construcción de las páginas sino que empezábamos a palpar problemas que tenían que ver con la interacción del usuario dentro del sitio, la apertura en página nueva tan de moda en épocas pasadas, rompía con la navegación que el usuario empleaba usando los controles del navegador (botones atrás adelante).

Otros errores que reflejaban estas inquietudes tenían que ver con la falta de navegaciones alternativas, como por ejemplo archivos, la apertura de los links en ventana nueva que, persiguiendo la inutilidad de que el usuario no se fuea de los dominios del webmaster, desorientaban gravemente a los usuarios novatos, por entonces, una abrumadora mayoría.

También expone la maldita costumbre de mover las cosas de lugar rompiendo los links desde otras páginas y dejando obsoletos los bookmarks de los usuarios (con lo que costaba conseguir información en épocas pre-googleanas)

El punto 10 nos da indicios de las primera apariciones de la ceguera a los banners, ya que se recomienda no hacer contenidos que parezcan publicidad ya que los usuarios, aún en épocas tan tempranas, comenzaban a ignorarlos. Los destacados de 1999 fueron:

1. Deshabilitar el botón Atrás
2. Abrir en nuevas ventanas
3. Uso no estándar de las aplicaciones o controles
4. Falta de biografías
5. Falta de archivos
6. Cambiar los links de las páginas
7. Titulares que no tienen sentido fuera de contexto
8. Utilizar las últimas Buzzwords de internet
9. Tiempos de respuesta del servidor lentos
10. Cualquier cosa que luce como publicidad

No contento con años de prédica, en 2002 se reedita la lista bajo el nombre de Top Ten Web-Design Mistakes of 2002 pero, en esta edición veremos que si bien seguimos repitiendo ciertos errores, el acento recae en otro tipo de problemas, aquellos ligados con la lógica de negocios en internet, el puesto número uno se lo lleva un problema típico de los incipientes sitios de e-commerce, la falta de precios en los productos ofrecidos.

El segundo puesto también está ligado a un tema recurrente de los grandes sitios, el tener motores de búsqueda que no devolvieran resultados útiles a los usuarios, gran problema en una tienda virtual si el cliente no encuentra lo que busca… y cuestiones tales como el punto 7 y el 8 forman parte del catálogo de políticas erróneas implementadas en las primeras épocas de transacciones en red.

Sin embargo seguimos teniendo problemas con las interfases, las fuentes de tamaño fijo, o los grandes y poco legibles bloques de texto o errores menores que desorientaban la navegación del usuario como los citados en los puntos 6 y 10.

Empiezan a aparecer puntos que tiene que ver con la accesibilidad, no parece que sea desde este enfoque que se encaran estos errores pero vemos que hay temas que se irán instalando para prevalecer más adelante en la línea de tiempo. Finalmente la lista de 2002:

1. No publicar los precios
2. Motores de búsqueda Inflexibles
3. Scroll horizontal
4. Tamaño de fuente fija
5. Bloques de texto
6. JavaScript en los links
7. Preguntas infrecuentes en las FAQ
8. Recolección de direcciones de e-mail sin una política de privacidad
9. URL > 75 Caracteres
10. Links con “mailto” en lugares inesperados

Parece ser que los tiempos en la web se aceleran, y ya Nielsen no pudo dejar pasar entre 3 y 4 años para señalar los errores de la web, así que al año siguiente publicó Top 10 Web Design Mistakes of 2003 como venimos viendo los problemas que van surgiendo obedecen también a la ampliación de posibilidades, el tiempo va pasando y surge la necesidad de fechar las publicaciones, como de mantener archivos, o en el negocio de vender productos en línea donde empieza a surgir la necesidad de catalogar más exhaustivamente ya que una clasificación solo por marcas no es suficiente para que los usuarios encuentren los productos o los formularios para usuarios que eran muy restrictivos.

1. Declaración de principios poco clara
2. Nuevas URL para contenido archivado
3. Contenido sin fecha de creación o modificación
4. Pequeñas imágenes obtenidas de Grandes fotos con muchos detalles
5. Textos alternativos excesivamente detallados
6. Falta de soporte para situaciones de comparación entre opciones
7. Largas listas que no pueden ser filtradas por atributos
8. Productos clasificados solo por Marca
9. Formularios de entrada muy restrictivos
10. Páginas que tienen links a sí mismas

Dos años después podemos ver el retorno de Jakob Nielsen con Top Ten Web Design Mistakes of 2005, pero, en pos de extender horizontes, esta vez hizo una encuesta entre los lectores de su newsletter para armar la lista en torno a aquellos errores que más irritaban a sus lectores, curiosamente, o no, los lectores de Nielsen conincidieron en muchos puntos con errores ya destacados en otros años.

Y si, por fin apareció el flash, tardó su tiempo pero ocupó su lugar, este punto, que al parecer nielsen no habia detectado por si mismo, tuvo la suficiente relevancia como para entrar tercero en el ranking. Eso, imagino, se debe a las molestas animaciones de introducción que tenían que soportar los usuarios no una sino  cada vez que accedían a una página antes de poder saltar al contenido que estaban buscando. Debemos rescatar también los problemas de legibilidad que más que nada están basados en la falta de contraste entre el fondo y el color de la tipografía.

Otro de los temas importantes que emerge es la necesidad de seguir estándares para la construcción del código que se muestra en la web: HTML+CSS. Ya en 2005 era molesto abrir una página con Firefox y ver que la misma se desbarataba o que las funcionalidades no andaban, es un poco del despertar de la conciencia, que nos dice que diseñar para internet explorer no es lo mismo que diseñar para la web. El listado total para 2005 es:

1. Problemas de legibilidad
2. Links no estándares
3. Flash
4. Contenido que no está escrito para la web
5. Búsqueda mal planteada
6. Incompatibilidad entre los navegadores
7. Formularios incómodos
8. Falta de información de la compañia o de contacto
9. Layouts fijos con anchos de páginas fijos
10. Ampliación inadecuada de las fotos

Quizás ya cansado del reporte periódico, en 2007  Nielsen decidió actualizar el compilado:  Top ten mistakes in web design, que listaba según sus palabras.: “las ofensas más flagrantes contra los usuarios” “Los desastrosos diseños web, horrorosos HTML y las atrocidades en contra de la usabilidad”

Es como si con cada generación de nuevos diseñadores se renovaran los errores una y otra vez, el tema de las búsquedas y las dificultades que experimentan los usuarios para encontrar lo que buscan dentro de un sitio, es un claro ejemplo de un desacierto que se repite constantemente, la falta de legibilidad también, ya sea por el tamaño de las tipografías o los grandes bloques de texto, o el abrir los links en ventanas nuevas sin el consentimiento del usuario, en este sentido Nielsen dijo una vez y yo lo he repetido miles: El usuario es el dueño del mouse (¿qué parte no entendieron?)

Sin embargo aquí también aparecen nuevas vetas que suponen una evolución tanto de la web como de los errores, y es la visibilidad en buscadores, La era Google ya se ha desarrollado y con ello la posibilidad de que cualquiera que tenga un sitio bien hecho pueda esta bien posicionado en un resultado de búsqueda y nos empezamos a preocupar por los metadatos, la clasificación Dublin Core, la limpieza del código, la repetición de las palabras clave, las condiciones de accesibilidad y visibilidad del sitio. Nos enteramos no hace mucho de la palabra SEO (Seach Engine Optimized) y todo lo que ella representa y toda esta movida en el tiempo, se representa en el puesto número 6 de la lista de UseIt.

Otro tema digno de destacar son las convenciones, así como los lenguajes responden a estándares, el diseño web responde a convenciones en este caso a la consistencia, funciones o tareas que indefectiblemente se distinguen y se comportan de la misma manera. En este sentido Nielsen sostiene que como los usuarios pasan mucho tiempo en diversos sitios, basarán sus expectativas con respecto al nuestro en relación a la consistencia que tengamos con otros sitios, la familiaridad que se crea al encontrar que algo funciona de la misma manera que en otro lado, la traslación de ese conocimiento tornará nuestro sitio más facil de usar. La lista para 2007 está compuesta por:

1. Dificultad en las búsquedas
2. Archivos en PDF para lectura en línea
3. Falta de diferenciación para el color de los links visitados
4. Texto no escaneable
5. Tamaño fijo para las tipografías
6. Títulos de página con baja visibilidad en buscadores
7. Cualquier cosa luce como publicidad
8. Violación de las convenciones de diseño
9. Abrir links en ventanas nuevas
10. No responder a las preguntas de los usuarios

A como va el negocio, que a mi modo de ver tiene barreras de entrada muy bajas, con lo cual nos encontramos que cualquiera puede rápidamente armar páginas web, podemos sostener que Jakob Nielsen  podría seguir unos cuantos años más con sus decálogos de horrores en el diseño web.

Hasta la próxima!

Enlaces relacionados

• 456 Berea ST: Top ten web design mistakes, 2005 edition
• 456 Berea ST: Ten deadly sins of web design
• Web Pages that sucks: Biggest mistakes in web design 1995-2015
• Office Microsoft Live: 5 mistakes every website should avoid
• Palmer Web Marketing: 10 Costly Assumptions
• web design from scratch: Top 5 Home Page Mistakes

Escrito por Viv Dehaes
Publicado originalmente en: Interacciones
Bajo licencia CC Reconocimiento-No Comercial-Sin Obra Derivada 2.5 Argentina.