El año pasado estuve realizando algunas consultorías sobre accesibilidad que resultaron muy interesantes. Sobre todo no deja de asombrarme el entusiasmo de los miembros de los equipos involucrados. Eso es algo bueno en sí mismo. Sin embargo no es de eso de lo que quiero hablar en este momento, sino de una herramienta que utilicé por primera vez en este contexto.

Muchos estamos familiarizados con las personas como herramienta para lograr una mayor aproximación de los equipos hacia los usuario finales. Se trata básicamente de lo siguiente: identificar perfiles claros de grupos de usuarios, determinar las caracterísiticas más comunes de cada uno de esos perfiles y finalmente crear una narración breve con la descripción de un personaje inventado que reúna estas características. Se trata de inventar personajes con esas características, incluso les asignamos un nombre y una fotografía para hacerlos más reales, de modo que el equipo pueda tener un rostro con características propias para quien desarrollar el sitio, aplicación o funcionalidades específicas.

Las personas, como herramienta de diseño centrado en el usuario, son tremendamente útiles, en tanto permiten a los miembros de un equipo tener una aproximación más real con el destinatario final del proyecto. Normalmente habrá tantas personas como perfiles de usuarios se identifiquen para cada proyecto.

Lo interesante es que podemos utilizar las personas como herramienta de accesibilidad, para facilitar la implementación de técnicas que mejoren la accesibilidad de un proyecto.

En un proyecto ideal, deberíamo considerar la accesibilidad como un parte integral desde el principio del desarrollo y esto implica que no se debería realiar un esfuerzo adicional para mejorar la accesibilidad de un sitio, por ejemplo. En esta situación, podría existir una o dos personas que permitan identificar características generales de usuarios con las discapacidades más comunes en el web, una persona con ceguera total y otra con problemas de visión no extremos. Un ejemplo puede ser el siguiente: tenemos una persona que, a grandes rasgos, se llama Diego, tiene 55 años, tiene poblemas de miopía avanzados, usa internet explorer para navegar pero aumenta el tamaño de los textos al máximo que le permite el navegador para facilitar la lectura. Durante el desarrollo del proyecto podríamos presenciar esta conversación:

Jefe de Proyecto:

Tenemos que desarrollar la página de registro, para aumentar la seguridad y los riesgos del registro mediante scripts automatizados se propone el uso de capchas.

Miembro del equipo o reponsable de accesibilidad:

Me parece, pero debemos verificar como interactuaría Diego con los capchas. Tú sabes, son imágenes y normalmente no podrá aumentar su tamaño. Creo que deberíamos estudiar un mecanismo altenativo o ver la forma de facilitar eu amplíe la imagen. Por otro lado debemo asegurarnos de que exista también un méodo alternativo para Ana que es ciega y no podrá registrarse si no puede conocer el contenid de los capchas.

La posibilidad de personalizar características simplifica mucho el proceso de revisar los requerimientos de grupos de usuarios con características particulares.

Volviendo a la experiencia que mencioné al principio, como mi rol se trataba de asesorar en la adaptación de un sitio ya existente a normativas de accesibilidad, creé un grupo de personas que reunieran las características más notorias de los potenciales usuarios discapacitados de este sitio. El resultado es tremendamente positivo, los miembro de los equipos pueden personificar características que de otro modo serían abstractas y difícilmente asimilables. Eso garantizará un mayor éxito en la implementación de accesibilidad y una mayor consciencia en el equipo.

Esto es algo que hasta hace muy poco tiempo en Chile parecía imposible y que personalmente jamás pensé que podría ver. Hoy se notificó de sus condenas y encarceló a los máximos diregentes de la disuelta Dirección de Inteligencia Nacional, DINA, responsable bajo mando directo del General Augusto Pinochet de las más aberrantes violaciones a los derechos humanos cometidas en nuestro país durante la dictadura militar. Los arrestados son Manuel Contreras (12 años), Marcelo Moren Brito (11 años), Miguel Krassnoff Marchenko (10 años), Fernando Laureani (5 años) y Gerardo Godoy (5 años).

