“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.

• Usabilidad de la home page
• Soporte a las tareas del usuario
• Navegación y arquitectura de la información
• Formularios
• Confianza y credibilidad
• Escritura y calidad de los contenidos
• Estructura de la página y diseño visual
• Búsqueda
• Ayuda, feedback y tolerancia a los errores

Estos lineamientos parecen más bien puntos de verificación y por la manera en que están escritos están más orientados para la verificación de sitios ya productivos aunque son una guía muy util durante la construcción, como la misma consultora apunta: Nada reemplaza un buen proceso de diseño.

Enlaces relacionados

• User Focus: 247 web usability guidelines
• MIT: Usability guidelines
• Interacciones: La evolución de los errores según Jakob Nielsen

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.

Imagen descriptiva de los 9 círculos del infierno del dante

1. en el primer círculo, el limbo, se encuentran aquellos que no fueron bautizados
2. en el segundo se encuentran los lujuriosos
3. en el tercero están los soberbios y envidiosos
4. el cuarto está reservado para los avaros
5. y el quinto para los orgullosos
6. en el sexto están los herejes y materialistas
7. el séptimo contiene las almas violentas
8. en el octavo se encuentran los fraudulentos
9. y en el noveno, los traidores.

Curiosamente en esta visión del mundo mientras más se adentra uno en las profundidades del infierno, más frío hace hasta que en el noveno círculo todo está congelado.

Hace un tiempo que vengo pensando en la idea de: Si el Dante caminara por la tierra en estos días, cómo sería el infierno? y más concreto, cómo sería un infierno digital?

He aquí una primera aproximación, se aceptan sugerencias, de quienes serían candidatos a los 9 círculos, no tengo bien claro el orden y quizas se me está escapando uno que otro pecado:

1. Los orgullosos que abusan de la navegación basada en metáforas
2. Los displicentes que diseñan sin independencia del navegador
3. Los usureros que utilizan títulos de fantasía que nada tiene que ver con el contenido
4. Los egoístas que piden registrarse para navegar la información o realizar tareas simples en un sitio
5. Los fraudulentos que disfrazan los avisos de adsense entre el contenido
6. Los soberbios que configuran cada link para que abra en una nueva ventana
7. Los herejes que hace intros en flash sin skip para los sitios
8. Los malditos que hacen un uso no estándar de los controles sobre todo en formularios

Todos ellos recibirán castigo divino por esas acciones, y el noveno circulo? bueno, el circulo más profundo del infierno está destinado a los que hicieron los formularios  e interfaces de la AFIP (Administración Federal de Ingresos Públicos de Argentina) luego de haber luchado una semana entera con los abm desarrollados por estas personas donde me he encontrado con situaciones tales como:

1. Falta de mensajes de error, es decir me equivoco y la interfaz no me dice nada!
2. Las pocas veces que me encontré con un mensaje de error era tan críptico como: Error 90.005
3. Opciones escondidas sin absolutamente ninguna pista de dónde se encuentran
4. Páginas de ayuda que llevan a un error 404
5. Falta de ayuda para opciones escritas en un lenguaje técnico inalcanzables para quien no profesa la burocracia como forma de vida

Debo decir, Sres de la Afip, Dios los va a castigar por lo que están haciendo, dejen de hacer manuales e instructivos y hagan interfaces pensando en la gente.

Hasta la próxima!

Enlaces recomendados:

• Psicobyte: Todos los informáticos van al cielo
• Álvaro Felipe: Resumen de la Divina Comedia (Mapa del Infierno)
• Bestiaria: Los nueve círculos del Infierno
• 456 Berea St: Ten deadly sins of web design
• Smashing Magazine: 10 Usability Nightmares You Should Be Aware Of
• SEO Blog: 10 Usability Sins that Make me Bounce and Never Come Back

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.

En el evento se desarrollarán charlas y talleres liderados por expertos locales, que abordarán la cuestión de la usabilidad vinculándola al ámbito de Internet y a otros campos, en los que su aplicación significa una mejora en la vida diaria de las personas. Se cubrirán aspectos conceptuales, prácticos, metodológicos y económicos de la usabilidad.

El evento es gratuito pero requiere inscripción previa (no habrá inscripción el mismo día).
Se puede realizar la inscripción y conocer el programa detallado del evento en el sitio oficial: 

Día Mundial de la Usabilidad 2008 en Buenos Aires 

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.

