Archivo de Categoría «General»

Folksonomía Aplicada

General

Como les comenté hace poco, he estado investigando sobre la aplicabilidad del concepto de folksonomía o los sistemas de clasificación colectiva a la vida real. Particularmente, estoy evaluando la factibilidad de utilizarlo en una intranet.

Una intranet normalmente debería tener un sistema de clasificación top-down o impuesto como parte del diseño de los contenidos, lo que permite controlar la estructura y navegación de la información. Esto es útil en la medida que refleje realistamente el universo de los contenidos y del conocimiento de los usuarios. Normalmente una intranet contendrá una cantidad de información significativa, muchos documentos y herramientas en línea. Sin embargo, la clasificación propia de la intranet puede no ser suficientemente significativa para todos los usuarios y esto podría dificultar su capacidad para encontrar la información. En el contexto de una intranet es fácil hacer cálculos del valor que involucra el tiempo perdido por los funcionarios por causa de un mal diseño, por lo tanto también es fácil visualizar los beneficios de un sistema que afecte positivamente el desempeño.

Vale señalar que estoy pensando en una intranet con una taxonomía adecuada, tópica o temática, no una basada principalemente en la estructura organizacional, un error que podemos observar frecuentemente en este tipo de sistemas de información.

Para concretar mi divagación, imaginemos la siguiente situación: la intranet tiene una o más taxonomías adecuadas que permiten organizar la información y darle estructura al sitio. Como complemento a lo anterior, se provee un mecanismo mediante el que los propios usuarios podrán aplicar términos de clasificación a cada contenido o documento, de modo que se conforma paralelamente un sistema de clasificacación colectivo informal, no oficial, que contribuye a mejorar los resultados de búsqueda, y que adicionalmente permite sintonizar las taxonomías formales de la intranet.

Si observamos que un tipo de contenido, por ejemplo el Manual de Procedimientos, que en la taxonomía temática está clasificado en Reglamentos Internos, es clasificado frecuentemente por los usuarios con los términos manual, procedimientos, interno ypolíticas, podremos notar que la taxonomía formal no está suficientemente afinada. El feedback de los usuarios nos indica que deberíamos tomar algunas medidas:

  • Si es apropiado, incorporar una nueva categoría, considerando la clasificación de los usuarios
  • Si existe otra categoría que contenga los Manuales, podríamos agregar una faceta o clasificar el contenido además en la categoría Manuales
  • Complementar el vocabulario controlado, estableciendo relaciones especiales como por ejemplo, términos relacionados, sinónimos, etc.

El problema con esto, es que no ocurre automáticamente, alguien debe moderar y administrar la clasificación de los usuarios. En un entorno restringido como lo es una intanet (ok, no la intranet de IBM, con 350.000 usuarios…), esto no debería ser un problema muy grande si consideramos cómo se puede enriquecer la estructura de información y la propia interacción dentro del sitio. En una intranet mediana o pequeña, el uso de un sistema de clasificación colectivo podría ser favorable.

La experiencia actual en el uso de folksonomías (flickr, del.icio.us, technorati) lleva a pensar que si bien es posible que los vocabularios de los sistemas de clasificación colectivos crezcan bastante, también es cierto que tienden a automoderarse: los usuarios tienden progresivamente a utilizar los términos usados por otros para definir un contenido, en tanto les haga sentido. Del mismo modo, se potencian los términos más frecuentemente utilizados, lo que a la vez funciona como termómetro de los contenidos más consultados. De esa forma, se limita el crecimiento indiscriminado del vocabulario.

Algunas consideraciones:

  • Las palabras clave o términos de clasificación se denominan tags;
  • La mayoría de las implementaciones actuales de clasificación colectiva utilizan tags o términos simples de una palabra, por lo que no es posible clasificar un contenido como manual de procedimientos, queda convertido en manualdeprocedimientos, esto es una limitación innecesaria.

El objetivo de todo esto, finalmente, es explorar mecanismos que permitan encontrar información de un modo más eficiente. En un sistema de publicación con miles de páginas y documentos, comúnmente será más fácil utilizar el buscador que un sistema de navegación tradicional.

