Napapijri wallpaper

Napapijri wallpaper

Siempre me han fascinado las marcas, desde mucho antes de que ni siquiera supiera qué era el branding. Recientemente he conocido una nueva marca, dedicada a comercializar ropa outdoors, llamada Napapijri. A pesar de su nombre de origen finlandés (al parecer, napapijri significa “círculo polar ártico” en finés), la marca es de origen italiano. Napapijri es una marca que no está al alcance de los mortales currantes como yo: sus chaquetas, pantalones, jerseys y complementos valen una fortuna, y la marca se posiciona como ultra-premium sin complejos.

Aún así, la verdad es que los diseños de Napapijri no son nada del otro mundo y probablemente las tecnologías que usan tampoco (cualquier fabricante de ropa técnica como TNF, Helly Hansen o Salomon seguro que tiene ropa con mejores prestaciones, por la mitad de precio), por lo que lo que más me ha gustado de Napapijri no han sido sus productos sinó el sabor que desprende la marca. Napapijri dice estar inspirada en las primeras expediciones al Polo Norte y al Polo Sur, y dice apoyar exploraciones científicas a la Antártida. Sea verdad o no, lo cierto es que navegando por su web me he acabado inspirando y he acabado haciendo una composición (que puede valer como wallpaper de Napapijri) que intenta ilustrar ese espíritu que Napapijri intenta transmitir.

Se puede ver aquí en todo su esplendor:

VISUALIZAR WALLPAPER NAPAPIJRI

Y se puede descargar desde aquí (1680 x 1050 px):

DESCARGAR WALLPAPER NAPAPIJRI

Lo he enviado a Napapijri también por si quieren utilizarlo para algo, a ver qué dicen…

7 principios básicos en el uso de tipografías

He aquí 7 principios básicos que he ido recopilando de diferentes fuentes (y nunca mejor dicho) a tener en cuenta cuando se usan tipografías:

  1. Las tipografías con serif deben medir siempre algo más que las sin serif; por ejemplo si una sans serif tiene entre 9 y 11 puntos; si la cambiáramos por una serif ésta debería tener entre 11 y 12 puntos.
  2. Es bueno evitar columnas de texto con más de 80 carácteres por línea. Las líneas más largas de 80 cpl pueden llevar a que los usuarios lectores lean la misma línea dos veces; sin embargo, las más cortas de 80 cpl rompen tan a menudo que es difícil seguirlas.
  3. No abusar de letras todas mayúsculas, especialmente cuando se trata de composiciones con un uso intensivo de textos. Las mayúsculas reducen la velocidad de lectura un 30% y en cambio requieren un 30% más de espacio que las minúsculas.
  4. En diseño de revistas y periódicos, pero también en la web, el ancho de la columna debería ser tan largo como lo que ocupara una vez y media el alfabeto entero en la tipografía que quieres usar y en minúscula.
  5. En diseño de vallas exteriores, un buen anuncio no tendrá más de 7 palabras y no más de 2 cosas a las que mirar.
  6. En las tipografías en cursiva, el cuerpo de letra perfecto es aquel que su altura es 5 veces el ancho.
  7. Para saber la legibilidad de un texto a distancia, hay que que coger la mitad de la altura de la letra en pulgadas y multiplicarla por 100, para tener la distancia de la que es legible en pies

Bueno, pues eso eran 7 principios básicos en el uso de tipografías que siempre va bien tener a mano.

Usabilidad en los peajes I – Re-diseñando los rótulos

A pesar de que en Internet se pueden encontrar opiniones y análisis sobre cualquier tema imaginable, me ha sorprendido un poco no haber encontrado ninguna referencia sobre la usabilidad de los peajes, ni siquiera en inglés. Ya sé que no es un tema tan interesante como para hablar de él largo y tendido, pero cuanto menos es curioso. ¿O quizás es que yo soy el el único del mundo que necesita un pequeño esfuerzo mental para entender los rótulos y la caótica iconografía que los acompaña? ¿Seré yo el único al que no le gusta nada la interfaz de las máquinas de cobro? O quizás sea sólo desviación profesional…

Lo bueno de esto es que nadie ha hablado sobre esto antes y por tanto soy el primero que entre a explorar este territorio virgen. Con esta idea en mente y dado que tengo un esguince que me tiene impedido y no tengo nada más que hacer, voy a hacer una pequeña serie de artículos con propuestas sencillas y económicas de mejorar la usabilidad de los peajes.

En esta primera parte me centraré en exclusiva en el rotulado, que lógicamente incide en mucho en la usabilidad percibida de un sistema. En otro post intentaré escribir una pequeña crítica sobre la usabilidad de las máquinas de cobro de los peajes, que ese es un tema que merece también su propio post.

