Ocho viejos errores que siguen sin solucionarse en la web actual

Pasan los años, avanzan los estándares, evolucionan los navegadores, vienen nuevos desarrolladores y nuevas paradigmas de desarrollo (con abundante e incluso excesivo javascript, que no falte), pero hay errores que, a pesar del paso del tiempo, siguen estando presentes. Aquí van algunos:

Error 1: No identificar el idioma (lang) de una página adecuadamente

Es un pequeño detalle, pero muy importante. Si una página está en inglés (en), español (es), francés (fr), chino (zh), esukera (eu), catalán (ca), gallego (gl),… debe estar especificado en el código fuente. Por ejemplo <html lang="lt"> para una página en latín.

Simplificando mucho: para el valor del atributo lang se emplea un valor ISO-639-1. También se puede añadir el código del país tras un guión, como lang="es-es" para español de España. Pero puede ser bastante más complejo, como se puede consultar en Tags for Identifying Languages.

Error 2: No incluir un título apropiado para la web (title), ni para el contenido (h1)

Los elementos title y h1 nos ofrecen la posibilidad de resumir el contenido de una página web en unas pocas palabras (a personas y buscadores). Es una irresponsabilidad no utilizarlo adecuadamente. Tal vez, y salvo excepciones, una buena elección sea usar el título del documento para el h1, el mismo literal acompañado del nombre del dominio para el título.

Error 3: Usar textos ambiguos en enlaces (por ejemplo «aquí»)

El clásico error: usar términos como texto de un enlace que no tiene ningún significado leído fuera de contexto. ¿A qué me refiero? Usar textos como «aquí», «enlace» ó «página» no aportan nada de información.

Si para saber dónde nos lleva un enlace tenemos que leer el párrafo entero o la frase en la que está el vínculo, cometemos un grave error doble:

  • Hacemos perder el tiempo a los usuarios
  • Perdemos una buena oportunidad de mejorar el posicionamiento web.

Mi consejo: usar el título del documento de destino como texto del enlace.

Curiosidad SEO: hace años al buscar «aquí» en Google nos mostraba la página de descarga de Adobe Acrobat Reader. El obvio motivo es la infinidad de vínculos con el texto «aquí» que enlazaban esa página. De ahí la importancia para el posicionamiento de los enlaces.

Error 4: No diferenciar apropiadamente los enlaces mediante estilos

Otro serio problema: no diferenciar con claridad, los enlaces del texto que le rodea. ¿Dónde puedo hacer click, tocar? En no pocas ocasiones, al prescindir del clásico subrayado, perdemos un factor importante para diferenciar un enlace de un texto normal. En ocasiones el único.

Hay un porcentaje importante de usuarios con discromatopsia ( incapacidad para distiguir ciertos colores). Y en general, desde el punto de vista de la accesibilidad, es una mala práctica usar el color para transmitir información: por ejemplo que la única forma de distinguir un enlace sea por el color del texto.

Obviamente hay situaciones, como menús de navegación y enlaces con apariencia de botones, en los que el subrayado no es necesario. Pero en el resto de los casos, recomiendo subrayar los enlaces. Facilita mucho a los usuarios encontrarlos y evita frustración… por no hablar de evita perder visitas.

Error 5: No incluir alternativa textual (alt) en las imágenes

En HTML5 también está figcaption, pero alt sigue teniendo toda su vigencia e importancia: describir textualmente una imagen, ya sea para las personas o para los buscadores es una obligación moral y técnica.

Error 6: Insuficiente contraste entre el texto y el fondo

Entiendo que el color (y el contraste) es una forma que funciona para destacar unos elementos sobre otros. Pero se sobrepasa con demasiada frecuencia el límite del contraste mínimo: pensad que se pueden dar situaciones de iluminación nada óptimas (el móvil en la calle acompañado de un pequeño tamaño del texto), discapacidades visuales (la edad, la mencionada discromatopsia que dificulta diferenciar colores,…) y no tiene sentido incluir un texto que no se puede leer en cualquier contexto.

Siendo más concreto: no entiendo (ni comparto), el uso de fondo oscuro (casi negro) con un texto minúsculo en color gris medio.