En la medida que tenga conclusiones más significativas se las contaré, de momento, continuaré explorando, de paso, si alguien tienen experiencias relacionadas con esto, sería interesante conocerlas.

Microformatos, Tags, Folksonomy y Keywords

General

Por favor permítanme pensar en voz alta por un momento, esto es algo que no termino de elaborar, pero que va tomando cuerpo de a poco. Sí, microformatos, tags, folksonomíakeywords son un montón de términos, algunos suenan a buzzwords, pero hay algo tras todo esto que puede resultar útil. Desde hace un tiempo les vengo dedicando cierto espacio de procesamiento en background en mi cabeza, no demasiado conscientemente para que fluyan, y definitivamente las palabras de Tantek gatillan cosas bastante más concretas:

One of the principles of microformats is to be presentable and parsable. This means we prefer visible data to invisible metadata. This is one of the lessons we learned from the meta keywords debacle.

http://tantek.com/log/2005/06.html#d03t2359

Particularmente esto me parece muy relevante: preferimos datos visibles antes quemetadatos invisibles. Esto es uno de los aspectos que sustentan las folksonomías, el tener un sistema de clasificación visible, expuesto, además de lo obvio, abierto y colectivo. Creo que volveré sobre esto en unos días.

Card Sorting

General

Card Sorting es una técnica de arquitectura de información para la clasificación de contenidos que se basa en el ordenamiento de tarjetas de papel que representan categorías o contenidos específicos. En la práctica esto puede funcionar de dos modos, con propósitos muy diferentes:

  • Como herramienta de trabajo grupal
  • Como herramienta de testeo con usuarios

En el primer caso el ejercicio se realiza en grupo y se discute la estructura que se va desarrollando para lograr un criterio común de equipo. En el segundo caso, se le pide a usuarios reales que realicen la clasificación, esto permitirá considerar diferentes visiones y podrá entregar información valiosa sobre la apreciación de los contenidos y los intereses de estos.

En la serie de fotografías a continuación, se ilustra el proceso de card sorting comoherramienta de trabajo en equipo. Esta sesión es real y se desarrolló en el contexto de la planificación de un sitio que estamos rediseñando con un grupo alumnos, partimos del inventario de contenidos del estado actual del sitio. En total participamos siete personas, aunque se puede hacer con un número mucho menor que éste. Veamos el proceso:

card-sorting-01

Foto 1: así comenzó todo. Dispusimos las tarjetas (en este caso notas adhesivas) aleatoriamiente en una pizarra.

card-sorting-02

Foto 2: luego comenzamos a organizar la información. En este caso dos integrantes del equipo inician el proceso.

card-sorting-03

Foto 3: se le pidió a un miembro del equipo que comenzara a organizar según su criterio; posteriormente entre todos se discutieron alternativas y visiones diferentes.

card-sorting-04

Foto 4: en ocasiones faltan contenidos o categorías y se crean nuevas tarjetas.

card-sorting-05

Foto 5: finalmente los contenidos comienzan a tomar cuerpo y se llega a una estructura optimizada en la que todos coincidimos.

Si te interesa profundizar en esta técnica, puedes encontrar artículos muy ilustrativos en Boxes and Arrows.

Did you say Spanish?

General

Creo que uno de los aspectos más importantes para la accesibilidad de los contenidos en el web así como para la indexación y clasificación de los contenidos en general es la identificación del idioma. Me refiero a algo tan simple como el declarar en qué idioma se encuentran los contenidos de una página. Sin embargo esto es algo que ocurre con muy poca frecuencia.

Cualquiera que haya utilizado alguna aplicación asistiva como Jaws para evaluar accesibilidad o incluso como herramienta de navegación sabe que no es fácil entender un documento en castellano leído con un sintetizador configurado para leer en inglés o a la inversa. Del mismo modo, los indexadores como Googlebot deben realizar esfuerzos especiales mediante algoritmos complejos para identificar el idioma principal de un documento para luego analizar sus contenidos. Es evidente que para poder analizar, indexar y clasificar los contenidos de una página primero debemos conocer el idioma.