El primer problema de los peajes es la rotulación. Cuando nos aproximamos con el coche, nos encontramos con carteles de este tipo, al menos en Cataluña: MANUAL y AUTOMÁTICO.

Usabilidad en los peajes

Como todo buen profesional de la usabilidad sabe, el rotulado debe ser auto-explicativo por un lado y por el otro no llevar a confusión. Sin embargo, tanto las vías señalizadas como “MANUAL” como las de “AUTOMÁTICO” son todas manuales, no automáticas. Pagues con billetes y monedas o con tarjeta, ambos modos de pago son completamente manuales y no tienen nada de automático, en tanto en cuanto requieren que pares, que bajes la ventanilla, que pagues y que una vez se efectúe el pago se suba la barrera. No es pago automático porque no es que la máquina cobre por sí misma, quee s la definición de una máquina de pago automático. Esto viola uno de los principios más elementales de la usabilidad: la correcta rotulación a nivel semántico.

Adicionalmente, “AUTOMÁTICO” puede inducir a error a los usuarios del Teletac, que sí es un sistema de pago realmente automático en tanto en cuanto no requiere ninguna acción del conductor aparte de bajar un poco la velocidad. Un usuario del Teletac con toda la razón del mundo podría pensar que los carriles de “AUTOMÁTICO” son sus carriles, y que los de “MANUAL” son para los que no tienen de un sistema de pago automático porque manualmente, ya sea con billetes y monedas o con tarjeta.

En realidad, lo que distingue unos carriles de los otros no es otra cosa que el modo de pago. A diferencia de un supermercado en el que tanto los que pagan con billetes y monedas como los que pagan con tarjeta pasan por los mismos carriles o cajas, en los peajes se distingue a unos y otros, porque el dispositivo de cobro es diferente. Por tanto el rotulado debería expresar esto sin ambiguedades y los carteles sobre las vías deberían ser “AL CONTADO” y “TARJETA”. De este modo, se comunicaría fielmente e inequivocamente que se distingue a los conductores por cómo van a pagar.

En realidad, ésta tampoco sería buena opción, ya que en los carriles señalizados como “AL CONTADO” siempre hay un operario, y a éste se le puede pagar también con tarjeta. Por tanto, los rótulos deberían ser “AL CONTADO O TARJETA” y “TARJETA”. Lo mejor, por supuesto, es acompañar estos dos rótulos de iconos sencillos que apoyen y confirmen el mensaje para no dejar lugar a dudas. Con un sencillo icono de monedas y billetes, y otro sencillo icono de tarjeta es suficiente para acabar de comunicar que se distingue los carriles por cómo se puede pagar en ellos. Además, estos icono son necesarios para los extranjeros si el rótulo no está traducido, como es el caso aquí.

Por tanto, si antes tenían este aspecto:

Usabilidad en los peajes

Ahora tendremos éste otro:

Usabilidad en los peajes

Hemos eliminado los conceptos de “AUTOMÁTICO” y “MANUAL” porque, como hemos visto, son incorrectos y se prestan a confundir. Por otro lado, al integrar arriba los iconos de pago al contado y de pago con targeta, podemos eliminar los otros rótulos fluorescentes que están más abajo y que sólo añaden ruido visual. Las redundancias, en el caso de un sistema en el que hay pocos segundos para escoger, son negativas. También aprovechamos para quitar el rótulo verde con el icono de tarjetas que hay debajo del rótulo también verde para vehículos pesados, porque ahora es también redundante. Con lo cual la cosa nos queda así:

Usabilidad en los peajes

Pero aún hay muchas cosas que mejorar. Como bien sabe cualquier diseñador, los códigos cromáticos se suelen hacer servir para con diferentes intenciones. Pero lo que está claro es que los códigos cromáticos, si se utilizan, deben utilizarse siempre y bien. De otro modo, no sólo pierden su sentido, sino que confunden en vez de ayudar. En la imagen anterior a ésta última, hay un código cromático que identifica a los mensajes dirigidos a los vehículos pesados, el verde. El verde agrupa a 3 rótulos dirigidos a este tipo de vehículos.

Pero cualquier diseñador algo avezado en psicología humana sabrá que mucha gente, ante estos cuatro rótulos, deducirá con toda lógica que si el fondo verde se utiliza para significar “Vehículos pesados”, entonces por fuerza los fondos azul y blanco de los otros rótulos deben querer significar otros dos tipos de vehículos. Este tipo de razonamiento no es sólo completamente lógico, sino que además es también consecuencia del aprendizaje de las señales de tráfico, que son probablemente el mejor ejemplo de una señalética excelente que se basa, precisamente, en este tipo de códigos cromáticos. En el caso de las señales de tráfico, los fondos se combinan con la forma, con el borde y con iconos para expresar diferentes conceptos combinados. La gente ha aprendido a leer este tipo de códigos al estudiar para el carnet de conducir y los aplica también frente a la rotulación de los peajes.