El grupo se llama UPA Argentina y hacen reuniones mensuales en la Ciudad de Buenos Aires de capacitación, debate, intercambio de ideas, etc., además de compartir una lista de correo a la que, aquellos que la propuesta les resulte interesante, se puedan suscribir.

En la última reunión, según lo que me cuenta Gonzalo Auza, que fue quien me contactó para participar, se hizo una presentación sobre Arquitectura de Información, un debate posterior y un ejercicio lúdico de ordenamiento de tarjetas; y en la anterior profesionales de renombre como ser Eduardo Mercovich, Enrique Stanziola y Jorge Plano hicieron presentaciones.

Me parece una muy buena iniciativa ya que una de las formas de difundir la usabilidad es a través de la socialización del conocimiento, logrando a través de estas acciones el crecimiento del mercado y la concientización de la necesidad de estas disciplinas como parte integral de la expansión e innovación en los desarrollos en internet.

Hasta la próxima!

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

Los invito a bajárselo, imprimirlo, colgarlo en un lugar visible, sacarle una foto y luego ubica tu foto del calendario en el mapa

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

En nombre de esta cruzada se cometieron abominaciones tales como separa un contenido largo en muchos hipertextos que se comunicaban a través de enlaces, por ejemplo, o se partían los textos en la misma página con grandes espacios (simulando ser una página nueva) y se los vinculaba a través de los anchors (enlaces dentro de una misma página). Lo cual obligaba a los usuarios a visitar varias páginas antes de encontrar lo que estaba buscando, y nos posicionaba más cerca de la imprenta que de los servidores.

Se hicieron estudios acerca de qué es lo que pasaba “above the fold”, estos términos también traducibles como “debajo del doblez” tienen que ver con el mundo físico, el del periódico, ya que las páginas de los periódicos suelen tener un tamaño que para poder leerlo cómodamente hay que doblarlo, entonces tenemos una parte visible, en donde aparecen los titulares más importantes y una parte que queda doblada, la cual puede ser pasada por alto. en la web, el doblez, también llamado línea de scroll, traza una raya imaginaria debajo de la cual el usuario debe hacer scroll para ver más contenidos.

Entonces ¿qué está pasando con el scroll? investigaciones recientes y no tanto (Jakob Nielsen publicó en 1997 su artículo: Changes in Web Usability Since 1994 que los usuarios realmente tenía este comportamiento incorporado), exponen que los usuarios no tienen inconveniente alguno en buscar información más allá de la línea de scroll, siempre y cuando ellos puedan reconocer que esta línea existe y que debajo de ella la información se extiende.

Surgen preguntas acerca de este cambio en el comportamiento de los usuarios, ¿cuánto habrá influido en este cambio el advenimiento del formato blog con sus páginas de scroll ad infinitum? ¿Cuánta influencia habrá tenido la ruedita del mouse en este caso? No encontré

Jared Spool publicó en User Interface Engineering un artículo Utilizing the Cut-off Look to Encourage Users To Scroll en el cual propone que si se arman las páginas en secciones estructuradas de forma reconocible, además de que se tratará de que las mismas no sean simétricas para la pantalla logran, a través de textos o imágenes cortadas en el fondo del navegador, transmitirle sutilmente a los usuarios que la información no se ha terminado en la primera pantalla, sino que la página tiene un doblez.

Por ejemplo, el siguiente sitio: http://www.robbiemanson.com

Las imágenes se cortan y en la barra lateral de información hay un título “Current projects” que, me sugiere que, la información continúa por debajo de la línea de scroll.

Sin embargo, en el siguiente sitio: http://www.lataka.com

A pesar de que se observa gran cantidad de scroll para hacer en la barra vertical, no tengo indicios claros de que la información continúe por debajo del doblez.

Cuando en una estructura todas las secciones terminan uniformemente al final de la pantalla, el usuario puede tomar la decisión subconsciente de que no existe más información para ver y eventualmente no se desplazará hacia el final de la página.

Un truco a tener en cuenta si el sitio cuenta con páginas realmente largas es añadir “stop points” elementos que le permitan al usuario escanear el texto, tales como imágenes, distintos niveles de títulos, viñetas, entre otro recursos para prevenir que el usuario no encuentre saltos que le permitan entender el texto y se desplace hasta el final de la página de un solo movimiento.

ClickTale tiene un excelente informe: Unfolding the Fold en el cual afirman que los usuarios realizan el scroll hasta los pie de las páginas cualquiera sea su tamaño y que además están dispuestos a escanear la página entera, no importa su extensión. Acompañan estas afirmaciones gráficos y porcentajes que valen la pena revisar.