¿Cómo remediarlo? con herramientas como contrastchecker.

Error 7: Que la web no se visualice apropiadamente en un teléfono móvil

La aparición del iPhone (2007) ha sido sin duda un hito en el desarrollo de la web móvil. Más de diez años más tarde, no tiene sentido que una web no se visualice apropiadamente en un teléfono móvil corriente.
Sorprende, que en numerosos casos, hay más usuarios que acceden a una web desde un teléfono móvil que desde ordenadores de sobremesa. Pensemos además en que pueden tener una conexión lenta, o ciertas restricciones en el uso de datos (que se consumen con mucha facilidad).
La cifra de personas que acceden a una web desde un teléfono móvil debería ser uno de los datos más importantes a la hora de desarrollar web y pensar que un exceso de recursos (kilobityes de imágenes, scripts, estilos,…) repercute negativamente y aleja a los posibles usuarios.

Error 8: Que no cumpla unos requisitos mínimos de accesibilidad.

Las WCAG 1.0 se publicaron como recomendación en el año 1999. La segunda versión (WCAG 2.0), se publica en el 2008 y la última (WCAG 2.1), en el año 2018. La legislación ha ido, con cierto retraso, siguiendo los pasos del W3C, pero ahí tenemos en Europa y España las últimas novedades (leer Disponible la UNE-EN 301549:2019 de accesibilidad para tener algo más de información).

Impedir o dificultar el acceso a una web a una parte nada despreciable de personas, es una imprudencia. Y si entramos en términos morales, una discriminación inmerecida. Si el argumento moral no funciona, tal vez sea más convincente el asunto de la pérdida de visitas o beneficios por ventas, oportunidades de negocio o publicidad.

Apunte final: la mayor parte de los errores aquí mencionados están muy relacionados con la accesibilidad. Da para una pensada en profundidad.

Cómo crear un diseño más simple

En una época –la de las constantes distracciones–, en la que encontrar el foco puede considerarse una hazaña, la sencillez y la simplicidad tienen aún más importancia.

Es bastante conocido el ya veterano libro de John Maeda The Laws of Simplicity. Con este punto de partida, Taras Bakusevych, ha desarrollado un interesante artículo titulado How to simplify your design, en el que muestra con ilustrativos ejemplos cómo encontrar esa simplicidad tan necesaria y vencer la complejidad, que clasifica de la siguiente manera:

  • Information overload
  • Randomness and disorder
  • New and foreign experences
  • Multitasking
  • Multitudes of choices
  • Rely on the user memory
  • Distractions and break the focus
  • Repetitive and monotonous operations

Consta de los siguientes apartados:

  • Build products with focused value
  • Remove everything unnecessary
  • Translate data into a meaningful format
  • Support quick decision making
  • Too many choices will scare off customers
  • Provide recommendations where multiple choices are presented
  • Draw users attention to the right areas
  • Use color and typography to communicate a hierarchy of content
  • Organizations help the system of many look fewer and more manageable
  • Group related content
  • Break up huge tasks in smaller steps, try one column layout
  • Be transparent in communicating the process and system status
  • Do the calculations for your user
  • Hide complexity with progressive disclosure
  • Rely on commonly accepted patterns and interactions
  • Design a streamlined first-time experience
  • Keep in mind ergonomics and circumstances under which product will be used
  • Support inline edit and autosuggest values
  • Use Smart Defaults to Reduce Cognitive Load
  • Prevent errors
  • Design for accessibility
Y está muy bien explicado y más desarrollado con buenos ejemplos en How to simplify your design.

Haikuemas: la aplicación, el ebook, el libro (II)

Siguiendo lo que se contaba en Haikuemas: la aplicación, el ebook, el libro (I) …

Un libro electrónico

Dos proyectos para escribir un libro en punto muerto, y al final fructifica el último en llegar. ¿Los motivos?

  • Honestamente, algunos versos y haikuemas iniciales me gustaban mucho. Trabajando más en ello, podrían mejorarse.
  • Conceptualmente la obra que tenía en mente me parecía interesante: un recorrido en versos a lo largo de un año, viendo el paso del tiempo por diferentes acontecimientos de la naturaleza (del clima, la fauna, la flora) con una mezcla de imágenes de la que considero mi tierra.
  • Tenía ganas de publicar un libro en papel.