Esto no es un juicio político, ellos fueron enjuiciados y encontrados culpables, en este caso, de la desaparición desde enero de 1974 hasta la fecha de Miguel Angel Sandoval, un militante de izquierda. La desaparición significa que, como más de 3.000 otras personas en Chile y otras en latinoamérica principalmente durante los 60 y 70, fue asesinado y su cuerpo escondido o destrozado de modo que nunca volviera a aparecer. Los ahora reos tienen cada uno una serie de otros juicios en curso por causas de derechos humanos.

Comparto esto con ustedes porque la violación a los derechos humanos no tiene fronteras. Así como resulta horrible cualquier atentado contra la dignidad y vida de las personas en cualquier parte del mundo, sea 9/11, 11-M o aquéllas producto del golpe de estado de 1973.

No todo es acerca de las máquinas y el web.

Más información en Google News Chile.

Las siguientes imágenes son fotografías que tomé con mi cámara digital de la cobertura de esta noticia por diversos canales de televisión chilenos.

Estos días he estado ocupado resolviendo el diseño de un sitio. Mientras pensaba en una solución para el menú de navegación secundario, compuesto por elementos auxiliares como ayuda, contacto, en fin, aquellos elementos que entregan una funcionalidad diferente o complementaria a la de navegar contenido, me detuve a pensar en el ya clásico ícono de portada del sitio o home page.

Sucede que el ícono típico para representar la función de ir a portada o inicio del sitio se representa frecuentemente con una casa pequeña, simple, claramente reconocible. Sin embargo, su uso es una herencia directa del uso anglo, en que la casa, home representa la portada, home page. Pero, ¿qué significa eso para cualquiera que no sea angloparlante? Absolutamente nada. Nosotros no utilizamos el concepto de página hogar, y hogar del sitio para referirnos a la portada. Por lo tanto la metáfora queda invalidada.

Este es uno de esos clásicos problemas de internacionalización (i18n) en que sin pensarlo, asumimos como propios conceptos que no se aplican correctamente a nuestros contextos. La pregunta es ¿por qué lo hicimos, por qué asimilamos el concepto de home page tan fácilmente? Se me ocurre que se trata de una cuestión práctica: no puedo pensar en representaciones gráficas directas y simples para portada. Y hasta donde conozco, no hay muchas más variantes del concepto: página de inicio, página de entrada, menú (muy confuso!), página principal.

Para averiguar la frecuencia de uso y las aplicaciones del ícono home realicé una exploración no demasiado extensa, pero sí considerable. Revisé aproximadamente unos 100 sitios vinculados desde news.google.com, news.google.es, news.google.cl y una serie de directorios de yahoo.com y yahoo.es.

Lo primero que observé, y que seguramente debió haber sido algo obvio, pero no había reparado en ello, es la marcada tendencia a utilizar vínculos textuales en lugar de íconos. En general, los menús compuestos por íconos son muy pocos. En consecuencia, me costó bastante conseguir ejemplos de algo que supuse iba a ser más fácil. Esto, sin embargo, no desacredita el punto de fondo que estoy tratando, el uso de home en lugar de portada u otro término similar.

Como nota curiosa, me sorprendí con el uso de la palabra home como elemento de navegación en un par de sitios en que no se utilizaban íconos, para referirse a su página principal. No quiero que se me malinterprete, no tengo nada en contra del inglés y la adopción de neologismos cuando es apropiado. Pero creo que portada o página de inicio dejan bastante claro el concepto.

En concreto, las observaciones de mi revisión (completamente no-científica) son:

• del total de sitios revisados, una minoría utilizaba íconos para su navegación;
• las aplicaciones son diversas, en algunos casos sumado a la ambigüedad del propio concepto home los gráficos resultan casi incomprensibles;
• la tendencia mayoritaria es a usar los términos portada e inicio;

Para ser honesto, no he resuelto el problema de encontrar una representación que me satisfaga. Y para este proyecto decidí no utilizar íconos, sólo un vínculo a portada.