En este peaje, parece que se ha utilizado el azul y el blanco con la intención de querer distinguir mejor un carril para pago con tarjeta y otro para pago al contado (y con tarjeta), pero es un error. En el código que estamos diseñando, los tipos de pago se comunican a través del icono y sólo a través del icono. Hacerlo de dos modos distintos, con color y con icono, como bien se sabe en usabilidad, es redundante y genera confusiones. “Dínoslo de una manera correcta, y de sólo una manera”, sería la frase.

En cambio, el color de fondo, lo estamos utilizando para identificar tipos de vehículos distintos. Verde para vehículos pesados, y por tanto el blanco o el azul, pero nunca ambos, para vehículos ligeros. En este caso prefiero utilizar el blanco, con lo cual la foto nos quedaría así:

Usabilidad en los peajes

Parece que queda más claro las dos famílias que hay, la blanca para vehículos ligeros y la verde para vehículos pesados. Pero aún queda un pequeño detalle. Dado que la redundancia es negativa como norma general en usabilidad y como norma particular cuando sólo se tienen unos cuantos segundos para tomar una decisión, como cuando uno se aproxima a un peaje, aún queda un pequeño detalle: eliminar el cartel verde con el dibujo del camión.

Finalmente, si lleváramos al extremo los principios del buen diseño y de la usabilidad, corregiríamos una asociación visual que es traicionera: el verde que identifica vehículos pesados es muy parecido al que hay en las balizas de los refugios entre carril y carril. Por supuesto, en este caso sería difícil que alguien entendiera que los vehículos pesados, identificados en verde, deben pasar por los carriles “señalizados” con balizas verdes, pero vamos a pasarnos de rosca e intentar resolver algo que no porque no nunca tendrá mayores consecuencias deja ser un error. Por tanto, cambiaremos el color verde de las balizas por uno que no se relacione en nada con los rótulos, ya que no tienen nada que ver. Hay que romper esta asociación cromática utilizando otro color.

Podríamos pintar las balizas de cualquier color excepto el blanco o el verde (ya que se asociarían con los rótulos), pero para ir a por nota, no escogeremos un color al azar, sinó que ayudaremos a distanciar más las balizas respecto de los rótulos asociando las balizas a las cabinas pintando las balizas de color azul. De este modo, ordenaremos el paisaje visual uniendo las balizas a las cabinas, comunicando por tanto que las balizas no tienen ningún significado, sino que forman parte de la estructura del peaje.

Operando estos dos cambios la cosa queda de la siguiente manera:

Usabilidad en peajes

OK, ahora queda más claro. Lo que hemos hecho ha sido rediseñar la rotulación de este peaje, de modo que esté más ordenada, más clara, tenga menos ruido visual,  y exija menos esfuerzo para ser comprendida. Para poder comparar este resultado con lo que teníamos al principio del rediseño, recupero la imagen original:

Usabilidad en los peajes

En el caso de un peaje, una buena rotulación no es una cuestión baladí, y de hecho puede tener un impacto notable. Por un lado puede ahorrar un gran número de errores como los que todos hemos visto muchas veces de coches que tiran marcha atrás porque se han equivocado de carril, y por el otro lado puede reducir el número de maniobras de último momento que algunos conductores  hacen cuando por fin localizan el carril por el que tienen que ir. En algunos casos, este tipo de maniobras provocan accidentes.

Hasta aquí el rotulado. En el próximo capítulo, cuando pueda, me centraré en las máquinas de cobro con tarjeta de los peajes.

Cómo medir la usabilidad de una web

La usabilidad es la capacidad de algo de ser usado. En el campo específico del diseño web, la usabilidad se refiere a la facilidad o dificultad con la que los usuarios de un website navegan, interactuan, encuentran información y, en general, realizan las acciones que quieren realizar en él.

Como la usabilidad es por naturaleza algo subjetivo y dificilmente medible, hay que recurrir a técnicas que, aunque aproximadas, son al menos más objetivas, para poder evaluar la usabilidad de un sitio o sistema web.

