Archivo de Categoría «General»

Un problema frecuente en las aplicaciones web abiertas al público es el de los scripts automatizados que tratan de explotar algunas de sus caraterísticas para propósitos diversos, normalmente ilegítimos. Desde los robots que ingresan comentarios spam a los blogs por miles, hasta aquéllos que intentan abusar de los servicios de correo como MSN, Yahoo! y más recientemente Gmail, el factor común es que se trata de scripts o programas relativamente pequeños que se diseñan para abusar específicamente de ciertos sistemas.

Los spammers de blogs apuntan en particular a los comentarios, normalmente abiertos al público, para dejar vínculos que pretenden sacar partido de los buscadores que valoran positivamente la cantidad de referencias a un sitio. Los wikis, con su esencial característica de edición colectiva, son vulnerables también a estos problemas.

Una forma específica de enfrentar el problema, es utilizar un mecanismo que permita garantizar que quien realiza una acción es un humano y no un robot programado. La técnica más común es el uso de imágenes distorsionadas que para los humanos resultan relativamente simples de leer, pero que para un programa es muy difícil procesar. Estas imágenes son conocidas como captchas.

Captchas

Partamos por la definición del nombre: éste es una abreviación de Completely Automated Public Turing Tests to Tell Computers and Humans Apart, algo así como Prueba Turing Pública Completamente Automatizada para Diferenciar Humanos y Máquinas y fue acuñada por un equipo de IBM en el año 2000.

Esta técnica, desarrollada originalmente por AltaVista en 1997, busca distinguir claramente a un humano de un proceso programático, mediante el uso de imágenes distorsionadas de un modo que haga imposible el que sean leídas por algo que no sea un humano. Quien esté familiarizado con los escáneres de imágenes, probablemente conocerá también la tecnologíaOCR, Optical Character Recognition, que permite escanear páginas de texto como imágenes y transformarlas a texto. La tecnología OCR permite reconocer caracteres desde imágenes mediante análisis de inteligencia artificial, y demuestra que si bien se puede programar un sitema para que reconozca imágenes, deben existir ciertas condiciones para que el reconocimiento de los caracteres sea más fácil. Por lo mismo, los captchas distorsionan la imagen de un modo que hace imposible que que las tecnologías OCR actuales identifiquen su significado. Algunas de las técnicas para ocultar el texto en la imagen son el uso de tipografías poco usuales, distorsionadas, irregulares, junto con diferentes colores y elementos de ruido visual. Vale hacer notar que con un esfuerzo considerable es posible programar sisteas que sean capaces de leer captchas, pero normalmente el costo de esto es muy alto.

La técnica completa de los captchas consiste en presentar una imagen al usuario y solicitarle que ingrese el texto que reconoce en ella en un campo, normalmente una mezcla de caracteres alfanuméricos, y luego se comparan ambos para verificar si coinciden. Un script automátizado no pasará la prueba, en tanto un humano sí. ¿Sí?

Accesibilidad y Captcha

La base de la técnica de captcha se basa en que los humanos podemos leer. Pues bien, la mayoría lo hace, pero no todos podemos leer. Sí, me refiero a los ciegos. Esto establece un problema de accesibilidad concreto, que de no ser corregido, significa discriminación. La buena noticia, es que los captchas no sólo se pueden realizar con imágenes, es posible también utilizar audio para entregar información que sólo será diferenciable para humanos. La técnica es similar: se presenta la grabación de una serie aleatoria de letras y números en con ruido auditivo y cierta distorsión. Lo ideal es tener ambos sistemas, captcha de imagen y de audio, para permitir que todos los usuarios puedan ciertamente pasar la prueba de discriminación de humanos y máquinas.

En el Mundo Real

En muchos casos he encontrado captchas de imagen en sitios públicos como Yahoo! o incluso más recientemente en Gmail. Pero en todos los casos se omitía el problema de accesibilidad. En Gmail parecen tener planes al respecto, porque junto a cada imagen captcha se encuentra un gráfico pequeño con el símbolo de discapacidad, aunque la solución ofrecida es actualmente bastante pobre: abre una ventana nueva usando JavaScript, la ventana tiene el mismo captcha con texto en el atributo ALT que dice algo como usted no puede ver la imagen porque las tiene desactivadas en el navegado. Cómico, si lo quieres tomar con humor.