El Principio

Desde que comencé a utilizar CSS, hace ya algunos años, he buscado formas más eficientes de estructurar las hojas de estilo. En el principio todo se reducía a una hoja de estilo (normalmente llamada principal.css,main.css o diferentes variantes) que internamente estaba organizada de modo que las definiciones de elementos de HTML (body, p, h1…h6, etc.) estaban al principio, luego los IDs y finalmente las clases.

Aparece CSS 2

En algún momento, mientras comenzaba a incorporar elementos de diagramación y posicionamiento, las hojas se hicieron cada vez más complejas. La organización interna se hacía gradualmente más difícil de seguir y determinar los pesos de cada elemento en la cascada resultaba una tortura.

A la vez descubrí el potencial de CSS para generar opciones para distintos dispositivos de salida y comencé a incluir print.css, en la que desde entonces defino el estilo de impresión importándola con el atributomedia="print".

La Separación

El siguiente paso fue bastante lógico: separar el archivo principal en dos. Uno manejaría los aspectos básicos de estilo para los elementos de HTML, esencialmente fuentes, colores y tamaños. El otro se encargaría de la definición de elementos de diagramación y posicionamiento. De este modo se generaba una situación en la que la primera hoja, que seguía llamándose main.css, contenía casi exclusivamente CSS 1, y la segunda hacía fuerte uso de CSS 2. Esta estrategia inicial tenía mucho sentido para aislar a browsers antiguos como Netscape 4.x, más aún si lo combinabamos con el hack @import que éste no reconoce, por lo que esas definiciones de estilo le resultan invisibles, pero el usuario puede de todos modos acceder al contenido sin estilo, o al menos parcialmente estilizado. Esto es lo que llamamos degradación positiva o graceful degradation.

En ese momento ya coexistían tres archivos de estilo, main.css, layout.css y print.css. Con el uso y el tiempo surgió la necesidad de modularizar aún más esto y nacen hojas como forms.css para manejar exclusivamente los elementos de formularios.

Nace el Color

Actualmente estoy yendo un paso más allá: para agregar una capa adicional de abstracción o separación, estoy utilizando una hoja llamada color.css, en la que defino sólo los colores. Cuál es la ventaja? Sencillo, si quiero o necesito modificar la paleta completa de colores de un sitio, sólo tengo que modificar color.css. Esto facilita la tarea de proveer diseños alternativos, realizar actualizaciones rápidas e incluso modificar plantillas prearmadas para propósitos específicos, personalizándolas con colores propios.

Modularización

El concepto clave detrás de toda esta estrategia de manejo de estilos es la modularización: agrupar los elementos comunes y aislarlos de los demás para conformar estilos pequeños, fácilmente manejables y altamente reutilizables. Estos son conceptos prestados de programación, pero resultan sumamente apropiados en este contexto.

La modularización de los estilos no sería lo mismo sin una cuidadosa estrategia de manejo de CSS. Mi técnica favorita consiste en vincular sólo una CSS externa en el HTML mediante el elemento link:

<link href=”styles/main.css” rel=”stylesheet”
type=”text/css” />

De este modo el HTML permanece limpio y efectivamente separado de la presentación. Las demás hojas se vinculan desde el archivo main.css:

@import URL(“layout.css”);
@import URL(“forms.css”);
@import URL(“color.css”);
@import URL(“print.css”) print;

Esto último tiene una flexibilidad enorme: puedo agregar o quitar hojas de estilo sin siquiera modificar el HTML, porque éste siempre vincula sólo a main.css, lo que allí ocurra es harina de otro costal.

¿Alguien más notó el cambio en Amazon.com? Aparentemente desde el 22 de Octubre se publicó un nuevo sistema de navegación global diferente del clásico sistema de pestañas. Parece ser que los cambios están siendo presentados a los clientes (he comprado varios libros en Amazon.com) y los usuarios nuevos ven la interfaz tradicional.

Jugando un poco con los parámetros he comprobado que se puede forzar la vista de categorías con esta URI.