Click Tale sostiene que la zona más valiosa va desde casi el top de la página hasta aproximadamente los 800 pixels y que el pico de atención se ubica en aproximadamente la línea de los 540 pixels, pero habiendo hoy en día tantos tamaños de resoluciones en uso es difícil decidir dónde se encuentran tanto estos puntos como la línea de scroll.

La recomendación que suelen hacer los que saben es: no te preocupes, solo diseña las páginas de manera eficiente, distribuye la información por toda la página con los suficientes espacios en blanco y una buena estructuración de tal manera de llegar al usuario con una propuesta simple y usable. Esto no significa obviar las reglas básicas: la información primordial debe estar contenida en la primera pantalla, de otra manera estaríamos haciendo que el usuario navegara por todos lados buscando la mínima información acerca de dónde está parado.

Para terminar, transcribo la conclusión de ClickTale:

Browser: Do not try and find the fold. That’s impossible. Instead… only try to realize the truth.
Designer: What truth?
Browser: There is no fold.
Designer: There is no fold?
Browser: Then you’ll see, that it is not the fold that matters, it is only yourself.

¡ Hasta la próxima!

Otros enlaces recomendados:

• Boxes and arrows: Blasting the Myth of the Fold
• ClickTale: Scrolling Research Report V2.0 – parte 1 y parte 2
• User Interface Engineering: As the Page Scrolls

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

Muy buen recordatorio para no caer en la tentación:

• Enero: Elegir una presentación que combine con el contenido
• Febrero: Ofrecer personalización solo si añade valor
• Marzo: Mantener las novedades visibles, no esconder la información en desplegables
• Abril: El video es copado, siempre y cuando soporte las tareas del usuario.
• Mayo: No pedir login si no es necesario
• Junio: ¿Quién dijo que lo usable tiene que ser aburrido?
• Julio: Ley de Fitts: Mientras más grande mejor, o al menos más fácil de hacer clic
• Agosto: Más opciones de navegación no siempre hacen al sitio más fácil de usar
• Septiembre: No copies cada elemento de moda de la Web 2.0 que ves
• Octubre: Focaliza el esfuerzo en el contenido, la home page es vista por pocos usuarios
• Noviembre: Una palabra: Oversahring
• Diciembre: Hemos visto suficientes clones de Facebook ya, gracias!

Consigue el calendario en formato PDF

¡Hasta la próxima!

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

Y no es extraño que las personas se comporten así, cuando se enfrentan a un producto novedoso es probable que no tengan información exhaustiva sobre el mismo, sino que más bien sepan lo mínimo y necesario, por ejemplo cuando compré mi primer reproductor de DVD, yo ya sabía todo lo que tenía que saber de los VHS pero los DVD eran terreno virgen para mi, entonces el vendedor me preguntaba: quiere que reproduzca también DivX? Por supuesto! le respondía yo, aún sin tenerlo bien en claro, quiero el que reproduzca mayor cantidad de formatos! más allá de que fuera a utilizarlos o no, no tenía ni la certeza ni los conocimiento como para descartar nada. Y no estaba muy equivocada en el tema del DVD pero, hoy en día, por ejemplo sé que si tuviera que comprar otro microondas no compraría uno que tuviera Grill ya que en mi vida lo usé.

Ahora, si a las personas no les gusta comprar productos “simples” ¿Por qué hay tanta gente en la calle con el clip de ipod? (Esta pregunta tiene una respuesta que va más allá de nuestro tema, pero necesitaba plantearlo porque es una arista mas dentro de la discusión) Vale aclarar que el fanatismo que los usuarios sienten por estos aparatos no viene únicamente de la supuesta simplicidad de su interfaz sino más bien de un coctel muy poderoso que resume: diseño limpio, estética única, apelación de lo emocional, fidelización de clientes, visión de elite, etc, etc, etc, cuando uno compra un ipod clip no compra un mp3, sino mucho más, pero eso ya refiere otros temas así que volvamos al tema.

Para sostener la hipótesis de Norman podemos apelar a un estudio del Harvard Business Review que sostiene que los consumidores al enfrentarse por primera vez a un producto juzgan su calidad basándose en la cantidad de funcionalidades que ofrece. Esto mandaría al tacho las teorías de HCI de todos los tiempos de no ser porque el mismo estudio también aclara que este tipo de comportamientos se encuentra en nuevos usuarios, y que una vez que los mismos hayan utilizado el producto, la facilidad de uso pasará a ser más importante que la cantidad de funciones ofrecidas.