Una de estas técnicas es la medición de varias propiedades relacionadas con la facilidad de uso. Estas propiedades que hay que medir son las siguientes:

  • Satisfacción – Mediante un cuestionario anónimo
  • Eficiencia – Midiendo el tiempo que se tarda para realizar una(s) tarea(s) determinada(s)
  • Aprendabilidad – Midiendo el tiempo que se tarda en alcanzar un cierto nivel de conocimiento
  • Errores – Contando el número de errores que ocurren mientras se usa la web para completar una tarea determinada
  • Memorabilidad – Contando el número de respuestas correctas en un test de memoria del funcionamiento de la web

Algunas de estas propiedades son un poco subjetivas, como por ejemplo la satisfacción, pero aún así se puede evaluar especificando unos niveles-objetivo. Por otro lado, la eficiencia, la aprendabilidad, el cómputo de errores y la memorabilidad son propiedades más fáciles de medir matemáticamente.

Con esta técnica planteada, podemos estar seguros de que mediremos la usabilidad de un website de un modo bastante certero. De todos modos, hay otras variantes en este tipo de mediciones relativas a la usabilidad, como por ejemplo aquella en la que se miden sólo 3 factores: la eficacia (el usuario logra lo que quiere), la eficiencia (lo logra rápidamente y sin obstáculos) y la satisfacción (después de completar la tarea).

Con la técnica de las 5 propiedades, debemos asignar diferentes niveles -objetivo requeridos de usabilidad para cada propiedad que evaluamos. Por ejemplo, si la satisfacción la medimos en una escala de 1 a 5, en la que una satisfacción óptima es 5, podemos fijarnos como meta llegar al nivel 4, que ya es suficientemente difícil de conseguir, y podemos establecer que no daremos por buena una web cuya satisfacción en el uso esté por debajo de 3. Lo mismo con las otras propiedades.

A priori, otros atributos, como el número de errores, son más fáciles de evaluar, porque consiste en contar las veces que un usuario se equivoca al querer realizar una tarea. Pero ojo, no nos llevemos a engaño: identificar y comprender por qué suceden los errores requiere tanto experticia como experiencia.

Habitualmente, los requisitos de usabilidad que se quieren para un website se definen después de que se han establecido los requisitos técnicos, sin que ello suponga ningún problema. Pero si los requisitos de usabilidad se definen demasiado tarde en un proyecto web, entonces implementarlos puede ser terriblemente caro. Por tanto, idealmente los requisitos deben establecerse después del diseño y antes de la programación.

De todos modos, no está de más tampoco ir comprobando que la web cumple con los requisitos de usabilidad establecidos a medida que la vamos construyendo, es decir, en diferentes estadios del ciclo de desarrollo del proyecto. Ello nos ayudará a ir evaluando la usabilidad del sitio para que, cuando tengamos que realizar una medición de usuabilidad, logremos una buena calificación.

Por qué hay tan mala usabilidad en el open-source

¿Por qué las aplicaciones open-source suelen tener tan mala usabilidad? He aquí algunas de mis razones:

– Hay pocos incentivos para que haya una buena usabilidad. Los fabricantes de productos comerciales tienen que ganar dinero para pagar los sueldos de los desarrolladores, y eso significa que se deben esforzar en que sus productos sean usables, para maximizar ventas. En el open-source no existe esta obligación.

– Muchas aplicaciones open-source se entregan “as it is”; no suele haber un sistema de soporte técnico que colapse ninguna centralita si el producto tiene una mala usabilidad. En cambio, en el software comercial se intenta evitar al máximo las llamadas al soporte técnico y ello significa que se cuida la facilidad de uso. En el open-source los problemas de usabilidad en una aplicación no suelen tener ningún impacto en sus desarrolladores.

– Por su propia naturaleza, las personas involucradas en el open-source suelen estar centradas en el código. Cualquier otro aspecto es secundario. Ello incluye el diseño o la usabilidad, que son aspectos que quedan relegados. El resultado son aplicaciones con interfaces bastante caóticas, sin orden, jerarquía o estructura visual.

– Cualquier producto open-source necesita diseño, pero en cambio suele haber pocos diseñadores en el software libre. Tal como está pensado el open-source, no es lugar para un diseñador. Por ejemplo, mientras que un desarrollador puede identificar un bug y contribuir un patch para solucionarlo, un diseñador que encuentre un fallo de diseño o de usabilidad no puede más que indicarlo, y esperar que alguien de mala gana lo intente arreglar.

– Al no haber muchos diseñadores, muchas decisiones de diseño y usabilidad se deciden sin el criterio necesario. Al igual que los mejores intérpretes de música suelen ser pésimos compositores, los mejores programadores suelen ser pésimos diseñadores. La ausencia de criterio propicia decisones erróneas y, en consecuencia, en el desarrollo de aplicaciones con las que trabajar no suele ser muy ergonómico. En segundo lugar, al no haber diseñadores las decisiones se toman a modo de compromiso entre las sensibilidades de todos los programadores, lo que resulta en una interfaz sin unidad, integridad y consistencia.

