Errores Comunes con Ajax

General

Cuando observo el frenesí que causa Ajax, el chico nuevo del barrio, no puedo dejar de recordar la primera época de Flash, aquélla en que la que los efectos, animaciones e interfaces de usuario lamentables se hacían porque se podía.

Es cierto, el web es un medio restrictivo en el que tienes que asumir que muchas cosas no van. Con esto no me refiero al conformismo pasivo, sino a entender la naturaleza del medio, asumir que sobre ciertas cosas no tenemos control y que tenemos que respetar la libertad del usuario. La libertad de controlar sus ventanas, de elegir el tamaño del texto, de poderusar los controles a los que está habituado.

Dentro de las restricciones del medio hay un amplio rango de movilidad para poder desarrollar soluciones inteligentes, atractivas e interesantes. Por eso, cuando llegamos a tener nuevas herramientas a nuestro alcance, son bienvenidas. Más aún cuando se trata detecnologías no propietarias, relativamente estándar, disponibles para todos y fácilmente desarrollables con las aplicaciones a las que estás habituado.

Este es el caso de Ajax. Es una suma de tecnologías basadas en estándares público, a excepción del objeto , que si bien no es un estándar público, ha sido asumido como tal, siendo soportado por la mayoría de los navegadores modernos.

Pero con la excitación de subirse al bote, se cometen algunos de los mismos errores que llevaron al clásico Flash 99% Malo. Por esto la lista de los errores más frecuentes cometidos con Ajax, de Alex Bosworth, es muy oportuna. A continuación, algunos destacados:

  • Inhabilitar el botón Atrás
  • No representar el estado de las páginas ni contar con URLs reales con las que representar un estado de una página
  • Elementos de interfaz gráfica nuevos e innecesarios

La Importancia de un Nombre

General

Desde hace pocos meses la ola de aplicaciones web y sitios que utilizan Ajax crece sorprendentemente. Con aplicaciones como Google Suggest, Maps, Gmail, hasta Basecamp y una cantidad creciente de usos localizados para resolver situaciones específicas, el uso deAjax se ha extendido rápidamente.

Sin embargo la prensa tecnológica y, admitámoslo, nosotros los bloggers, le hemos prestado atención desde principios de este año. Probablemente sea porque es una tecnología muy reciente. Tal vez se trate de que Ajax en sí misma no sea una tecnología auspiciada y promovida por una compañía en particular, no es un producto propietario, sino más bien una suma de tecnologías complementarias. O tal vez por una cuestión de compatibilidad que sólo los navegadores más recientes han podido resolver.

En realidad ninguno de los supuestos anteriores es correcto. Ajax es en concreto una suma de tecnologías presentes desde hace bastante tiempo de modo independiente, y usadas en conjunto desde hace ya algunos años. De hecho lo que algunos llamaban DHTML hace años, contenía mucho de lo que actualmente Ajax usa. DHTML era la combinación de HTML con CSS y JavaScript para generar contenido y efectos dinámicos. Pero carecía de la posibilidad real de comunicarse con el servidor y obtener contenidos remotos sin recargar la página. Ajax, por su parte, utiliza esos ingredientes, HTML, CSS y JavaScript, junto con DOM, XML y el elemento que marca la diferencia: el objeto XMLHttpRequest. Este objeto permite realizar conexiones a un servidor mediante HTTP usando XML, sin necesidad de recargar una página. Pero no es un elemento nuevo en el paisaje. Inicialmente fue desarrollado por Microsoft y está presente desde IE5. En otros navegadores se ha implementado de modo más reciente: en Mozilla desde la versión 1.0 y en Safari desde la 1.2. Eso significa que está disponible en los navegadores más utilizados desde hace años.

Los demás ingredientes, CSS y DOM tienen un soporte aceptable en IE6 y en Mozilla por definición son parte de su propio ser (mucha de su propia interfaz está construída usando unlenguaje basado en XML, CSS y DOM llamado XUL).

¿Entonces, porqué sólo ahora estamos conociendo masivamente de esta suma de tecnologías? Creo que hay dos razones para esto:

  • La primera tiene que ver con el respaldo que significa que una compañía con un peso muy importante, como es Google, decida utilizarlo como elemento clave de su estrategia de desarrollo de aplicaciones web.

    Gmail, Google Suggest y Google Maps basan su interfaz en el uso de estas tecnologías.

  • En segundo lugar hay un factor clave, imaginemos la siguiente situación: estoy construyendo una aplicación web basada en HTML+XML+XMLHttpRequest+CSS+JavaScript+DOM que seguro será un éxito… El 18 de febrero de este año Jesse James Garrett publicó un artículo en el sitio de Adaptive Path en el que acuñó el término Ajax como abreviación de Asynchronous JavaScript + XML.

Mi punto tras todo esto es notar la importancia de un nombre, uno apropiado, que facilite las cosas y que permita hablar de un modo menos técnico sobre un tema técnico. El éxito de Ajax ha sido en parte por contar con un nombre, aunque evidentemente no exclusivamente por eso. Un ejemplo de la exposición que esto le ha significado lo ilustran los siguientes artículos:

Esto sin considerar el tratamiento del tema en blogs, Google muestra 725.000 resultados, de los cuales la mayoría son posts en blogs.

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.