Resultado: salió el libro en formato electrónico en Amazon KDP (una herramienta bastante útil). Numerosos borradores (más de veinte), correcciones, cambios, la introducción, las dudas, el enfoque, los aspectos técnicos, diseño editorial, portada,… Desde que empecé con las primeras versiones en 2015 hasta que se publicó en verano del 2016 pasó más de un año. Utilicé Sigil para editar el ebook: y aprendí que un epub no deja de ser HTML + CSS + imágenes, y para un maquetador web, es un reto asequible el mejorar y optimizar el epub.

Ilusionado ví como, gracias a la generosidad de algunos amigos-lectores, durante algunos días estuvo como best seller en la sección de poesía (un indicio de que no se venden muchos libros den esa sección).

Haikuemas, libro de poesía más vendido el 15 de Julio del 2016 en Amazon

El libro en papel

El siguiente paso lógico (pero no tan sencillo), era sacar el libro en papel. Y de nuevo Amazon KDP facilita y reduce el precio del libro. Estuve tanteando otras plataformas de autoedición, pero al final había que hacer un pedido mínimo (desde 50 libros) y la gran ventaja de Amazon es que se imprime bajo demanda: por lo que puedes experimentar con borradores antes de dar con una versión «definitiva».

Elegir el tamaño del libro, remaquetar el contenido, elegir fuentes, rediseñar la portada (el proceso más laborioso y complejo), elegir el precio de venta, repasarlo todo una vez más,… hasta que tienes un fichero en formato doc ó pdf, superar las revisiones automáticas de Amazon KDP (muy útiles, aunque no perfectas), y las que hace uno mismo. Sólo falta enviar, guardar y hacerlo público.

El resultado, el libro impreso. Y tras algunas correcciones, la versión definitiva.

¿Ventas? Pocas, y casi siempre de conocidos. No era para mí lo importante.

¿Satisfecho? Mucho, sobre todo por el proceso y también por el resultado.

¿Habrá más libros? Probablemente. Hay dos o tres candidatos.

El largo y gratificante proceso

  • Juntar la necesidad de leer y escribir con la satisfacción de publicar.
  • El interés por el diseño editorial y la posibilidad de trabajar en ello: secciones del libro, diseño de páginas, tipografía,…
  • El apredizaje lento e inseguro sobre diseño, y el poder diseñar dos portadas reales (la original del ebook y la definitiva del papel).
  • La cantidad de horas dedicadas a aprender cosas nuevas que realmente te interesan, poder experimentar y aplicarlo en un proyecto concreto.
  • Pasar de conocimientos teóricos, a la realidad de la práctica.
  • El placer de aprender y hacer algo que se pueda tocar.
  • La importancia del camino, más que de la meta.

Cosas que importan, aunque a veces se olvidan.

Curiosidades

  • El empujón y apoyo de Pilar Gómez Rodriguez (una escritora de verdad) ha sido muy importante. Gracias.
  • En el origen, el libro era puro azar. Pero ha habido numerosas revisiones. Podría decir que el azar sirvió de semilla para la versión definitiva.
  • Hay algunas versiones del ebook dedicadas: GIMP para modificar la portada (con dedicatoria escrita en una fuente de tipo script), Sigil para personalizar la dedicatoria y listo 🙂
  • Hay tres versiones «beta» del libro en papel: primera con la portada en blanco, segunda con texto en blanco algo ilegible, y tercera con los colores cambiados (!vaya fallo!). Alguna hay vendida, pero la mayor parte las compré yo 😉
  • Las dos portadas (la inicial del ebook y la definitiva del ebook y del libro en papel) han usado fotografías hechas con una vieja cámara telemétrica: mi Yashica 35-ME.
  • La portada, aunque quizás sea trivial, utiliza cuatro colores que representan las estaciones. Si juntamos las portadas y contraportadas varios libros, se forman dos ciclos entrelazados. Invito a buscar interpretaciones 🙂

¿Comprar el libro?

Ah, por cierto, si alguien está interesado, lo puede comprar en Amazon:

También en B&N: Haikuemas de las cuatro estaciones (Barners & Noble)