Actualización: Aparentemente el mecanismo de despliegue es aleatorio, es decir, se presenta la interfaz nueva a un grupo de usuarios seleccionados al azar, por lo que la URI del párrafo anterior puede no funcionar.

El nuevo sistema presenta sólo dos pestañas, una con la etiqueta Welcome y la otra All Categories. La primera contiene opciones de navegación relacionadas con elementos globales como las tiendas internacionales, productos destacados, etc., en suma, un criterio transversal de contenidos. La segunda no tiene opciones secundarias, pero nos conduce a lo que puede ser el cambio más interesante: un sistema de categorías como el directorio de Yahoo! o Google con todas las áreas de Amazon.com.

El cambio me parece positivo hasta ahora, se observa un sitio más organizado y limpio. La estética del sitio continúa siendo la misma: la paleta de colores y los elementos secundarios son los mismos, el cambio es más bien en la navegación global.

Cabe señalar que el nuevo encabezado de Amazon.com incorporaba hace unos días una interfaz de búsqueda del recientemente lanzado producto de Amazon, A9.com, pero mientras reviso el sitio no puedo encontrarlo, es posible que haya sido removido.

Si te interesa revisar el sitio antiguo para constatar las diferencias, está disponible vía Internet Archive Wayback Machine.

Durante el desarrollo de una serie de sesiones de capacitación que estoy realizando como parte de una asesoría de accesibilidad he hecho más consciente algo que es evidente, pero no había terminado de racionalizar. Me refiero a la relación entre las prácticas de accesibilidad y la optimización para motores de búsqueda.

Sucede que en la medida que utilicemos prácticas simples de accesibilidad como el uso de gramáticas formales, de implementaciones tecnológicas que se degraden apropiadamente, no dependan exclusivamente de tecnologías de cliente o creamos sitios que consideren el uso de diferentes dispositivos estamos permitiendo a un rango mayor de usuarios que accedan a los contenidos. La clave está en que cuando hablamos de usuarios no sólo estamos hablando de personas: cualquiera que se dé el trabajo de revisar las estadísticas del servidor de cuando en cuando notará que gran parte de las visitas se deben a robots, web crawlers y otras alimañas. Una de ellas, la más importante en muchos aspectos, es Googlebot. Googlebot es el bot de Google, y es quien realiza gran parte del trabajo casi silenciosamente. Es él quien clasifica cada sitio, trata derelacionar los contenidos, y de asignar puntajes. Lo que nosotros usualmente vemos al buscar en Google es la interfaz del buscador, pero los resultados aparecen gracias al trabajo realizado laboriosamente por Googlebot.

La relación es simple: Googlebot tiene varias discapacidades.

• es completamente ciego
• es totalmente sordo

Además de lo anterior, no es un browser tradicional con soporte de JavaScript y no es capar de acceder a los contenidos de muchos plugins comunes.

Googlebot es ciego porque no es capaz de reconocer o entender las imágenes, de hecho tampoco ve una página del modo que nosotros lo hacemos, usando un browser u otro tipo de dispositivo: solicita una página al servidor como cualquier browser mediante HTTP, la analiza y procesa, pero nunca la dibuja en un monitor. Por qué habría de hacerlo, no es necesario. Sólo necesita el texto, al igual que Lynx y Jaws. Cabe señalar que la búsqueda de imágenes de Google utiliza la información del contexto de una imagen, su nombre de archivo, ALT y descripciones extensas cuando existen para clasificarlas e indexarlas. Google no es capaz dever una imagen.

Es sordo, porque no es capaz de comprender archivos de audio. No tiene idea de los contenidos de un archivo MP3 u otros formatos. Cualquier contenido que se encuentre en este modo, sea un discurso, una conversación o música no será analizado. Esto también se extiende a cualquier formato multimedia que contenga audio.

Por si fuera poco, Google no reconoce JavaScript. En rigor, lo que no hace es ejecutarlo. Googlebot podrá analizar código JavaScript como texto, pero no lo ejecutará como un browser tradicional. Por ejemplo, si se utilizan técnicas como:

document.write(’<h1>Título principal</h1>’);

Googlebot jamás se enterará de que el texto correspondía al título principal, puesto que no lo ejecutará. Es capaz de leerlo, pero sólo como parte del texto y no está muy claro de que esto sea así si está dentro de un archivo JavaScript externo. Esto es sólo un ejemplo, lo mismo ocurrirá con todos los contenidos dinámicos generados vía JavaScript e incluso vía CSS.

Es cierto que muchas de las técnicas que utiliza Google son secretas y se conservan en ese estado por razones de marketing y para disminuir la posibilidad de explotación ilegítima. No obstante existen presunciones fundadas sobre varias de las reglas que aplica Google para indexar y asignar puntajes a las páginas que analiza. No nos sorprenderemos, entonces, de descubrir que muchas de las técnicas que benefician a un usuario con algún tipo de discapacidad también ayudan a Google a entender mejor un sitio y a asignarle un mejor puntaje, por lo tanto, aparecer mejor posicionado en los resultados de búsqueda:

• Títulos bien redactados
• Palabras clave utilizadas en títulos
• Contenidos estructurados semánticamente
• Uso de descripciones alternativas para imágenes y otros medios
• URIs legibles y significativas

Conclusión:

• la accesibilidad beneficia a usuarios que por condiciones propias se ven limitados para usar sitios que no se construyan técnicas apropiadas;
• beneficia a usuarios que por situaciones o circunstancias específicas navegan en condiciones no tradicionales, como el uso de dispositivos móviles (PDAs, WAP, WebTV, etc.), conexiones de baja velocidad, computadores de baja capacidad;
• facilita la labor de los robots indexadores como Googlebot, lo que te beneficia porque genera mejores puntajes y posicionamiento en los resultados de búsqueda, por lo tanto, más visitas.

Esta relación, independientemente de cualquier argumento humanista que se pueda hacer al respecto, es desde ya un muy buen argumento de ventas de la accesibilidad

Para algunos esto puede ser obvio, pero para quienes recién se introducen en Arquitectura de Información es una fuente de confusión constante: la estructura de contenidos no necesariamente es equivalente a la estructura de navegación de un sitio.

La estructura de contenidos o taxonomía de un sitio no tiene por qué, obligatoriamente verse fielmente reflejada en la estructura de navegación principal de un stio. De hecho, un sitio puede presentar múltiples formas de navegación, desde el clásico menú principal, pasando por menús contextuales, vínculos en el contenido, etc., hasta sistemas de búsqueda.

El objetivo de la taxonomía es organizar los contenidos de manera lógica utilizando diversos criterios. Esto permite ordenar los contenidos en un sistema estructurado, relacionado y eventualmente jerarquizado. Pero los modos que dispondremos para utilizar estos contenidos siguen patrones diferentes.

En el caso específico del patrón de menú de navegación principal se presentan secciones o categorías de contenido que se desea destacar, pero que pueden no corresponder exactamente a la misma estructura de clasificación de la taxonomía del sitio.

El diagrama anterior nos presenta una estructura de contenidos simple con subcategorías. No todas las categorías de primer nivel formarán parte del menú principal de navegación, sólo aquéllas que sea necesario destacar.

El esquema de navegación que presentamos arriba pretende ilustrar la situación que estoy tratando de exponer: la estructura de navegación utilizará algunas de las categorías de la taxonomía, pero no necesariamente todas y tampoco será necesario que pertenezcan al mismo nivel.

El criterio mediante el que seleccionaremos los contenidos de la navegación estará relacionado con el modo en que pretendemos guiar el recorrido de los contenidos, aquellos aspectos que necesitamos destacar particularmente. La taxonomía, en tanto, utilizará criterios de organización lógica.

La taxonomía, en cambio, tendrá un rol relevante en el uso de otros mecanismos, como los motores de búsqueda y sistemas facetados de navegación, como catálogos de productos y directorios entre otros. Uno de los lugares en que más probablemente observemos la evidencia de la taxonomía de un sitio será en el uso de los menús de rastros, que representarán la jerarquía de los contenidos en forma descendente hasta la página actual.