Simplicidad e interfases web

Los sitios web no están exentos de este debate, muchas veces nos encontramos con algunos que presentan gran complejidad visual pero en los que los usuarios perciben valor asociado a la cantidad de funciones que ofrece, mientras más mejor. Ante esta perspectiva, hay varias cuestiones que que tenemos que repensar.

La simplicidad de las interfases debe reflejarse en todos los aspectos del sistema: por un lado la visual que refiere al equilibrio de las estructuras entre información y espacios en blanco. en este sentido la simplicidad visual puede medirse por cuán fácil puede recordar un usuario la composición de la página luego de haberla visto por primera vez durante poco tiempo. La simplicidad de los conceptos que tiene relación directa con los modelos mentales, las metáforas y los distintos mecanismos de interacción forman parte también de la simplicidad de u sitio junto a la simplicidad de la información propiamente dicha, que tiene que ver con lo que se escribe y el lenguaje que se utiliza, la estructuración de las ideas, y por último la simplicidad en la interacción, es decir con la propuesta de interactividad de la página la cantidad de pasos en una tarea, la complejidad de los mismos.

El foco no debería ponerse en cuantas funciones debe tener sino en cuales serán las importantes, cuales publicaremos a primera vista, cuales esconderemos, cuales son superfluas y por ende dispensables, cuales se pueden resolver por procesos que no requieran interacción directa con el usuario, etc. La propuesta es lograr un equilibrio lo que se deja, lo que se esconde, lo que se disimula y lo que se saca por supuesto siempre con sentido común. En este sentido los prototipados y los test de usuarios son esenciales ya que más allá de la complejidad visual que presente una interfaz, el usuario maneja un número limitado de información a la vez, (recomiendo leer Balancing visual and structural complexity in interaction design)

Las funcionalidades que ofrecemos sólo agregan valor si son bien utilizadas por nuestros usuarios, el hecho de tenerlas por tenerlas, solo agregará complejidad a nuestras interfases. Una función que ofrecemos a nuestros usuarios, más allá de tener características implícitas, necesita de contexto para que éstas se expliciten de la mejor manera posible, es decir que se necesita de una buena arquitectura de la información, ya que los datos eficientemente catalogados tienen mayor relevancia y facilitan el entendimiento, es decir se vuelven más útiles.

Si bien se habla mucho del tema, no hay reglas claras a seguir, por ejemplo Ben Hunt en su sito web design for scratch sostiene:

"There are two important aspects to achieving success with simplicity: 1. Remove unnecessary components, without sacrificing effectiveness. 2. Try out alternative solutions that achieve the same result more simply."

Esta premisas son totalmente lógicas y llenas de sentido común. Estamos rodeados de leyes que no dicen mucho (ver The Laws of Simplicity de John Maeda), y también en abundancia de frases, algunas con ribetes filosóficos como:

"Simplicity is know when less is too little and more is too much." el mismo John Maeda de las leyes…

otras con más pistas que nos ayudan a dilucidar de qué se trata:

"Simplicity involves two major processes: eliminating redundant elements and integrating things to make them flow." – Ken Okuyama

Pero finalmente nos dejan sin parámetros que nos permitan experimentar la felicidad de algo cercano al método científico. La simplicidad finalmente se define a ojímetro (dícese de una medida tomada a través del ojo), vemos un sitio y podemos opinar si nos parece simple o complejo, pero del proceso para llegar a esos dos objetivos, por ahora bien gracias…

La regla de los cinco dedos

Luego de pensarlo un tiempo, he llegado a la conclusión de que el poder discernir el nivel de simplicidad de forma eficiente es una dura tarea que puede encararse a través de lo que en el ambiente se conoce como la regla de los cinco dedos que paso a explicar a continuación:

1. Extender el brazo derecho hasta que quede paralelo al piso.
2. Separar los dedos de la mano levemente
3. Girar el dedo pulgar para abajo al tiempo que el meñique gira para arriba generando una rotación de la mano hacia la izquierda.
4. Realizar el movimiento opuesto subiendo el pulgar y bajando el meñique.
5. Repetir los pasos 3 y 4 con un ritmo ligero.

Por último una frase que me gustó:

“See it big, and keep it simple.” Wilfred Peterson.

Hasta la próxima.