Imagino que el origen de este descuido tiene raíces en el idioma original de las tecnología web: el inglés. Desde la perspectiva de los usuarios (y desarrolladores) angloparlantes, el resto del mundo habla un idioma extranjero, por lo tanto ellos normalmente no sienten la necesidad de preocuparse de identificar el idioma dominante del web en cada uno de sus documentos. Evidentemente esto es un error. Y es más incorrecto aún cuando nosotros, desarrolladores hispanoparlantes (y en general los hablantes de cualquier otro idioma), omitimos esta declaración. El hecho es que el idioma por defecto del web es el inglés (aunque esto no es técnicamente correcto, como veremos más adelante) y nosotros estamos obligados a identificarnos para asegurarnos de que nuestros contenidos sean correctamente comprendidos. No lo puedo asegurar por el hermetismo de Google respecto a sus algoritmos, pero imagino que será más cortés y benevolente con nosotros si le ahorramos un considerable tiempo de procesamiento y análisis lingüístico declarando explícitamente el idioma en que se encuentra nuestro contenido. Para salir de las dudas, esta misma pregunta la he enviado a un grupo de discusión sobre buscadores y al mismo Google. Nada se pierde con intentar, no?

De todos modos, los beneficios de marcar correctamente el idioma van más allá de los buscadores. Cualquier proceso automático sobre el contenido podría utilizar este antecedente, además de los ya mencionados beneficios para la accesibilidad.

Entonces, ¿cómo deberíamos identificar el idioma? En HTML 4.01 se especifica lo siguiente:

This attribute specifies the base language of an element’s attribute values and text content. The default value of this attribute is unknown.

[…] The lang attribute’s value is a language code that identifies a natural language spoken, written, or otherwise used for the communication of information among people. Computer languages are explicitly excluded from language codes.

En la práctica, esto nos indica que: el atributo lang indica el lenguaje del elemento donde se declara y de sus atributos; el valor por defecto es desconocido; es un código que identifica un lenguaje natural. Veamos esto en detalle.

Alcance del Atributo lang

El atributo lang determina el idioma del elemento al que pertenece, pero también el idioma de sus demás atributos. Por ejemplo, en el siguiente ejemplo tanto el contenido del atributo title, así como el propio contenido World Wide Web Consortium están definidos como texto en inglés. Recordemos que en HTML el orden de los atributos no tiene ningún significado o valor especial.

<a href=”http://www.w3c.org/” title=”W3C web site” lang=”en”>World Wide Web Consortium</a>

Valor por Defecto

Cuando este atributo no se indica, se debe asumir que se desconoce el idioma, a menos que el elemento sea hijo de otro elemento en un nivel superior que sí declare idioma. En el siguiente ejemplo, el texto en p está definido como español, pero dentro de él está el texto World Wide Web Consortium en el elemento em que está identificado como inglés.

<p lang=”es”>El <em lang=”en”>World Wide Web Consortium</em> es un consorcio internacional que define estándares para el web.</p>

Códigos de Idioma

Los códigos de idioma están definidos en RFC 1766 y en ISO 639. La siguiente tabla presenta algunos códigos:

Nombre del Idioma Código
Francés fr
Alemán de
Italiano it
Holandés nl
Griego el
Español es
Portugués pt
Árabe ar
Hebreo he
Ruso ru
Chino zh
Japonés ja
Hindi hi
Catalán ca
Checo cs
Quechua qu

XHTML

En XHTML el procedimiento es muy similar:

Use both the lang and xml:lang attributes when specifying the language of an element. The value of the xml:lang attribute takes precedence.

La diferencia es que además de lang se debe usar el atributo xml:lang. Si ambos están decarados, se utilizará el valor de éste último.

Criterios de Uso

Cuándo es necesario definir el idioma:

  • Al principio de cada documento HTML como atributo del elemento head: <HTML xmlns="http://www.w3.org/1999/xhtml” lang="es">. Esta declaración rige para todo el documento y no es necesario volver a identificar el idioma a menos que ocurra un cabio dentro del contenido.
  • Cuando ocurre un cambio de idioma dentro del contenido. Por ejemplo, si el documento está declarado como español en head, pero dentro del texto hay una frase en inglés, se debería identificar usando cualquier elemento que sea apropiado, por ejemplo <em lang="en">