Problema

Se necesita un mecanismo que permita al usuario navegar globalmente los contenidos de un sitio de un modo consistente y visible desde todas la páginas.

Por qué

El sitio posee un número de categorías de contenidos que se desea destacar y exponer al usuario para facilitar la navegación directa y la localización de la información deseada.

Cuándo

Cuando la estructura de contenidos de un sitio presenta múltiples secciones o categorías que deben ser localizadas fácilmente por el usuario, permitiendo de este modo un acceso directo a las páginas interiores del sitio.

Solución

Utilizar un listado de las secciones más destacadas a las que se desea dar acceso directo. Este listado de categorías o secciones suele presentarse como una barra horizontal en el sector superior de la página, con nombres suficientemente breves, aunque clarificadores y en un número normalmente no superior a 7 ítemes. Aunque el modo más frecuente de disposición es horizontal, también es común que se le utilice verticalmente.

Es común, aunque no particularmente recomendado por factores de usabilidad y accesibilidad, el utilizar sistemas jerarquizados que permiten desplegar subniveles mediante tecnologías de scripting.

Este patrón de navegación está compuesto principalmente por vínculos textuales, sea en forma de texto real o mediante imágenes que representen textos para obtener efectos gráficos específicos.

Ejemplos

Observaciones

Existen variaciones de este patrón que trataremos separadamente, como aquéllos que utilizan una combinación de tabs o pestañas o sistemas jerárquicos complementarios para permitir el acceso a subniveles.

Referencias

• http://www.welie.com/patterns/showPattern.php?patternID=main-navigation

Los logos y marcas que aparecen en esta página son propiedad de sus respectivos dueños. Las capturas de pantalla de sitios de terceros se presentan para efectos ilustrativos y no representan vinculación, aprobación ni otro tipo de relación.

Problema

Se necesita un sistema que permita orientar al usuario sobre la ubicación de la página que está leyendo en un sitio web, respecto a la estructura de contenidos global. Esta información debe estar disponible en el contexto de la propia página, por lo que el mapa del sitio no soluciona el problema.

Por qué

Normalmente la estructura de navegación de un sitio no otorga información suficiente que permita ubicar precisamente una página dentro del contexto global de los contenidos de un sitio. Cuando el sitio tiene una estructura de contenidos compuesta de múltiples niveles resulta difícil reconocer la ubicación de las páginas interiores respecto a la arquitectura de información del sitio. Este problema se hace más evidente cuando un usuario ingresa al sitio desde páginas interiores, por ejemplo mediante un vínculo en una página de resultados en un buscador, pero es igualmente relevante para los usuarios que navegan el sitio de modo convencional.

Cuándo

Cuando la estructura de contenidos de un sitio presenta una profundidad mayor a dos niveles y resulta necesario entregar un refuerzo sobre la ubicación de la página respecto a la estructura de contenidos del sitio.

Solución

Proveer un sistema jerarquizado de vínculos a las secciones o páginas padre desde la página actual hasta la portada. El sistema debe:

• Representar claramente la jerarquía descendente hasta la página
• Utilizar un elemento separador que refuerce esa jerarquía entre cada vínculo
• Estar orientado de izquierda a derecha y en la parte superior de la página, normalmente bajo el encabezado de la página y sobre los contenidos.

Ocasionalmente se observa el uso de textos como Usted está en: para reforzar la funcionalidad ubicación de este elemento.

Ejemplos

Observaciones

Es preciso hacer notar que el nombre en inglés, breadcrumbs así como la traducción de menú de rastros resulta confuso, dado que el objetivo de este patrón no es informar sobre la ruta de navegación que ha seguido el usuario para llegar a la página en cuestión, sino que informar sobre la ubicación de la página en el contexto de la estructura de contenidos del sitio.

