Amazon no es una biblioteca

En un almacén de Amazon te puedes encontrar un DVD de Walking Dead cuidadosamente colocado al lado de unos pepinillos en vinagre. No, no es un ejemplo inventado, es literal:

Algunos estaréis ya familiarizados con el llamado “chaotic storage” que usan muchos almacenes: los productos se colocan básicamente al tun-tun, aprovechando cualquier espacio libre sin tener en cuenta la relación entre ellos (más allá de características técnicas como la humedad ambiente, temperatura, etc.)

El “truco” es que los productos se asocian al lugar de almacenaje en el momento de colocarlos (mediante códigos de barras), de forma que en cualquier momento si se necesitan unos pepinillos en vinagre el sistema sabe en qué puntos del almacén se pueden encontrar.

Esta técnica ofrece mucha flexibilidad, ya que no es necesario planificar cómo evolucionarán los stocks de los productos; pero además es muy eficiente, en tres sentidos:

  • Es eficiente en espacio, ya que se aprovechan mejor los huecos, y el espacio libre en general, al no tener que reservarlos para productos del mismo tipo
  • Es eficiente para organizar nuevos ítems, ya que no es necesario conocer dónde van, sino simplemente dejarlos en el primer sitio disponible
  • Y también es eficiente para recoger, ya que un mismo producto es probable encontrarlo en muchos puntos del almacén, consiguiendo así que las cuidadosamente calculadas rutas para recoger varios ítems acaben siendo más cortas

Pero…. Si este sistema de organización es tan bueno, ¿por qué no lo usan también las bibliotecas, por ejemplo?

La respuesta es que los escenarios de uso en ambos casos son distintos. Si en una biblioteca siempre buscáramos libros concretos (conociendo, por ejemplo, su título y autor) el sistema sería factible, pero la realidad es más compleja: nuestro interés en una biblioteca puede ser explorar un tema concreto, sin conocer exactamente qué buscamos; investigar en profundidad alguna cuestión, con un enfoque exhaustivo; o simplemente volver a un libro que ya cogimos en un pasado.

Antes de plantear sistemas de organización y navegación, es indispensable preguntarse si están presentes estos tres escenarios (búsqueda exploratoria, investigación exhaustiva y reencontrar) y no quedarse únicamente con la búsqueda de un elemento conocido.

La información que importa

Overwatch es un reciente videojuego desarrollado por la empresa Blizzard. Se trata de un FPS, un juego de disparos en primera persona, en el que se forman dos equipos de 6 jugadores que compiten entre sí por un cierto objetivo. La derrota o victoria está basada en lo que hace el equipo y no únicamente en el desempeño individual de cada jugador.

Es habitual en este tipo de juegos poder ver en cualquier momento de la partida cómo lo están haciendo tus compañeros, activando estadísticas varias, especialmente el número de bajas (kills) efectuadas por cada jugador.

Tabla de estadísticas del juego
Scoreboard de Battlefield 4 (tomado de Total Gaming Network) mostrando “K/D”, kills/deaths.

En algunos juegos, para estimular que los jugadores no se centren simplemente en matar, no se muestran las bajas, sino unos puntos que se otorgan según las acciones que está haciendo cada miembro del equipo.

Tabla de estadísticas, sin "kills" ni "deaths"
Scoreboard de Team Fortress 2 (tomado de Scalari.net)

Pero uno de los objetivos de diseño de Overwatch, según su director Jeffrey Kaplan, fue eliminar el individualismo y la competencia interna (entre miembros del equipo) inherente de este tipo de juegos. Para contribuir a ello tomaron una decisión interesante: no mostrar ningún dato concreto sobre los demás jugadores.

Imagenes de los jugadores sin datos de la partida actual
Scoreboard de Overwatch (tomado de The Guardian)

La arquitecta de información Abby Cobert, en “How to make sense of any mess” escribe:

The difference between information, data and content is tricky, but the important point is that the absence of content or data can be just as informing as the presence.

En Overwatch, Kaplan y su equipo han decidido eliminar datos para moldear la información que los usuarios percibirán. La realidad, del juego, sigue siendo la misma, pero al cambiar la fotografía que mostramos al jugador estamos influenciando en sus prioridades y, con ello, en su comportamiento.

En palabras de Kaplan:

So we basically stopped displaying any form of scores, kills, deaths because it really wasn’t telling the story of who was doing their job properly to win or lose as a team. And really, what it’s all about is, “Did you win or lose as a team?” None of that other stuff really matters at the end of the day.

Experto en Axure