No está de más recordar que podemos utilizar lang en prácticamente cualquier elemento de HTML.

Conclusión

Hemos visto que técnicamente es simple marcar el contenido con el idioma correcto. Incluso es posible implementar interfaces gráficas para editores de contenido WYSIWYG de modo de no intervenir el código. Los beneficios pueden no ser evidentes, pero ocurren: se mejora la acesibilidad, el contenido queda enriquecido estructuralmente al identificarse apropiadamente fragmentos de diversos contenidos.

Mayor información sobre internacionalización e idiomas en el artículo Language tags in HTML and XML del W3C.

Accesibilidad y Personas

General

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.

Notas

  1. Una definición de personas se puede encontrar en el Information Architect’s Wiki, el que a su vez contiene varios vínculos de interés.
  2. Algunas definiciones de UCD se encuentran en Web Style Guide y Usability & User Experience Community, un enfoque más técnico lo da IBM en su sección Ease of Use.
  3. Mark Pilgrim utiliza personas en su libro Dive Into Accessibility en un muy buen ejemplo de la utilidad de esta herramienta en accesibilidad.
  4. Capchas o captchas son una técnica para impedir (o al menos dificultar) el acceso a scripts o programas automatizados. Se trata principalmente de mostrar una imagen distorsionada que un humano reconocería fácilmente pero que presenta un gran desafío para un programa. Más información en Wikipedia y en el Palo Alto Research Center.

Derechos Humanos

General

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.

DSCN7967

La imagen muestra la llegada de la caravana que transportaba a Manuel Contreras a la cárcel. Un número importante de personas esperaba su llegada para celebrar su arresto y condena.

DSCN7973

Otro canal cubre la noticia, la caravana que transportaba a Manuel Contreras llegando a la cárcel.

DSCN7976

Ya dentro de la cárcel Contreras es bajado de la camioneta.

DSCN7977

Contreras es conducido hacia el interior de la cárcel.

DSCN7991

Éste fue uno de los hombre más temidos durante los primeros años de la dictadura militar en Chile, entre 1973 y 1976.

Home Page e Internacionalización

General

homepage-icons

Ejemplos diversos de aplicación del ícono home page.

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.

Estrategias de Organización de CSS

General

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, h1h6, 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.

Cambios en Navegación de Amazon

General

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

amazon-nav-01

El antiguo sistema de navegación por pestañas de Amazon.com se había sobrepoblado haciéndolo recargado y menos eficiente que al principio [d].

amazon-nav-02

Nuevo sistema de navegación global en Amazon.com que reemplaza al tradicional sistema de pestañas [d].

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.

amazon-cats-01

El nuevo rediseño de Amazon.com presenta un sistema de categorías que permite navegar todo el sitio [d].

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.

Descripción de Imágenes

  1. Descripción de imagen 1: La imagen presenta un menú de navegación de pestañas formado por dos niveles, el superior muestra las categorías de navegacion principal y el inferior las opciones secundarias. El primer nivel contiene las opciones Welcome, Your Store, Books, Apparel and Accesories, Electronics, Toys and Games, DVD, Baby. La selección actual es Welcome, que presenta las opciones International, New Releases, Top Sellers, Sell Your Stuff.Las pestañas son una forma habitual de presentar muchas opciones alternadamente.
  2. Descripción de imagen 2: La imagen muestra el nuevo sistema de navegación de Amazon, que conserva las pestañas pero esta vez con sólo dos ítemes: Welcome y All Categories. La pestaña seleccionada esWelcome y las opciones al igual que en la versión anterior son International, New Releases, Top Sellers, Sell Your Stuff.
  3. Descripción de imagen 3: La imagen muestra el listado de categorías de Amazon.com dispuesto en cuatro columnas y dividido en dos secciones horizontalmente. La parte superior contiene productos y la sección inferior muestra servicios e información.

Google y Accesibilidad

General

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.

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