Enlaces recomendados:

• UX matters: The complexity of simplicity
• Jeff Brace Design: Simplicity
• LukeW: The Pursuit of Interface Design Simplicity
• BoxesandArrows: Simplicity: The Distribution of Complexity

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

BumpTop es un prototipo de escritorio para tablet PC que hace un tratamiento de los documentos digitales tal como si fueran sus ancestros de papel, según sus creadores lo que pretenden con este prototipo es "enriquecer la metáfora del escritorio mediante técnicas de expresión simples sacadas del mundo real".

El video es bastante educativo de los alcances de esta propuesta, usando un puntero los archivos pueden ser seleccionados, movidos, agrandados, apilados y desapilados a voluntad

Suena interesante y merece ser probado.

Enlaces recomendados

• Página oficial: BumpTop™ Prototype
• BumpTop: Nice for anything…but my Desktop
• Parodia de BumpTop en YouTube

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

Según la Wikipedia, un newsletter o boletín electrónico "es una publicación distribuida de forma regular, generalmente centrada en un tema principal que es del interés de sus suscriptores."En un principio este delivery de información calificada se realizaba en papel por medio el correo postal, con el advenimiento de la era de la información tuvo su salto al mundo digital y aparecieron los newsletters electrónicos enviados a suscriptores vía e-mail.

El objetivo primario de esta práctica de marketing digital es entregar información a los usuarios sobre actualizaciones del sitio o lo que se les ocurra a los editores que pudiera interesarle a sus suscriptores, el fin último tiene que ver con la fidelización del usuario, es decir, el newsletter se transforma en un embajador de la calidad de nuestro sitio, por ello debemos prestar atención a lo que estamos enviando.

Sobre la información

De más está decir que la información tiene que ser relevante, o sea de interés para el grupo de suscriptores. Los contenidos tienen que perseguir algún estándar de calidad que pueda ser percibido por sus usuarios, de no cumplir con estas sentencias, no lo envíen y no utilicen el newsletter como soporte para enviar publicidad, a menos que los usuarios lo hayan solicitado expresamente.

Es importante que el newsletter contenga la siguiente información:

• Nombre del sitio, En el formato HTML debe ir también el logo.
• URL del sitio, información de contacto, nombre de la persona responsable.
• Información sobre la administración de la suscripción.

Sobre el formato y la presentación de la información

Los formatos de entrega más populares son HTML y texto plano, los cuales deben ser ofrecidos a nuestros usuarios para que éstos elijan cómo quieren que la información les llegue. Para los usuarios que elijan como formato HTML, habrá que considerar algunos aspectos de la presentación de la información, por ejemplo:

• Ancho recomendado: la longitud horizontal máxima que puede alcanzar el mensaje para que la información sea correctamente interpretada. Por mi parte recomiendo un máximo de 500 px a 550 px. En esta medida no solo hay que tener en cuenta la resolución del monitor de los usuarios, sino también el uso del panel de previsualización de los clientes de mail por parte de la mayoría de los clientes de mail de escritorio y que seguramente se va a incorporar en las próximas generaciones de servicios de mail web based. La idea es que el mail pueda mostrarse correctamente cuando el usuario lo previsualiza en su cliente de correo, si después quiere abrirlo para verlo mejor, enhorabuena, pero hay muchos usuarios que ya no utilizan esta funcionalidad, sino que visualizan lo que se ve en el panel de previsualización.
• Modelo de pirámide invertida: es recomendable que la información más importante esté lo más arriba posible dentro de la estructura. Se recomienda empezar por la conclusión, un párrafo como resumen e ir agregando información gradualmente, de modo que los usuarios puedan tener una idea global del contenido incluso sino no lo leen entero.
• Estructurar el texto para que sea escaneable: utilizartítulos claros, significativos y diferenciados de los textos, párrafos cortos y concisos, viñetas y recuadros para cortar la monotonía de la información pero no perdiendo de vista la moderación. Asegurar también, el balance necesario entre las zonas de congestión de la información y los espacios en blanco necesarios para "airear" la información. No justificar el texto, los cortes que encontramos en la alineación a la izquierda, generados por el tamaño aleatorio del texto ayudan a la lectura en pantalla, que es mucho más dificultosa para el ojo humano. (Ver: How Users Read on the Web). Se recomienda como máximo el uso de 3 tipos distintos de tipografías.
• Poner mucha atención los encabezados del newsletter: el asunto debe ser, como vengo diciendo con los títulos, descripciones, etc.: descriptivo y concreto. Hay que tener especial cuidado con el Sender (from) es recomendable no utilizar alias genéricos como "listadmin" o "postmaster" sino más bien nombres reales, del sitio o del encargado del mismo. Y por último el destinatario del mensaje debe ser el mail del suscriptor, no eufemismos de listas tales como "listaboletin", y ni hablar del "undisclosed recipient" para que el receptor pueda saber fácilmente por cual dirección de correo le llega determinada lista.