Como algunos sabréis, sigo desde hace tiempo las andaduras del director de cine (y daily vlogger) Casey Neistat.

Este personaje, que asumo puede despertar odio y amor a partes iguales, tiene un aparente desprecio absoluto por las herramientas que utiliza para grabar. En cualquiera de sus vídeos es fácil comprobar cómo trata despreocupadamente su cámara y es habitual verle visitar tiendas de fotografía para, simplemente, cambiar la lente que acaba de destrozar en la toma anterior.

Varias veces Casey Neistat ha descrito los principios que rigen este comportamiento, pero nunca tan bien como en un reciente vídeo:

“All I want from my camera gear is to get the hell out of my way, so I can make videos”

Todo lo que hay entre él y su audiencia, dice, son dificultades a las que debe hacer frente, pero que en ningún caso son el foco u objetivo de su trabajo.

I hate camera gear. Just leave me alone so I can make movies.
Tomado de Casey Neistat

Todos los que hacemos trabajo no tangible, como arquitectura de información, estamos en una situación similar. Queremos comunicarnos con una audiencia (un cliente, un compañero de trabajo, desarrolladores, un supervisor…) y para ello usamos herramientas de prototipado, entornos para compartir ficheros, servicios de videoconferencia y obviamente el propio sistema operativo de nuestro ordenador.

Lo lógico sería que estos intermediarios digitales fueran lo menos importante de nuestra profesión, pero curiosamente no es así. En algunos cursos de formación del sector se dedican más horas a aprender a utilizar herramientas concretas que a realmente diseñar. Veo más ofertas de trabajo solicitando “Experto en Axure” que “Arquitecto de información”. Y algunos currículos parece que la única forma que tienen de justificar su experiencia es en “horas de vuelo” de Sketch.

Al final todo este asunto me recuerda a la clásica pregunta que hacen algunos curiosos a los fotógrafos: “¿saca buenas fotos esta cámara?”.

De momento, al menos, nadie me ha preguntado si mi Axure saca buenos prototipos.

Arquitecturas de cerveza

Michael Jackson

Es difícil escribir de alguien llamado Michael Jackson sin pensar en el rey del pop, pero hoy quiero hablar de otro Michael Jackson, un escritor y periodista inglés, que dedicó mucha tinta a una bebida que todos conocemos.

Michael Jackson sujetando uno de sus libros.
Michael Jackson (imagen promocional)

Viajó por el mundo probando cervezas y escribió libros como World Guide to Beer o el Michael Jackson’s Beer Companion, obras con gran influencia en cómo entendemos hoy en día los estilos de esta bebida.

En su clasificación, por ejemplo, diferenciaba entre “Ales” y “Lagers”, cervezas de alta o baja fermentación; y dentro de “Ales” organizaba varios estilos en dos grandes categorías: cervezas británicas y cervezas belgas. A las primeras se les atribuía el origen de la “Pale ale”, una cerveza que originalmente se hacía con maltas pálidas, y dentro de “Pale ale” describía la “India Pale Ale”, un subestilo pensado para ser exportado a la India, que incluía dosis exageradas de lúpulo por sus propiedades conservantes y bactericidas.

Los libros de Jackson utilizan esta clasificación para que el lector no solo considere las características puramente organolépticas. Jackson daba mucha importancia al contexto cultural de cada cerveza, cómo y dónde se elaboraba y cómo la llamaban los autóctonos de cada lugar.

Al principio del Beer Companion, Jackson escribe:

“No one goes into a restaurant and requests ‘a plate of food, please’. People do not simply ask for ‘a glass of wine’, without specifying, at the very least, whether they fancy red or white, dry or sweet, perhaps sparkling or still … when their mood switches from the grape to the grain, these same discerning people folk often ask simply for ‘a beer’, or perhaps name a brand, without thinking of its suitability for the mood or the moment … beer is by far the more extensively consumed, but less adequately honoured. In a small way, I want to help put right that injustice.”

BJCP

Otra clasificación reciente a la que los cerveceros dan bastante importancia es la publicada en la guía de estilo de 2015 del Beer Judge Certification Program. Esta organización se dedica básicamente a proporcionar a la comunidad unas guías de cómo debería ser una cerveza para pertenecer, o no, a un cierto estilo. Para ello usan criterios básicamente organolépticos, dando menos importancia al contexto cultural o incluso procedencia de la cerveza, a no ser que ésta sea, justamente, la que marque claras distinciones sensoriales.

Beer Judge Certification Program 2015 Style Guidelines