Sin embargo, hace uns días me llevé una sorpresa, que fue la que me motivó a escribir este ya extenso post: en MSN utilizan captchas de imagen y audio. Las siguientes imágenes muestran parte del proceso de creación de nueva cuenta y al final hay un ejemplo del captcha de audio.

El captcha de audio presentado por MSN es una lectura distorsionada de una serie de números que se oye así (WAV, 64Kb.). Vale hacer notar también que la grabación del captcha se presenta en castellano, como corresponde a un sitio mulilingüe.

Más Información

Si el tema te interesa, te recomiendo algunos lugares para buscar más información sobrecaptchas:

• Proyecto Captcha del Palo Alto Research Center
• Información en Wikipedia
• Proyecto Captcha, Carnegie Mellon University
• Una nota del W3C sobre los problemas de accesibilidad de los captchas
• Wikipedia hace notar la vigencia de una patente en EE.UU. que cubre el concepto

Desde hace tiempo tenía la intención de opinar respecto a los blogs como medio, sobre la comunidad y las expectativas que muchos se crean de esto. El impulso final me lo da la polémica sobre algunas supuestas irregularidades o faltas a la ética del senador Flores. Así que aquí voy.

Antes de comenzar con el factor humano, observé por un tiempo muchos blogs, pero me contuve de publicar el mío porque el formato me parecía muy narcisista, demasiado basado en el ego de personalidades con tendencias a la figuración. Aún creo que esto es verdad en muchos casos, pero me he demostrado que también se puede hacer de otro modo y que es posible utilizar el medio como una forma más de publicación, con características muy especiales e interesantes desde varias perspectivas.

Tengo la necesidad de compartir y publicar aquéllas cosas que me interesan de mi trabajo y mi permanente proceso de investigación y aprendizaje. Trato de hacerlo con la mayor seriedad y rigor. Soy responsable de lo que publico, y sé que entre los lectores de efh hay gente que está iniciándose en un mundo complejo como el del diseño y desarrollo web, así como otros profesionales con quienes comparto intereses y perspectivas, no necesariamente coincidentes, pero eso es parte del juego. Por lo mismo trato de documentar mis notas, aclarar mis dudas y no actuar de modo impulsivo. Tengo una responsabilidad hacia quienes me leen y confían en lo que publico. Esto es lo que procuro hacer en este sitio. También me tomo ciertas licencias y hago algunos paréntesis que son completamente personales, pero que también trato de hacer con respeto.

Lo mismo que hago ahora en efh lo hice en mi primera aventura web allá por 1999,directorzone.com, un proyecto personal en el que publicaba información sobre Macromedia Director, la primera herramienta en la que me especialicé a fondo.

Pero el hecho de que yo publique un blog, o que un millón de otras personas lo hagan no me familiariza automáticamente con ellas, no me hace parte de una comunidad. No por leer el periódico soy igual a todos los que leen el periódico. No por tener un blog soy parte de una comunidad. El medio es lo único común. Mi sitio no tiene nada en común con el fotolog de un estudiante que publica las fotos de la fiesta del fin de semana. Ni con el lo de alguien que desea ventilar sus intimidades públicamente. Tampoco con el de aquél que escribe temas serios, documentados, pero ajenos a mí. No me considero ni más ni menos que los anteriores, pero no somos lo mismo. Por lo tanto, desde mi perspectiva, la blogosfera es un concepto bastante débil. Tal vez las únicas formas reales de que estos espacios individuales se encuentren es en lugares como Technorati o Bloglines, en los que nuevamente es el medio, la tecnolgía el factor de cohesión.

Sí existe una comunidad entre quienes establecen una red de contactos y de comunicación por intereses compartidos. Yo leo los blogs de Dani Torres Burriel, de Juque, Juan Carlos García, Diego Lafuente, los chicos de Isopixel, Véase además, etc. (mis disculpas por las omisiones, pero ya entienden el punto), y muchos de ellos me leen a mí también. Eso es comunidad. Pero es en torno a ideas e intereses, no al medio. El medio es una circunstancia, claro que es facilitadora, pero no es más que eso.