Sobre los estilos (CSS o Tablas)

Aquí entramos en una larga discusión acerca si para maquetar un newsletter, de cara a que se vea bien en los múltiples clientes de mail, se debería utilizar tablas o CSS.

He aquí unas recomendaciones al respecto:

• Incluir el tag <style> embebido en el HTML en vez de referenciarlo externamente mediante un link. También se aconseja que este tag, amén de que no sea políticamente correcto, se posicione a continuación del tag <body>en vez de antes de éste para que el HTMl pueda ser interpretado por el servicio de Hotmail.
• Tratar de no maquetar con CSS, aunque muchos sostengan que un maquetado correctamente semántico es posible, mi experiencia indica que la mayoría de los dispositivos no se ponen de acuerdo sobre una manera unificada de mostrar la información.
• No usar código JavaScript muchas veces pueden disparar alertas de seguridad en la PC de los usuarios, creo que no tengo que explicar lo mal que nos haría quedar una situación de ese estilo.
• Hacer un testeo de los documentos con un validador HTML (ej: validator.w3.org) ya que el excesivo uso de los tags o incluso un mal uso de los mismos (tags mal cerrados o no cerrados en absoluto) pueden hacer que el boletín sea catalogado como spam y consecuentemente filtrado.

Sobre el uso de imágenes y otros elementos multimedia

En los newsletter en HTML se recomienda:

• El diseño tiene que estar estructurado de manera que, si las imágenes no se visualizan, el e-mail no pierda significado y no quede trunco su diseño visual sino siga transmitiendo una imagen profesional. Recordemos que la mayoría de los clientes modernos, tanto desktop como web-based bloquean por defecto las imágenes en los emails.
• Se deben evitar las imágenes para encabezados, links, textos o sentencias, la información catalogada como importante debe mantenerse más allá de una posible falla al mostrar los elementos multimedia. La imágenes suelen ser útiles para acompañar ciertos contenidos, obviamente mostrar los logos y para background y diseño visual en general, pero traten de evitar su uso en información importante. Todas las imágenes deben tener su correspondiente texto alternativo (alt), el cual tiene que estar acorde a la funcionalidad del texto multimedia (Ver art: Texto alternativo: la imagen o la función)
• Declarar los atributos de ancho y alto en tag IMG que muestra las imágenes, se da esta recomendación porque algunos clientes de mail pueden distorsionar las mismas al mostrarlas si las medidas no están definidas.
• Incluir un link a la versión en línea del newsletter al principio del mail para que aquellos que no pueden visualizarlo correctamente en el programa de correo puedan hacerlo en el sitio.
• Acerca de la inclusión del flash en los e-mail, por favor ¡chicos no lo hagan en sus casas! Hablando en serio: los programas de mail no soportan flash, lo que quieran mostrar no se va a ver.

Ejemplo de newsletter compuesto únicamente de ¡una imagen!:

Basándonos en esto, viene la siguiente recomendación: "realicen pruebas de envíos en múltiples software, plataformas, clientes de mail, proveedores conocidos, etc." Testeen "apagando" las imágenes del newsletter. Si el mail no llega bien, si se rompe o no se entiende, pierde su fuerza, su significado, su propósito.

Accesibilidad

• Es preferible siempre el uso de texto a imágenes
• Usar colores que generen buen contraste entre tipografías y fondos.
• La información importante debe estar arriba y datos del estilo de suscripción / desuscripción, direcciones, copyright, etc, al final del documento.
• Evitar el uso de largas cadenas de caracteres para separa textos o secciones, como por ejemplo guiones, asteriscos, barras, etc. Ya que los lectores de pantalla tienden a interpretarlos uno a uno.

Hasta acá el resumen. Seguro que hay muchas más para agregar, si se te ocurre alguna bienvenido sea tu comentario.

Hasta la próxima.

Enlaces Recomendados

• Email Design Guidelines for 2006
• Email Newsletters: Surviving Inbox Congestion

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