La guía que publican, de hecho, está pensada para ser utilizada en concursos de cerveza casera, donde los cerveceros inscriben sus creaciones y compiten en categorías concretas. Se valora, pues, no tanto las características hedónicas de cada cerveza, sino su buen encaje en el estilo en el que se ha inscrito.

Un ejemplo de este criterio es el siguiente:

“English brewers, particularly when dealing in a historical context, might separate ales from porters and stouts as types of beer (although in the next breath, saying there is no difference between porters and stouts). When dealing in even more historical contexts, they might go even further to describe ale as distinct from beer in that beer was hopped (or more highly hopped) than ale. These historical notes are important for understanding old recipes and writings, but have little relevance today in the common usages of terms describing beer.”

Este criterio es lo que provoca situaciones curiosas, como tener una categoría “IPA” (India Pale Ale) que comprende estilos como “American IPA” o “Rye IPA”, pero ignora la “English IPA” que está incluida en otra categoría llamada “Pale Commonwealth Beeer” junto a estilos como la “British Golden Ale”.

Índice de la guía de estilo del BJCP
English IPA en “Pale Commonwealth Beer”

Esta decisión, que puede parecer absurda, tiene toda la razón de ser si la analizamos desde el punto de vista de un juez de un concurso de cata: independientemente de que una “American IPA” sea una evolución histórica de la “English IPA”, los niveles de amargor y el balance de estos estilos son muy distintos. No tendría sentido hacer competir en la misma categoría cervezas tan diferentes.

Y que se decida desterrar la “English IPA” de la categoría “IPA” es pura consecuencia de la evolución del significado de la expresión “IPA”:  hoy en día, cuando un consumidor pide una IPA se espera unas características que están muy alejadas de lo que aporta una “English IPA” tradicional.

Mercadona

Visto todo lo anterior, puede sorprender que al entrar en el sitio web de Mercadona nos encontremos con solo tres distinciones de cervezas: “Especialidades”, “Normal” y “Sin alcohol”.

En “Especialidades” Mercadona no solo sitúa alguna que otra cerveza de importación tipo Grimbergen Double Ambrée, sino también referencias mundanas como una Shandy Cruzcampo (una clara) o incluso lo que llama “Cerveza Fuerte Voll-Damm” (sic).

Listado de especialidades dentro de Bebidas - Cervezas
Las “especialidades” de Mercadona

En los supermercados físicos la clasificación es parecida: sin ningún etiquetado evidente simplemente se agrupan las cervezas “normales”, realmente lagers industriales tipo pils, como podría ser una Estrella Damm; y en otro lado se nos ofrecen “especialidades” como cervezas de importación y alguna que otra cerveza artesana local.

Arquitecturas de cerveza

¿Está mal la clasificación de Mercadona? ¿Es mejor la del BJCP? ¿O quizás es Jackson quien acierta?

Antes de clasificar algo debemos preguntarnos por qué estamos clasificando y para quién lo estamos haciendo.

El libro de Jackson es una herramienta de aprendizaje para cerveceros; la guía de la BJCP un instrumento de evaluación para jueces; y Mercadona un supermercado, sin ningún interés pedagógico, para cualquier persona cuya máxima aspiración cervecera será, probablemente, “probar hoy algo nuevo”.

Crear arquitecturas, como decía Le Corbusier, es “poner en orden”. Ordenando generamos arquitecturas de las que es posible interpretar una cierta información. Nuestra responsabilidad, como arquitectos, es facilitar esa interpretación creando las arquitecturas adecuadas a la información que queremos transmitir.

Diseñando una navegación

Hace unas semanas participé en un proyecto de diseño de una intranet. Se tuvo que plantear, entre otras cosas, un sistema de navegación para moverse cómodamente entre varios elementos de un mismo nivel de la estructura de información. La particularidad era que el número de elementos variaba en función del usuario de la intranet que hubiera accedido.

¿Qué hacer en este escenario? ¿Qué debemos pedir al cliente?

Una aproximación totalmente absurda sería pensar sólo en el caso mejor: pediríamos al cliente cuál es el número mínimo de elementos (sólo uno, de hecho) y diseñaríamos ignorando el resto de casos. No creo que sea necesario justificar el porqué esto es una estupidez (aunque la realidad sea que uno a veces se encuentra diseños planteados así).

Otra opción que puede parecer más razonable es solicitar al cliente cuál es el caso peor, el número máximo de elementos que la navegación debe “aguantar”, y diseñar algo acorde a ello. En el proyecto que nos ocupa ese máximo era el medio millar. Esta alternativa es mejor que la anterior, pero sigue siendo una aproximación estúpida: el caso peor puede darse en muy pocas circunstancias y aunque debe ser considerado no podemos focalizar toda la interfaz a satisfacerlo ignorando el resto.