Haikuemas: la aplicación, el ebook, el libro (I)

Siempre hay una historia.

Rosendo Mercado.

Y aunque tenga un interés relativo, quería contarla. Es la historia de un libro. Pero está formada de varios fragmentos que al final se unen.

El azar

Fascinación. Es lo que siento sobre el hecho de contar historias usando el azar. Tres buenos ejemplos:

  • Un compositor de canciones melódicas, publicado en la revista de humor El Jueves especial música de hace algunos años, creado por Albert Monteys y/o Manel Fontdevilla: era tabla de tres columnas con versos, y al mezclar un verso de cada columna, salía una estrofa de una canción. Y mucho mejor que muchas que suenan en la radio 🙂
  • Presentr (creo que era el nombre) ideado por Luis Villa, que generaba títulos de keynotes con toda la palabrería sin sentido de la época de la web 2.0. Muy gracioso.
  • Story cubes: dados con imágenes, que sirven para contar historias. Aunque para los más avispados, puede ser una herramienta muy versátil.

Ejemplos que pueden ser muy inspiradores, como cuento a continuación.

Las aplicaciones web

Mi primera aplicación web se llamaba Cuentos Locos. Varios arrays de cadenas de texto (época, lugar, protagonista, características, acción intrascendente, coprotagonista, características y misión), una programación relativamente sencilla y mucho humor. El fruto es una aplicación que puede generar el inicio de más de un billón (millón de millones) de diferentes cuentos, en muchas ocasiones alocado, con un final abierto. Porque contar los mismos cuentos de siempre puede ser aburrido. Y el comienzo de un cuento nos puede ayudar a estimular la imaginación, buscando un final muy original.

Los Haikus (de verdad)

Elements of Japanese Design (uno de mis dos libros de diseño favoritos, junto con Universal Principles of Design) me ha servido para mejorar mis limitados conocimientos de diseño, y también para conocer algo más de la cultura japonesa. Y de forma inesperada, para comprender un poco más los haikus.
Aunque más allá de lecturas fragmentadas, no he encontrado nada mejor para comprender los haikus que la transcripción de la Conferencia del Dr. Vicente Haya en Sofía, Bulgaria (12 de Noviembre de 2010), un reconocido experto en haikus.

Esquemáticamente, un haiku suele tener las siguientes características:

  • Es un tipo de poema de tres versos de 5, 7 y 5 moras (concepto relacionado con las sílabas).
  • Es originario de Japón.
  • Suele incluir un término o frase que hace referencia a una estación del año, denominado kigo.
  • Se produce un corte o separación entre dos imágenes mediante un kireji.

Haikuemas ¿?

Por algunas características (tres versos, referencia a las estaciones, ese corte ó kireji), digamos que es fácil encontrar patrones para generar algo remotamente parecido a haikus mediante programación: nada de un complejo robot de inteligencia artificial, tan solo hablo de crear poemas mediante la mezcla aleatoría de versos.

Aunque lo complicado es escribir esos versos: por las limitaciones de longitud, la coherencia temática y técnica, la lírica, y mi obsesión porque cada verso tuviese tuviese una imagen sugestiva muy superior a la longitud de los versos. Ha sido complejo.

Por respeto a los lectores y autores de haikus, llamé al resultado de este experimento de composición literaria y programación lúdica haikuema (palabra inventada mezcla de haiku y poema): No es un haiku, se inspira en ellos, y aspira a serlo.

El resultado acabó siendo  haikuema, una aplicación que muestra una pequeña composición poética relacionada con cada estación del año, con una paleta de colores propia.

Y la historia continúa… en Haikuemas: la aplicación, el ebook, el libro (II)

Proceso de diseño de UX y herramientas

This design process demands creation, communication, collaboration and validation.

Julius HuijnkA true UX tool

La cita es el punto de partida del que se vale el autor para plantear qué debería tener una aplicación que sirva en todas las fases del proceso de diseño, en este caso desde un punto de vista de la experiencia de usuario. Menciona bastantes aplicaciones que se usan en fases concretas, pero también explica sus carencias y las necesidades que no consigue solucionar.

Creo que es una lectura recomendable.