– Los bugs son objetivos, los fallos de diseño o usabilidad son en su mayoría subjetivos. Cuesta mucho más aceptar un error de diseño que un error de funcionamiento, porque aquél es mucho menos obvio. También cuesta mucho más que el grupo de desarrolladores se ponga de acuerdo sobre si algo es un fallo de diseño o esa una “feature” especial. Al ser los errores de diseño o usabilidad más subjetivos, es más dificil llegar a su identificación.

– Se programa antes de diseñar. El software suele ser mucho más usable si se diseña antes de programar, pero los entusiastas voluntarios de muchos proyectos open-source tienen tantas ganas de escribir código que prefieren saltarse los wireframes, los prototipos y los mockups. Sin embargo, estos elementos inciden directamente en el flujo de trabajo y uso de la aplicación, por lo que afecta al modelo de datos, a los algoritmos, al orden en que las acciones se realizan, etc. Programar antes de diseñar es cómo construir una casa sin planos.

– Al ser programadores, los desarrolladores suelen ser también power users. En consecuencia, las aplicaciones están pensadas para usuarios avanzados como ellos, para los que los problemas de usabilidad de una aplicación pueden ser superados sin mayores esfuerzos, pero eso no ocurre con los usuarios normales. Ejemplo de esta mentalidad de power-user es la ausencia casi total de asistentes o de prompts que guíen la navegación, elementos que en cambio suelen ser habituales en los programas comerciales.

– Los programadores open-source, al ser voluntarios, trabajan en aquellos proyectos que les interesan. Eso suele resultar en una falta de capacidad de abstracción. Al estar tan metidos en ese proyecto, a los desarrolladores les falta distancia y visión global, y la empatía necesaria para ponerse en el lugar de los usuarios. Los árboles no suelen dejarles ver el bosque.

– Por su propio carácter libre, el open-source facilita el intercambio de código y la reintegración de componentes, por lo que a menudo muchos módulos de diferentes orígenes se integran en una única aplicación. Ello suele resultar en inconsistencias en el diseño, en el manejo, o incluso en el léxico empleado de las aplicaciones de software libre, perjudicando por tanto la usabilidad.

– Todos los programadores voluntarios quieren que su pieza de software o la funcionalidad que han desarrollado aparezca en la aplicación, y cuánto más aparezca, mejor. Para aplacar ese deseo y asegurar la continuidad del voluntario, esa funcionalidad suele meterse donde quepa y de la mejor manera, pero a menudo sólo estorba y añade caos a la aplicación, tanto a nivel de diseño como de uso. Del mismo modo, quitar componentes de la aplicación para poder mejorar la ergonomía de la aplicación suele poner furioso al desarrollador que los hizo, con lo que a veces continúan aunque sean un estorbo o rompan completamente el uso lógico de la aplicación.

– Las aplicaciones open-source suelen competir unas con otras por el nivel de features que tienen, no por su diseño o por su facilidad de uso, mucho menos por obtener una cualificación mayor en la capacidad que tienen de ser usadas por los usuarios. Ello significa que la featuritis suele primar por encima de la experiencia de usuario. La simplicidad se ve como una carencia de features, no como una virtud.

– Los programadores no suelen distinguirse por su sensibilidad estética, por lo que muchas aplicaciones tienen un aspecto visual que ellos dan por bueno pero que a menudo horrorizan a cualquier usuario normal y corriente. Que las aplicaciones aparezcan bien es tan o más importante que el que funcionen bien. Un diseño pobre no sólo decepciona estéticamente al usuario, sino que perjudica sobremanera su usabilidad.

– Detalles como informar al usuario del progreso de una acción con una barra de progreso, explicar lo que  ocurrirá al presionar un botón determinado, rotular correctamente los botones y las secciones, redactar con propiedad la mensajería del sistema o la ayuda, ilustrar la interacción del usuario con el sistema con estados como hover o focus no suelen ser muy excitantes para los programadores, por lo que suelen faltar en las aplicaciones realizadas por voluntarios. Sin embargo, tienen un efecto crítico sobre la experiencia de uso de la aplicación.

Open source no es lo mismo que software gratis (freeware), ni que software libre. Estas razones no pueden aplicarse a todas las aplicaciones open-source (por ejemplo, hay aplicaciones open-source de pago con muy buena usabilidad), sino a muchas aplicaciones que aparte de ser open-source son también gratuitas.