Una tercera opción es solicitar al cliente dos números: el caso peor y el promedio (media aritmética). Así podríamos intentar diseñar una interfaz focalizada en lo más habitual y hacer las variaciones necesarias para soportar el caso peor. El problema es que este argumento tiene un fallo importante: un promedio no necesariamente será un caso habitual. De hecho en el proyecto el promedio era de 5 elementos, pero esto sólo representaba un 2% del total de usuarios

La cuarta opción es mi recomendación: pedir toda la información que sea posible. Siempre. Queremos el detalle de cuántos elementos tendrá cada uno de los usuarios. ¿Y qué hacemos con todos estos datos? Pues para empezar representarlos visualmente:

Gráfico de barras de 1 a 500. El 1 es significativamente mayor que el resto.

La representación visual nos da una idea clara de la distribución de los usuarios por número de elementos. Vemos que lo más habitual, con diferencia, es tener un único elemento y que la larga cola es larga pero fina.

Esto nos puede llevar a plantear un diseño de una navegación con las siguientes variaciones:

  • Para la gran mayoría de casos (un 70% concretamente) no necesitamos navegación alguna. Simplemente debemos mostrar el elemento.
  • Para algunos otros casos (un 20%) podemos proporcionar una navegación sencilla de un máximo de 10 elementos.
  • Para el resto (un 10%) proporcionaremos una navegación especial, pero sin rompernos demasiado la cabeza: un sistema de búsqueda y los elementos consultados recientemente fue suficiente para el proyecto.

Para este análisis estamos suponiendo que todos los usuarios tienen la misma importancia. A veces puede no ser así.

Vera y la serendipia

En la película Unmade Beds hay una escena en que Vera, la chica protagonista, es regañada por su jefe por dejar un libro donde no toca. Vera trabaja en una librería y parte de su cometido es mantener cierta organización, pero considera que tener un libro fuera de sitio permite que clientes que nunca lo habrían ido a buscar lo descubran por azar.

Cuando diseñamos sistemas interactivos buscamos siempre ofrecer orden y organización al usuario: debe saber en todo momento qué hacer para encontrar lo que busca o necesita, pero… ¿no es bonito perderse a veces?

En algunos contextos puede tener sentido ofrecer una organización que permita sumergirse en los contenidos, perderse por ellos sin tener referencias ni sistemas de orientación. Esto es justamente lo que hacen en el videoclub online @filmin (probablemente por sugerencia del estudio de diseño @vostokstudio) donde hay una forma de navegar por las películas que responde a la pregunta “¿Qué te apetece ahora?”.

Quien decida explorar el catálogo de esta forma verá que tiene a su disposición categorías como “Para días de lluvia”, “Lo que le gusta a Tarantino” o “Comer una hamburguesa”, opciones que parecen la antítesis de la buena organización pero tienen intencionalidad: son puertas a la serendipia y mecanismos para que el usuario no sólo disfrute viendo la película, sino también en su búsqueda.

Contenido adaptativo

El otro día tuve la suerte de escuchar en directo a Josh Clark (@globalmoxie) y Karen McGrane (@karenmcgrane) en un evento organizado por IxDA Barcelona. Asistir a este tipo de charlas en un pub, con notoria abundancia de cerveza, siempre te hace un poco menos receptivo al segundo ponente, Karen en este caso, pero aún recuerdo con claridad el título de su presentación: «Adapting Ourselves to Adaptive Content».

Karen habló de un tema que ya casi suena a rancio: contenidos y presentación deben diseñarse por separado. Hizo especial hincapié en saber trocear la información, habilidad a medio camino entre la arquitectura y el diseño de bases de datos, y en su importancia para poder enfrentarse a distintas interfaces, actuales y futuras.

Tiene sentido hablar de nuevo de este asunto no simplemente porque aún no lo hayamos entendido, sino por el boom multi-dispositivo que estamos experimentando en los últimos años. Móviles y tabletas están dejando en evidencia a más de uno, especialmente en el mundo editorial, y si sigue la penetración de las Smart TV vamos a ver suicidios colectivos.

Karen expuso un ejemplo interesante: el de una revista americana de televisión que hace más de 20 años tuvo la visión, o estupidez, de empezar a escribir tres descripciones de distintas longitudes para cada programa en emisión. Estas descripciones, inútiles en su momento, han acabado siendo utilizadas en distintos dispositivos modernos, desde móviles a Smart TVs, pudiendo así adaptar el contenido a cada interfaz particular.