Esto último incluso nos lleva un poco más lejos: en un sitio con una cantidad importante de contenidos, la arquitectura de información no necesariamente reflejará la estructura de navegación. La clasificación de los contenidos puede generar una estructura que no se refleje fielmente en el menú de navegación, por cuanto éste estará compuesto por categorías de navegación que idealmente contendrá accesos directo a zonas de interés específico en el sitio. La decisión entonces es ¿usar categorías de navegación o la clasificación de los contenidos del sitio? Creo que se debería utilizar la clasificación de contenidos del sitio, así como en el mapa del sitio.

Cabe también citar el ejemplo que presenta Jesús Carreras del uso para representar navegación en Tipos de Breadcrumbs, o cómo orientar al usuario, aunque personalmente no estoy consciente de haber encontrado otros ejemplos similares.

Referencias

• http://www.welie.com/patterns/showPattern.php?patternID=crumbs
• http://www.visiblearea.com/cgi-bin/twiki/view/Patterns/Homeward_path
• Tipos de Breadcrumbs, o cómo orientar al usuario

Los logos y marcas que aparecen en esta página son propiedad de sus respectivos dueños. Las capturas de pantalla de sitios de terceros se presentan para efectos ilustrativos y no representan vinculación, aprobación ni otro tipo de relación.

En un Alertbox reciente, Nielsen evidencia la importancia de los estándares en el diseño web:

Users expect 77% of the simpler Web design elements to behave in a certain way. Unfortunately, confusion reigns for many higher-level design issues.

Los estándares se refieren a elementos o funcionalidades comunes utilizados frecuentemente y que por la exposición, uso y finalmente acostumbramiento, los usuarios terminan identificando y utilizando de modo espontáneo, asumiendo naturalmente sus características. Por el contrario, cuando un usuario espera que algo opere de un modo específico y esto no ocurre, se genera confusión y pérdida de confianza.

Estos estándares y convenciones constituyen patrones de diseño, que contribuyen a la generación de modelos mentales respecto a elementos específicos o incluso a tipos de sitios en general. La importancia de los patrones radica en la automatización del uso de las interfaces e interacciones, lo que simplica la realización de tareas y permite que el usuario se concentre en los aspectos más importantes, más que en resolver cómo resolver los problemas más básicos, como lograr completar correctamente una tarea específica.

Como indica Nielsen en el artículo antes citado, el uso de estándares o patrones garantiza que los usuarios se sentirán en control, sabrán qué esperar de una tarea particular, se sentirán cómodos y utilizarán de un modo más apropiado un sitio web.

La lógica detrás de un patrón de interacción está dada por la construcción de modelos mentales, que nos permiten identificar y reconocer fácilmente aquellos elementos que hemos aprendido y asociado a través de la experiencia. En la medida que este proceso se concreta, se eliminan una serie de factores innecesarios, asociados a procesos congnitivos que se traducen en que nos enfrentamos a esquemas similares, conocidos, de resolver un problema. Este proceso nos permite pasar de un mecanismo que podría tomas algunos segundos, a un reconocimiento que ocurre en fracciones de segundos. Esto no es irrelevente si pensamos en que estos segundos de diferencia, y la calidad de la experiencia que ellos constituyen, tienen una relación directa con el éxito de una venta en linea, el envío correcto de un mensaje de contacto para un potencial negocio, la venta de una suscripción para un medio de noticias, etc.

Los patrones en el diseño web son precisamente uno de los aspectos que me interesa cubrir y explorar en EFH. Si el tiempo me acompaña, espero pronto comenzar a publicar temas relacionados con estos patrones. Mientran eso ocurre, los dejo con un conjunto interesante de sitios dedicados a la exploración de patrones en el web:

• Web Design patterns, colección de patrones de Martijn van Welie.
• the Diemen Repository of Interaction Design Patterns, Wiki sobre patrones de interacción.
• UI Patterns and Techniques, colección de patrones de Jenifer Tidwell.
• Widgetopia, proyecto de Christina Wodtke, que aunque no está orientado específicamente a patrones, ofrece interesantes muestras de uso de elementos de interfaz.