Todo esto lo menciono porque vengo viendo repetidamente ideas sobre blogger power, ética del blog y otros sinsentidos más. Muchos de estos exabruptos surgen a raiz de la intención de comercializar con los blogs, desde el querer poner publicidad, hasta el cobrar por hacer cursos sobre el medio. Parece ser que ciertos personajes se toman el medio como una causa y no son capaces de ver más allá, respondiendo con intolerancia o quién sabe qué espíritu.

Es por esto que no he firmado la solicitud de Mi Primer PC, pero de verdad. Porque si bien coincido en algunos de los puntos, hay otros con los que no estoy de acuerdo. Por ejemplo, no estoy convencido de que Linux esté apto para usuarios no principiantes. Yo tengo varios años como usuario de PCs, conozco de programación y no se me prodría describir como primerizo o inexperimentado. Tengo en mi notebook una partición dual con WinXP y Fedora. Antes tuve Mandrake y Suse. Pero aún así he pasado horas en Linux solucionando problemas que deberían ser triviales de resolver. No le desearía esto a alguien que se enfrenta pr primera vez con un computador, la experiencia podría ser frustrante. Sí estoy convencido de que Linux es una muy buena alternativa en otros contextos y que en un tiempo más podrá competir con las interfaces gráficas de los OSs comerciales.

No pretendo abrir una discusión sobre el tema, entiendo muchas de las razones tras la falta de usabilidad en Linux. Soy usuario de muchas aplicaciones open source como OpenOffice, WordPress, etc. Mi punto es que la consigna de levantar a la comunidad bloguera, me queda grande. No existe tal comunidad. Y ya pasé algunos años luchando contra la dictadura(insertar ironía), tuve mi cuota de colectivismo.

Por eso los ataques al senador Flores, con quien no tengo ningún contacto, no soy lector de su blog, ni nada parecido, me parecen destemplados, carentes de análisis e irresponsables. Creo que la argumentación de Leo Prieto sobre el tema aclara la situación y deja fuera cualquier otra interpretación.

Por lo demás, si alguien quiere hacer de los blogs una forma de vida, vamos, todo es posible. Y si no te has enterado de los blogs corporativos, estás muy atrás en el asunto.

Continuando con la explicación sobre el uso de id y class en HTML, ahora corresponde revisar la segunda parte, cómo utilizamos estos atributos en CSS para aplicar diseño al contenido.

CSS utiliza selectores para identificar a qué parte de un documento se aplican los estilos. Los selectores son declaraciones de diversos tipos que permiten indicar con un nivel de detalle bastante preciso a qué se aplicarán las reglas de estilo. El selector más simple es el de elemento. Este selector identifica un elemento de HTML y aplica las reglas a todas las instancias de ese elemento en el documento. Por ejemplo:

p { font-size: 1em; }

En este caso, el selector determina que todos los elementos p utilizarán la regla indicada, según el ejemplo, su texto tendrá un tamaño de 1em. En consecuencia, este selector es uno genérico, que no permite un nivel de discriminación muy detallado. Se aplicará a todos los elementos que definamos, sin excepción.

Pero frecuentemente necesitamos seleccionar elementos con un grado de discriminación más refinado. Aquí es cuando entran los selectores id y class.

Cuando necesitamos seleccionar un elemento único dentro del documento para asignarle una regla específica, lo haremos a través del atributo que los identifica de modo exclusivo: el id. Como vimos en el post anterior, id permite identificar de modo único a un elemento, no puede haber dos elementos con un id con el mismo valor. Si por ejemplo tenemos un elemento definido como id="contenido", en CSS nos referiremos él del siguiente modo:

#contenido { margin: 1em 2em; }

Siempre que deseemos referirnos en CSS a un elemento con un id n, antepondremos el caracter # y luego, sin espacios, el id: #n.

En otras ocasiones necesitamos referirnos a un grupo de elementos que comparten una clase común. En el ejemplo del post anterior, mencionábamos una clase nota para identificar a párrafos usados como notas al pie. En este caso seleccionaríamos a estos elementos del siguiente modo en CSS:

p.nota { border: 1px solid #CCCCCC; }

El uso de class nos permite seleccionar un rango mayor de elementos. Hay una serie de usos más avanzados de este selector, además de otros más avanzados. Incluso es posible combinar diferentes tipos de selectores, pero eso queda para otro post, recordemos que esto es una introducción.

Para finalizar, en un post anterior titulado CSS y Semántica traté este tema un poco más profundamente.

Hace un par de días me escribió un lector de EFH para preguntarme la diferencia entre id yclass. Según mi experiencia en capacitaciones a equipos de diseño y clases en la universidad puedo decir que éste es uno de los conceptos que más cuesta asimilar cuando comienzas a trabajar en el esquema de HTML/CSS. Por lo tanto, aquí va mi aporte para aclarar las dudas.

Presentación y Contenido

Lo primero que tenemos que entender es que la idea tras el uso de CSS, es separar el diseño o presentación, del contenido. Esto suena simple pero es un concepto que toma tiempo dimensionar. Partamos por hacer algunas definiciones.

¿Qué es presentación? Todo aquello que sea una característica visual es presentación. Colores, espaciado, alineamiento, fuentes, tamaños, disposición, etc., son todos factores de diseño, que nada tienen que ver con el contenido.

Por otro lado, ¿qué es el contenido? Es el motivo para crear una página. Es el texto, imágenes y otros medios de los que trata un documento. Sí, dije imágenes y no fue un error. Hay que hacer una distinción importante, sin embargo: algunas imágenes son contenido, otras son presentación. Son fáciles de diferenciar, por ejemplo, la fotografía que acompaña a una noticia es contenido, porque aporta información y lo complementa. Una imagen usada como bullet en una lista es presentación, porque no aporta información al contenido, aunque haga la lectura más fácil o permita diferenciar los elementos que destaca.

Pero en el contenido hay un elemento subyacente que es clave para la separación real de contenido y presentación. Se trata de la estructura.

Estructura del Contenido

El contenido no sólo es el texto y los medios que constituyen la información. También es parte del contenido la estructura interna de éste. Esta estructura está dada por los tipos de datos, las relaciones internas y la jerarquía. Aquí es donde entra HTML.

HTML es un lenguaje de marcado, o para ser más claros, de descripción de contenidos. Cada elemento dentro de HTML está compuesto de dos partes: su contenido y la semántica. Veamos el siguiente ejemplo:

<h3>Estructura del Contenido</h3>

En este caso, el contenido es Estructura del Contenido, pero eso no es todo. Por sí sola, esa frase no tiene contexto ni otro tipo de información adicional, es sólo texto. Pero el hecho de estar encerrada en el elemento H3 de HTML entrega la información restante: este elemento es un título de tercer nivel, por lo tanto es un texto importante, es más importante que un párrafo, y probablemente define el contenido que sigue después de él. Pero es menos importante que un H2 o un H1, que definen contenido de mayor alcance dentro del documento.

Del mismo modo, cada elemento en HTML, y en mayor medida en XHTML, que busca depurar el vocabulario para eliminar los elementos de presentación, tiene un significado preciso. Sólo por nombrar algunos, A define el contenido como un vínculo y sus atributos hablan del destino (href), descripciones (title), idioma (lang), etc., STRONG y EMindican peso y énfasis, y así con los demás elementos.

Class y ID

En HTML y XHTML los atributos son información adicional que se aplica a los elementos. Por ejemplo, en el elemento IMG el atributo src indica la fuente o source para la imagen, su ubicación. Este atributo es específico para el elemento IMG, del mismo modo muchos elementos tienen atributos exclusivos. Pero hay otros que son globales y pueden ser aplicados a prácticamente cualquier elemento.

Dos de estos atributos comunes son id y class.

El atributo id permite identificar de modo único a un elemento dentro de un documento. De hecho id es la abreviación de identificador. Por lo tanto, sólo puede haber un único elemento con un identificar determinado. Por ejemplo, si un elemento tiene un id con valorpost-225 (id="post-225"), no podrá existir otro elemento en el documento que se llame igual.

El atributo class, en cambio, define la clase o tipo de un elemento. Por ejemplo, si observamos que frecuentemente utilizamos notas al pie en nuestros documentos, podemos crear una clase que se llame nota. Y la asociaremos a párrafos (P) que utilicemos para las notas:

<p class=”nota”>Esta es una nota al pie de página.</p>

Por definición, podemos asociar una clase a muchos elementos dentro de un documento, en cada caso estaremos diciendo: este elemento es de la clase o tipo X.

Como verás, la diferencia ahora es evidente. ¿Pero cómo uso esto para aplicar presentar el contenido con CSS? Eso lo explicaré en el próximo post con más detalle.

Yusef Hassan publicó la semana pasada un artículo sumamente interesante y muy bien documentado, titulado Patrones de Diseño de Interacción (II): Estructura y Características, que es la segunda entrega de Patrones de Diseño de Interacción (I): Introducción. Me interesan particularmente los patrones de interacción, he publicado un par en este mismo sitio y tengo planeado continuar en la medida que el tiempo me lo permita. Me enteré de la publicación de Yusef mientras revisaba las estadísticas de efh y encontré unas referencias que provenían de una cita de los patrones que publiqué, Menú de Navegación Principal yMenú de Rastros. Gracias por la mención Yusef, un honor.

Gerry McGovern da en el clavo. En su artículo Search optimization, not search engine optimization lo resume del siguiente modo:

Search optimization focuses on how people search. Search engine optimization focuses on how search engines work. Search optimization sees quality web content as its foundation stone.

http://www.gerrymcgovern.com/nt/2005/…

Si bien search engine optimization o SEO es un asunto relevante para la evolución de los propios buscadores y la optimización del servicio, frecuentemente se confunde la terminología y se utiliza este concepto para hablar de la optimización del contenido para mejorar la puntuación o ranking en los resultados de búsqueda. Normalmente los blancos de esto son buscadores grandes como Google, Yahoo! o MSN. Podemos encontrar innumerables sitios y hasta libros dedicados al tema, como Google Guide y el Google Ranking Factors – SEO List.

Es cierto que se pueden usar trucos para obtener una mejor posición en los resultados, pero lo mejor que podemos hacer es optimizar el contenido. El uso apropiado de términos clave en ubicaciones precisas, como los títulos (h1..h6), son una clara señal de que el documento trata sobre aquelos temas. La repetición de las palabras más relevantes, el uso de términos alternativos, destacar apropiadamente mediante em o strong y la referencia a otros sitios relacionados mediante vínculos cuidadosamente seleccionados. Es clave plantearse de qué forma los usuarios buscarán la información para establecer tanto los términos más importantes y las formas alternativas para ofrecer resultados.

Por ejemplo, esta nota está titulada Optimización de Búsqueda, No de Motores de Búsqueda, lo que seguramente hará pensar a Google, Yahoo! o MSN que esta página en particular trata sobre el tema de buscadores. La palabra Búsqueda está dos veces en el título y eso no es coincidencia. Luego, hasta este punto he repetido la palabra búsquedacuatro veces más en el contenido de este post. Eso cuenta, pero también he usado variaciones como buscador o buscadores. Para reforzar el concepto menciono al principio a tres de los buscadores más importantes que por los logs del servidor me consta visitarán esta página minutos después de ser publicada: Google, Yahoo! y MSN (aquí los estoy repitiendo nuevamente). junto con todo esto, he utilizado HTML (cite, strong, em) para destacar ciertas palabras e indicar así que son relevantes.

Y finalmente, hay una serie de vínculos, no demasiados, que refuerzan el tema que estoy tratando. Creo que si revisamos en unos días, esta página debería tener una buena posición en resultados de búsqueda para términos como búsqueda, buscador, e incluso Google.

Existen algunas herramientas que pueden ser utilizadas para analizar las palabras clave dentro de un documento, su ocurrencia y relevancia. Por ejemplo, puedes analizar este mismo post en seokeywordanalysis.com o www.webmaster-toolkit.com, que fueron dos resultados que obtuve rápidamente buscando en Google.

Y para concluir, ¿Por qué estoy haciendo esto? En realidad es para probar un punto y para aprovechar la oportunidad de hacer un experimiento interesante. Si ustedes comentan en esta nota, más posibilidades tendrá de mejorar su posición. Pero esta parte es un juego, planteemos una situación mucho más seria: ¿cómo garantizar que el contenido dentro de una intranet esté correctamente indexado, y que los funcionarios o empleados encuentren lo que necesitan rápida y efectivamente? Con estas mismas técnicas. Los buscadores no son muy diferentes unos de otros, y las herramientas de búsqueda de los sistemas de publicación comerciales operan de modo similar. Finalmente, la forma en que planifiquemos, organicemos y escribamos el contenido es muy relevante y beneficiará a los usuarios, permitiéndoles encontrar la información de un modo más eficiente.

Desde hace un par de días he estado trabajando en la plantilla de WordPress para EFH, y la referencia obvia para esto es el tema por defecto de WP, Kubrick. De hecho la mayoría de los temas disponibles son básicamente modificaciones de kubrick. Sin embargo mientras estoy revisando el CSS noto algunas cosas que me molestan y son básicamente la razón por la que he partido casi desde cero con mi nuevo tema. Se trata del uso nombres de clases que se refieren a la presentación, a características de diseño, antes que a describir la lógica o estructura del contenido.

He hablado antes sobre la importancia del uso semántico de HTML, es decir, de utilizarlo como un descriptor de la estructura del contenido. El código HTML de un documento debe hablar sobre su estructura interna, debe dar pistas del tema tratado. Su estructura de títulos debe ser una pauta de la jerarquía del contenido y cada uno de los demás elementos debería utilizarse de modo que su significado aporte sentido al contenido.

Del mismo modo, las clases o atributo class no deberían referirse a características de comportamiento o presentación. Es así como lo han entendido quienes están detrás del interesante proyecto de microformatos, Tantek Çelik y Eric Meyer, que básicamente utiliza el atributo class para dar significado nuevo al contenido.

El nombre de una clase debería ser neutro respecto a factores de presentación, por ejemplo, div class="alignleft" no es mejor que div align="left". Es cierto, valida, pero ése no es el objetivo detrás de la separación de contenido y presentación que permite CSS. Es mucho más lógico utilizar algo como div class="plantilla-bloque-a" que no determina la forma en que los elementos que declaren la clase plantilla-bloque-a serán presentados. ¿Qué sucede si en un rediseño decidimos cambiar todos aquellos elementos que antes, usando la clase alignleft, estaban alineados a la izquierda y ahora los centramos? Quedaremos con una incongruencia en que el HTML dice div class="alignleft" pero el elemento aparece centrado.

Para finalizar, les propongo algunas pautas para revisar los nombres de las clases que creemos en CSS/HTML:

• Comprobar que el nombre no describa una característica visual, como color, tamaño o posición
• Comprobar que el nombre no describa una función o comportamiento
• Verificar que el nombre describa el significado o tipo de contenido que describe
• Asegurarse de que el nombre es lo suficientemente específico y no crea confusiones con otros nombres similares
• Asegurarse de que el nombre es lo suficientemente claro como para que otros leyendo el HTML entiendan su significado y propósito
• Asegurarse de que el nombre será apropiado en el futuro, previendo en lo posible la forma en que el documento y el contenido puedan evolucionar

Una pauta clásica de las evaluaciones heurísticas de usabilidad se refiere al uso inapropiado de signos de exclamación en los mensajes del sistema a los usuarios. Se trata básicamente de no generar alarma innecesaria o de no utilizar un tono inapropiado que pueda intimidar al usuario generándole inseguridad.

Do error messages avoid the use of exclamation points?

Los signos de exclamación son elementos de puntuación con un significado específico: crean énfasis, destacando una palabra o frase. Por lo mismo, lo podemos aplicar adecuadamente para destacar situaciones riesgosas o que merezcan notarse especialmente, por ejemplo en:

¡Atención! ¿Está seguro de que desea eliminar el mensaje?

Pero si se trata de una alerta normal para indicar al usuario que faltan datos obligatorios en un formulario, no es necesario alarmarlo:

Faltan datos!!!!!

Esto puede parecer evidente, pero lo he observado con bastente frecuencia en varias evaluaciones. No olvidemos que los mensajes, instrucciones y la ayuda son parte de la interfaz de un sitio, aplicación o un sistema.

En casos extremos, esto puede llevar a situaciones peligrosas, como la potencial carencia global de pixeles negros provocada por el uso indiscriminado de signos de exclamación 🙂

Y para compensar la licencia humorística, un par de datos:

• El sitio de IBM tiene una interesante guía para el manejo de mensajes y errores
• Nielsen publicó un alertbox sobre el tema hace tiempo atrás, Error Message Guidelines

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

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:

• AJAX: Web “shift” or business as usual?, News.com
• Will AJAX help Google clean up?, News.com
• AJAX breathes new life into Web apps, InfoWorld.com
• Desperately seeking: More AJAX developers, ZDNet.com
• DHTML Utopia: Modern Web Design Using JavaScript & DOM, Sitepoint.com
• Ajax (Asynchronous JavaScript and XML), Informit.com

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