Estaré dando una charla sobre Videojuegos para la Web en la Universidad de Palermo. La primera parte será el día Lunes 18 de abril, y la segunda se hará el lunes siguiente: 25 de abril: ambos encuentros ocurrirán a las 11.30 de la mañana, en la UP: Mario Bravo 1050.

[Ni que lo digan… no salí favorecido en la foto.]

¿Por qué una charla de videojuegos para la Web?

En el último tiempo ha habido una revalorización de los videojuegos simples, también llamados arcade, debido a su inclusión en sitios web y aplicaciones para dispositivos móviles.

En el encuentro se expondrá el proceso completo de programación de un videojuego arcade. La actividad implica una excusa sobre la cual trabajar, a modo introductorio, el paradigma de Programación Orientada a Objetos (OOP) y la metodología para encarar un proyecto de este género desde el punto de vista del desarrollo.

El proyecto se programará en lenguaje ActionScript3. No se requieren conocimientos previos siendo que el curso no hará especial hincapié en el lenguaje de programación, su sintaxis, o la Plataforma Flash. Daremos lugar a la experiencia de una propuesta metodológica que implica la solución de problemas paso a paso.

De nuevo… ¿Dónde y cuándo?

Lunes 18 y 25 de abril – 11.30 hs.
Mario Bravo 1050 – Universidad de Palermo.

El acceso a la charla es gratuito, pero hay que inscribirse.
Click aquí para inscribirse.

Todos recordamos este simpático speech de aquel pelilargo y pollerudo William Wallace clamando por la libertad del pueblo escocés. Freedooom! Freedooom!

En fin, a raíz del artículo ¿Tiene el usuario todo el control sobre la interfaz? que escribió nuestra amiga Verónica Traynor acerca de la libertad que se debe dar al usuario cuando se proyecta una interfaz, se me ocurren algunas ideas que intentaré listar a continuación.

De buenas a primeras, lo primero que me viene a la mente es «no»: un acto reflejo me dice que no es bueno darle absoluta libertad sobre una interfaz al usuario pero inmediatamente después siento una molestia, algo así como una picazón en el omóplato, y que tiene que ver con la maldita costumbre —que tenemos muchos— de construir generalizaciones, soluciones universales y respuestas todo-terreno que no hacen otra cosa que concentrarse en la cuestión formal (morphé) del problema, quitando importancia a su materia (hylé). Por lo tanto, si me permiten, haré una breve divergencia en mi relato acerca de la libertad del usuario y hablaré de esto otro, sólo por un ratito. Ya vuelvo.

La sobreestimación de lo formal

Hace ya varios meses que tengo esta picazón que comentaba. En principio, la molestia viene de situaciones como la siguiente: ocurren los hechos A y B, por ejemplo, y las personas se empujan y apuran a establecer una regla universal de lo que se debe hacer en dichos casos (A y B), pero también en todos los demás: el resto de los casos similares que hay en el universo, entonces…

• Resulta que acontece esta explosión de datos confidenciales gracias a las maniobras de Wikileaks y de pronto todos creemos que es mejor que toda la información sea pública y esté a la vista. Sí, en un primer momento también yo lo creo así. Pero, ¿toda la información? ¿No habrá que analizar caso por caso? Mientras tanto ponemos el grito en el cielo cuando el gobierno de USA pide a Twitter datos de Julian Assange (al margen: Twitter, en una movida admirable y sin precedentes, defendió a sus usuarios no enviando los datos al gobierno norteamericano ¡Vamo’ Twitter!). No estoy criticando a Wikileaks —de hecho me provoca cierta simpatía—, simplemente me pregunto si podemos establecer una regla universal al respecto. Yo creo que no. Para ser franco, no quisiera mis mails personales dando vueltas públicamente por ahí. ¿Dónde está el límite? ¿Sólo en el carácter personal o gubernamental de los datos? ¿Quién decide cuáles datos deben mostrarse y cuáles no? Quizás sea útil que cierta información sea pública, como el manejo de dinero de los gobiernos, y que otro tanto no lo sea.
• Sobre las clases de la facultad: es cierto que la bajada de línea en teóricas y clases de taller no suele ser un buen proceso de aprendizaje para los estudiantes, cuyo mayor valor debiera ser el descubrimiento y la creación de conocimientos propios, junto con la formación de una fuerte capacidad crítica. Sin embargo hay situaciones en las que una cátedra debe bajar línea, y en todo caso analizar más adelante el resultado con el debido cuidado. Algunos preconceptos podrán reverse más tarde, o criticarse, o modificarse. Existen diferentes estadíos de maduración de un estudiante: cuando uno estudia necesita construir ciertas estructuras de pensamiento fuertes, aunque más no sea para luego tirarlas abajo; un alumno no podrá hacer una revisión y valoración crítica de sus estructuras de pensamiento si todavía no ha logrado construir esas estructuras.
• Cuando de diseño se trata: si la importancia radica en el proceso o en el resultado, en la etapa proyectual, o en el objeto terminado. ¿No será, digo yo, que habrá que analizar cada caso?

¿Será que en temas como estos y otros cientos, estamos dando demasiada importancia a la estructura, a la forma, y nos olvidamos del contenido? ¿Acaso ese contenido, que rellena cada situación particular con personas, contexto, historia y posibilidades a futuro, no es al menos tan importante como la estructura del problema particular que se está analizando?

Y entonces yo me pregunto: ¿Podemos seguir estableciendo reglas generales a base de enunciados muy escuetos que sólo plantean un problema como estructura, sin un análisis del caso en particular?

Es un poco de esta época, sip. Y aquella sensación de que la ciencia es esa cosa simple y un tanto graciosa que nos cuenta la sección de Ciencia y Salud del diario La Nación. Donde se extraen conjeturas sobre la raíz genética de cosas tales como la infidelidad a partir de experimentos con ratas de laboratorio. Está muy bien, es el proceso inductivo típico de la ciencia occidental llevado a su máximo y peor exponente.

Yo, sin embargo, confío en que —a pesar de sus falencias— la ciencia occidental todavía tiene mucho para dar, y que no se trata todo de genes, adúlteros y simpáticos roedores.

Luego de esta breve pausa…

Volviendo al asunto de la libertad del usuario de una interfaz, decía que mi primera impresión es que, a priori, otorgar al usuario la libertad absoluta de obrar sobre la interfaz no es una buena idea. En tantísimos casos —cuando usuarios— no tomamos las decisiones correctas estando al mando de una interfaz. Es nuestro trabajo, en tanto diseñadores (o UXores, o como fuere), establecer los límites en los cuales el usuario puede actuar: debemos prever casi todos sus movimientos y sus combinaciones de movimientos y evitar que pueda llegar a donde no queremos. Los caminos que no deseamos no deben ser parte de la interfaz: no deben formar parte del universo de posibilidades de dicha interfaz.

Ahora bien, que no panda el cúnico, sé que todo esto suena a postura filosófica, o peor: política si se quiere. Pues bien, aquí es donde mi largo intermedio toma importancia. NO. No me estoy refiriendo a lo que puede o no puede hacer un ciudadano, ni tampoco a lo que debe o no debe prohibírsele a un niño en la escuela primaria. Tampoco de coartar las posibilidades artísticas y/o de violación de una herramienta por parte de una persona con sensibilidad poética. Estoy hablando de un usuario ante una computadora con una interfaz (gráfica, por lo general) de software.

Y aún así, retomando todavía con mayor fruición mi intermezzo, habrá que ver cada caso. Por ejemplo: es muy probable que en las aplicaciones profesionales sí sea útil dar mayor libertad al usuario; aquí habrá que definir oportunamente qué es una aplicación profesional, establecer niveles de profesionalidad, etc. No es mi intención ahondar en este asunto ahora: mi tendencia a estirar el texto es algo infernal. Estoy fuera de control.

Un caso particular: MySpace

Hace poco, si creemos lo que se decía en varios sitios web, MySpace estaba a punto de prescindir del 60% de sus empleados.

He aquí un artículo que pueden leer en mayor detalle si tienen ganas, pero sucintamente esboza la siguiente idea: el fracaso de MySpace se debió, entre otras cosas, a la libertad con la que sus usuarios podían configurar y personalizar sus portales web personales: esto ocasionó que la gran mayoría de las páginas de esta inmensa red de contenidos fuesen espantosos atentados a la vista de los transeúntes cibernéticos (seguramente habrán tenido la ocasión de experimentarlo).

Supongo, entonces, que no podemos establecer una afirmación general de si conviene, o no, darle la libertad completa sobre la interfaz al usuario: habrá que analizar cada caso en particular, con sus características y condicionantes específicas.

Por lo demás, ojalá pueda el pueblo escocés —si quiere— lograr su independencia y soberanía algún día. Salutes!

El martes 5 de octubre a las 19 hs. daré una charla gratuita sobre HTML5 y CSS3 en Gutenberg.

La idea es charlar un rato, de forma introductoria, acerca de estas tecnologías y de los cambios que conllevan para el trabajo que realizamos diariamente los diseñadores y desarrolladores web.

Hablaremos, también, del curso Desarrollo Web nivel 2, que introducirá a un manejo avanzado de HTML5, CSS3 y JavaScript con jQuery.

Para informes e inscripción a la charla gratuita, escribir a cursos@fundaciongutenberg.edu.ar , los cupos son limitados.

¡Allí nos vemos!

Hace varios días que tengo este post en mente (To be or not to be HTML5), y no he encontrado el tiempo para desarrollarlo y publicarlo.

Hoy comienzo mi día de trabajo y leo un tweet de Jeffrey Zeldman, que nos lleva a un comentario donde aclara ciertas cuestiones relacionadas con la confusión general que está experimentando el común de la gente, acerca de lo que efectivamente es HTML5. Ahora bien, cuando el querido Zeldman escribe algo similar a aquello que viene rondando nuestros pensamientos, uno se siente bien: debemos ir por buen camino. Así es que decidí apurarme y publicar aunque sea algunos pensamientos fragmentados, desprolijos, y sacarlos afuera de una vez.

¿Qué es HTML5 y qué no?

Primero lo primero: las tecnologías y estándares web son muchos y muy abarcativos, pero hay tres que son fundamentales y juegan un rol protagonista en la mayoría de los sitios web:

• HTML (sea cual fuere la versión)
• CSS (sea cual fuere el módulo)
• JavaScript (lo dicho)

Ahora bien, estas tecnologías cumplen tres funciones muy diferentes que se complementan mutuamente, a saber:

• HTML (contenido estructurado semánticamente)
• CSS (presentación; los diseñadores podemos llamarlo “diseño”)
• JavaScript (comportamiento)

Cualquiera que se dedique al desarrollo web de calidad tiene este concepto tatuado en el cerebro o se dedica a alguna otra cosa (fuegos de artificio… digo, manejo de Fireworks).

El punto es que en las últimas semanas, una monstruosa cantidad de posts, comentarios, tweets y charlas de café abordan la temática HTML5, citando ejemplos que, o bien no son HTML5, o bien lo son, pero cuyas características principales no tienen que ver en absoluto con el uso (o no) del futuro estándar HTML5. Incluso Apple ha decidido sumarse a la confusión de una forma espantosa: creando una web donde todos los ejemplos utilizan HTML5 (es cierto), pero muchas de las características que se muestran como sus bondades dependen —en realidad— de las bondades de CSS3, o JavaScript, y podrían realizarse sin problemas utilizando las tradicionales versiones HTML 4 ó XHTML 1.

Haremos a continuación un par de listas que reflejan algunos ejemplos (sólo algunos) de lo que es, y no es HTML5. Adelantamos, de todas maneras, que cuando una gracia relacionada con el diseño de una página web —como la posibilidad de rotar el ángulo del texto, o de generar cajas con puntas redondeadas—, está publicada como una bondad de HTML5, habrá que al menos sospechar (sabemos que el HTML no debe encargarse del diseño/presentación del contenido, sino de marcar correctamente el contenido en sí mismo; es la tecnología CSS la que se ocupa de la presentación de los elementos que el HTML describe).

To be HTML5

• Nuevas etiquetas que ayudan a marcar mejor el contenido a nivel semántico: <section>, <header>, <footer>, <nav>, <article>, <time>, etc.
• La posibilidad de incluir video y audio sin la utilización de tecnologías externas y plugins adicionales: <video> y <audio>.
• La posibilidad de generar experiencias altamente interactivas, dibujando sobre cierta área con JavaScript, sin la utilización de tecnologías externas y plugins adicionales: <canvas>
• Un doctype human-friendly (finalmente), que no comunica la versión del HTML: <!DOCTYPE html>
• La posibilidad de utilizar la sintaxis del viejo HTML o la de XHTML (que sigue la sintaxis del metalenguaje XML).

Not to be HTML5

• Texto rotado, puntas redondeadas, sombras estilo drop-shadow, imágenes y colores en transparencia, y todo tipo de situaciones que dependen del área de presentación/diseño de una página web, y que es responsabilidad exclusiva de la tecnología CSS. Por lo general, debemos estas nuevas posibilidades a CSS3.
• Animaciones de objetos que aparecen, desaparecen, se mueven, agrandan, colapsan y cambian su forma. Cuestiones que evidentemente tienen que ver con el comportamiento de un site, y que suelen programarse en JavaScript.
• Geolocation: muchos suelen decir que se trata de parte del futuro estándar HTML5, pero no.
• Posibilidad de visualizar el website en celulares y equipos móviles como el iPhone, iPad y similares: este asunto es escabroso, pero tampoco es exclusivo de HTML5. El debate Flash vs HTML5 ha generado la equívoca sensación de que para que un celular pueda interpretar correctamente una página web, ésta debe estar codificada en HTML5, cuando lo que en realidad ocurre es que simplemente se debe evitar la utilización de la tecnología Flash.
• La tecnología que hace volar al DeLorean en Back To The Future II.

Pero…

Como comenta el estimadísimo Jeffrey Zeldman, el hecho de que aquellos no-geeks (a veces gerentes de empresas, y quienes deciden cuándo/cuánto invertir en tecnología web) estén entusiasmados con el concepto HTML5, es genial y beneficia a la Web en general. Cuando estas personas se refieren a HTML5, en realidad se están refiriendo a un conjunto de tecnologías nuevas que incluyen HTML5, CSS3, manejo de JavaScript avanzado y algunas otras más crípticas como Microformats, Geolocation, Microdata, etc.

Es nuestro deber, como profesionales con conocimiento técnico, al menos tener la delicadeza de nombrar este conjunto de tecnologías por lo que son, o como bien recomienda Mr. Zeldman, titularlas: “HTML5 and related technologies” (HTML5 y tecnologías relacionadas). De esta manera, /1. mantenemos el halo marketinero del asunto y /2. evitamos malentendidos.

There, I said it. Pensamientos fragmentados y desprolijos afuera.

Es genial cuando se logra explicar un asunto complejo de forma simple. Aquí una explicación acerca del funcionamiento del buscador de Google.

En los últimos meses se ha hablado, escrito y discutido muchísimo acerca de cuestiones relacionadas con el universo del desarrollo web, el desarrollo de aplicaciones para smartphones y depravaciones similares, cuestiones político-filosóficas acerca del futuro de la web y del modelo de negocio de las empresas más pesadas dedicadas al software. Todo en la misma bolsa.

¿Un post más acerca de todo esto? En serio… ¿otro más? Sip. Un poco porque contar me ayuda a ordenar las ideas y otro porque probablemente le sirva a alguna que otra persona interesada, que todavía no hubiera llegado a entender de qué se trata todo esto, por qué tanto revuelo y cómo se relacionan estos asuntos entre sí.

First thing first

A continuación, una breve reseña descriptiva de algunas cuestiones:

• Hace algunos años (en el 2000 aproximadamente) la W3C intuyó que el futuro de la web no podría montarse sobre nuevas versiones del viejo y peludo HTML —ya muy vapuleado—. Decidieron lanzar al ruedo una nueva recomendación, que sentaba las bases de una línea de pensamiento renovada, un HTML más ordenado, limpio y estructurado, uno basado en el estándar XML: así nació el XHTML. Hoy, diez años más tarde, nos encontramos ante una situación similar: con una W3C que decide —en vez de continuar la lógica del XHTML y generar una versión 2.0— volver a la ruta del HTML y se encuentra as we speak desarrollando el mentado HTML5 (cambio de rumbo que se vio influenciado por el trabajo realizado por el WHATWG). Casi una marcha atrás, pero no.
• Apple, empresa que diseña y fabrica la línea de smartphones más popular del mercado, se niega a permitir la ejecución de Flash en sus artefactos. Adobe pone el grito en el cielo al tiempo que algunos usuarios. Steve Jobs, CEO de Apple, publica una carta en abril de este año, en donde explica el por qué de su decisión. Adobe responde con una campaña publicitaria titulada “We love Apple”.
• Apple apoya el formato HTML5 y se instala en el mercado que la Plataforma Flash está en decadencia, con la nueva versión de HTML como su verdugo y sucesor. Nace la rivalidad HTML5 vs. Flash.
• Tooodo el mundo enloquece con las vistosas nuevas posibilidades de lo que dan en llamar HTML5 (aunque en muchos casos se trata de posibilidades absolutamente factibles aún sin la utilización del dichoso HTML5). Hay la sensación de que algo groso, muy groso, está ocurriendo en el universo del desarrollo web.

¿Qué demonios está ocurriendo?

Trataremos de ordenar un poco el panorama, ahora sí, olvidando la poca objetividad que pude esbozar en los párrafos anteriores. Todas estas cuestiones se relacionan íntimamente. Veremos…

¡Que vivan los estándares!

Durante un largo tiempo, desarrolladores web y otros evangelizadores han invertido una enorme cantidad de energía en la utilización de estándares. —Me incluyo en la humilde y pequeñísima porción que me toca: comencé a utilizar estándares XHTML y CSS allá por el 2003 en trabajos para clientes, todo se veía para el traste en Internet Explorer y los clientes me querían mandar a matar.— Esto se hizo con muchísimo esfuerzo, contra la corriente y en oposición a muchos intereses económicos. Ha sido una tarea hercúlea que dio sus frutos: hoy podemos decir que los estándares web gozan de buena salud, buena publicidad y buen funcionamiento en casi todos los navegadores web.

¿Qué significa esto? Significa, entre otras cosas, que un sitio web desarrollado acorde a estándares tiene una alta probabilidad de funcionar correctamente en una gran cantidad de navegadores web. Significa, también, que personas no videntes, con visión reducida o problemas motrices severos, pueden navegar sin mayores inconvenientes gracias a una web más accesible. Esto último es muy importante: es equivalente a rampas y ascensores en edificios públicos.

En el pasado, algunas empresas (principalmente Microsoft) vieron esta democratización en cuanto a la libre elección de navegadores web como una amenaza contra la preponderancia del Internet Explorer, e hicieron todo lo posible por retrasar el avance en relación a los estándares web. Las consecuencias de esta estrategia han sido tan fuertes que aún hoy lo sufrimos a diario, tanto navegantes como desarrolladores.

¿Qué ha cambiado?

Los intereses económicos han cambiado. Por estos días, Apple —cuyo capital ha superado al de Microsoft muy recientemente—, basa la porción de su negocio con mayor crecimiento en sus plataformas mobile, esto es: iPhone, iPod touch y iPad. Estos artefactos son computadoras —mi Motorola W375 también, aunque sea menos evidente— pero, a diferencia de sus hermanas de escritorio, tienen menos velocidad de procesamiento, sus componentes son muy pequeños, se encuentran empaquetados de la manera más comprimida posible, y deben economizar la potencia de procesamiento al máximo para evitar el sobrecalentamiento y utilizar el menor consumo de batería posible.

Apple necesita del HTML5, y no es una cuestión de filantropía. Lo necesita porque puede brindarle contenido textual, imagen, animación, video, audio e interactividad utilizando pocos recursos. Los desarrolladores web nos encontramos ante una situación muy extraña: de repente el gran capital está a favor de los estándares web. ¿Algo andará mal? Not quite.

What’s up Flash?

El asunto Flash está sobredimensionado, salvo que se lo mire desde el interior mismo de los cuarteles de Adobe. La remota posibilidad de la desaparición de Flash, debe preocupar a nadie salvo a sus mismísimos fabricantes. En lo personal, le tengo muchísimo cariño a la Plataforma Flash, me ha dado de comer durante años, ha significado el 70% de mi trabajo de programación diario, pero debo admitir que la Web será un lugar tanto más feliz cuanto menos preponderancia posea Flash.

Las dos virtudes más importantes de la Plataforma Flash son:

• Un altísimo grado de interactividad, incluyendo texto, imagen, animación, audio y video.
• Fidelidad absoluta entre diferentes plataformas. Un contenido Flash se verá exactamente igual en Mac OS, Windows, y en algunos casos Linux, incluso cuando vistos en diferentes navegadores como Internet Explorer, Firefox, Safari, etc.

Por otro lado, los grandes problemas del Flash son:

• Una performance paupérrima. Basta con mover un objeto más o menos grande (una foto que ocupe toda la pantalla, digamos) para que algunas notebooks levanten su temperatura en segundos.
• Una cantidad incontrolable y muchas veces indocumentada de bugs. Aún en la última versión de su lenguaje de programación, ActionScript 3.0, programar en la IDE de Flash suele ser un safari infernal a lo desconocido.

¿Comienzan a vislumbrar el asunto? Flash tenía sentido en una realidad donde la fidelidad de un mismo contenido entre navegadores era muy pobre (una misma página web se veía y funcionaba de formas diferentes según desde qué navegador se ejecutara), y donde alcanzar un alto nivel de interactividad que incluyera audio, video y animación era imposible en el marco de los formatos estándares propuestos por la W3C.

Ahora bien, hemos sido testigos de la carrera de Intel y AMD por generar procesadores cada vez más rápidos y poderosos, pero esos tiempos se han acabado. El mayor interés actual es lograr un alto poder de procesamiento, en poco espacio, con poco consumo de energía y poca necesidad de ventilación. El gran capital necesita procesadores que puedan hacer funcionar sus nuevos gadgets para la burguesía tecnológica y software altamente optimizado que acompañe dicho ahorro de energía.

Como dijimos, Flash sufre de una performance paupérrima, un pésimo uso de la energía y está lleno de bugs. Que se cuelgue una aplicación en una computadora de escritorio es una cosa (force quit o ctrl+alt+delete y chau), que se cuelgue una aplicación en un teléfono móvil implica que la batería se consuma en unos pocos minutos: un día entero de incomunicación.

Contenido semántico

En los últimos años se habló mucho acerca de la web semántica. El asunto merece un post al margen, pero haré un breve reconto de por qué es importante en medio de todo este asunto.

La web abriga una cantidad demencial, inimaginable, incuantificable, infernalmente gigante de contenidos. Esto dificulta un tanto su accesibilidad. Cómo encontrar el contenido necesario entre semejante cantidad de datos es uno de los grandes temas en el campo de preocupaciones de científicos, ingenieros especializados y desarrolladores web. La respuesta es simple: hay que ordenar el contenido de alguna forma, hay que darle estructura.

El asunto es que la mayoría de las veces, quienes buscan entre el contenido son robots. Google puede mostrar una lista de resultados más o menos útiles en nuestras búsquedas, porque periódicamente envía una tropa de robots a darse una vuelta por la web, y a anotar lo recolectado en bases de datos. Cuanto mejor entienda la información este robot, más efectiva será la lista de resultados que ofrezca el motor de búsqueda.

La estructuración de ciertos tipos de datos en formas estándar, permite que estos robots puedan comprender la naturaleza de la información y sus relaciones. Por ejemplo, en los sitios web que están bien desarrollados y acorde a estándares, el robot de Google entiende qué partes de cierta página son más importantes, cuáles textos son títulos, a qué párrafos corresponden, de qué tratan las imágenes, etc.

Hoy en día, existen propuestas estándares para codificar muchos tipos de datos, por ejemplo un evento. Esto implica que es hipotéticamente viable, con la ayuda de Google y un smartphone con GPS, pararse en cualquier esquina de Buenos Aires y buscar eventos que ocurran de aquí a 4 horas, en un radio de 20 cuadras. Esto se hace posible únicamente en el marco de una web semántica, que sigue ciertos estándares.

¿Por qué nos interesa todo esto? Porque la información que se encuentra en un archivo HTML o XHTML (es decir, en una página web), es información que se encuentra accesible a robots, y que puede estructurarse semánticamente sin problemas. El Flash no lo permite, y es probable que no lo permita nunca, salvo que cambien cuestiones de la naturaleza de fondo de la tecnología.

¿Desaparecerá el Flash?

No creo. Pienso que se va a enfocar fuertemente al desarrollo de aplicaciones multiplataforma, lo que hoy en día Adobe llama Air, o tecnologías similares. Sin dudas la utilización de Flash en web está decreciendo, esto es un hecho. Apple ha ayudado mucho a acelerar el proceso. Vale la pena aclarar, sin embargo, que todavía no ha salido al mercado una versión del Flash Player que funcione en dispositivos móviles —con o sin manzana— por lo que está por verse si efectivamente Flash estará disponible en celulares y tabletas interactivas. Hoy en día hay un beta del Flash Player corriendo en un beta de la próxima versión de Android, el sistema operativo mobile de Google.

En ciertos casos clave, cuando se necesite un altísimo nivel de interactividad con una curva de aprendizaje más o menos sencilla, la tecnología de Adobe seguirá siendo una buena opción. Mientras tanto, sólo queda observar atentamente cómo se desarrollan los hechos, e ir practicando muuucho JavaScript ;-)

El lengueja de programación de la Plataforma Flash ha pasado por 3 versiones: ActionScript 1, ActionScript, 2 y ActionScript 3. Como sabemos, varias cuestiones han cambiado en el paso de AS2 a AS3. La carga de archivos externos es una de ellas. Si bien la traducción literal es más o menos sencilla, vale la pena repasarla.

Lo que en AS2 solíamos hacer así:

loadMovie("archivo_secundario.swf", this);

En AS3 se debe hacer así (el ejemplo citado a continuación está copiado de la documentación de Adobe, y luego ligeramente modificado):

import flash.display.*;
import flash.net.URLRequest;
var cargador:Loader = new Loader();
var urlReq:URLRequest = new URLRequest("archivo_secundario.swf");
cargador.load(urlReq);
this.addChild(cargador);

Más allá de lo que se puede ver a golpe de vista, hay un par de cuestiones interesantes que trataré de sacar a la luz en este post.

El ejemplo de Adobe:

Antes de crear nuestro propio ejemplo —seguramente más complejo— repasaremos lo que hicieron los muchachos de Adobe. El ejemplo original se incluye en la documentación de la clase Loader (encargada de la carga de archivos externos en AS3).

Se importan las clases necesarias para la realización de la carga de un archivo externo. Nosotros lo haremos de forma detallada cuando nos toque crear nuestro propio ejemplo. Adobe ha sido un poco vago al importar todas las clases del paquete flash.display sin mayores precisiones (como podrán ver ustedes mismos, ésta no es una práctica muy amigable ya que el paquete flash.display contiene numerosas clases que no están siendo utilizadas por el resto del código).

// importar las clases necesarias:
import flash.display.*;
import flash.net.URLRequest;

Se crea una instancia de la clase Loader, que hará las veces de cargador. Este tipo de objeto (que hereda de la clase DisplayObjectContainer) tiene la funcionalidad necesaria para realizar la carga.

// crear el cargador:
var cargador:Loader = new Loader();

Se prepara una instancia de URLRequest, el tipo de objeto que espera recibir el método load de la clase Loader.

// preparar la URL request:
var urlReq:URLRequest = new URLRequest("archivo_secundario.swf");

Efectivamente se da la orden de carga por medio de la función load, incluyendo como parámetro a aquel objeto de tipo URLRequest que creamos anteriormente.

// se da la orden de carga:
cargador.load(urlReq);

Hasta aquí, la carga del archivo externo ya se puso en marcha, pero aún queda agregarlo a la escena. La siguiente línea de código agrega al cargador (de tipo Loader) a la escena, como child del root. Siendo que los objetos de clase Loader heredan de DisplayObjectContainer, tienen la posibilidad de agregarse a la Display List, al igual que un MovieClip o un Sprite.

// poner el cargador en escena:
this.addChild(cargador);

Recordemos el código completo, comentado:

// importar las clases necesarias:
import flash.display.*;
import flash.net.URLRequest;
// crear el cargador:
var cargador:Loader = new Loader();
// preparar la URL request:
var urlReq:URLRequest = new URLRequest("archivo_secundario.swf");
// dar la orden de carga:
cargador.load(urlReq);
// poner el cargador en escena:
this.addChild(cargador);

A primera vista, parece mucho más complejo que la escueta versión en AS2 (y lo es), pero en programación menos no siempre es más. El cambio a AS3 nos facilita la resolución de errores y la generación de diferentes funcionalidades. El código nuevo ganó en complejidad, pero también en coherencia, orientación a objetos, facilidad en la solución de errores y funcionalidad.

Veremos un poco más a fondo el asunto en la siguiente página…

Quienes trabajamos en el desarrollo de sitios web sabemos que el Internet Explorer, de Microsoft, es de lo peor. Lo sabemos, no por nuestro fanatismo geek, los numerosos artículos que versan sobre sus vulnerabilidades en materia de seguridad, o por boca de terceros, sino porque sufrimos diariamente sus caprichos y su incorrecta interpretación de código HTML y CSS.

Cuando terminamos de escribir el código y los estilos de un sitio, cuidando que todo esté acorde a los estándares dictados por la W3C, y pasamos a testearlo en diferentes navegadores, vemos que la mayoría muestra las páginas de la forma esperada… la mayoría, salvo el Internet Explorer. De ahí que estamos obligados a introducir hacks —en muchos casos incluso código no estándar— para reparar el problema. Este fenómeno suma horas, complicaciones inesperadas, incertidumbre y stress a nuestra tarea de desarrollo.

Una posible solución a largo plazo, es procurar que los usuarios elijan otros navegadores y dejen de utilizar IE (algo que está ocurriendo: las estadísticas de los últimos años muestran cómo viene perdiendo terreno el que alguna vez fue el navegador más utilizado).

Educar al soberano:

Dejar de incluir hacks en los sitios que desarrollamos sería una buena táctica; algo así como una guerrilla de insurrectos desarrolladores web —aunque convengamos que sería complicado explicarle a nuestro cliente que ve su sitio destartalado porque está utilizando Internet Explorer, que es el peor navegador, y entonces debiera cambiarlo y utilizar Firefox, o Chrome o Safari, lo mismo que los demás visitantes del sitio—. Eso es imposible. El cliente quiere que su sitio se vea perfecto en todos los principales navegadores, especialmente en el bendito Explorer.

Estos pocos días que transcurrieron desde que puse en marcha mi blog personal me han enseñado mucho. Ayer, por ejemplo, pensé que tener un sitio web personal implica hacer lo que se me de la gana. Decidí que no agregaría hacks para solucionar los errores de interpretación de IE, y que aportaría mi granito de arena para explicarle a los navegantes usuarios de Explorer que les convenía utilizar otros navegadores. Decidí incluir un cartel —visible únicamente para usuarios de IE— que los alerte e invite a probar otras alternativas.

Hay muchas maneras de presentar contenido únicamente a Internet Explorer. Voy a explicar a continuación cómo está resuelto en el caso de este sitio web en particular.

A modo de receta de cocina, diré que haremos uso de:

• los comentarios condicionales de IE.
• un poco de javascript no intrusivo.
• css a gusto para condimentar.

Comentarios condicionales:

Quizás porque la gente de Mircosoft sabe que su navegador deja mucho que desear, inventaron una forma fácil para que los desarrolladores podamos escribir código que sólo el IE pueda ver; lo hicieron en la forma de comentarios de HTML, pero con una estructura estándar que el IE leerá.

Haciendo uso de esta posibilidad, podemos agregar un archivo JavaScript externo, que sólo IE verá. Escribiendo el siguiente código dentro de la etiqueta head:

<!--[if IE]>
    <script type="text/javascript" src="ruta_al_archivo_javascript.js"></script>
<![endif]-->

Los demás navegadores verán eso como parte de un comentario de HTML, y no cargarán el JS externo.

Un poco de JS no intrusivo:

A continuación, utilicé un poco de JavaScript para escribir contenido en el HTML. ¿No podría haber escrito el código HTML directamente dentro de la etiqueta body, utilizando los comentarios condicionales propios de IE? Sí, lo podría haber hecho, pero preferí utilizar JS porque no quería ensuciar el código HTML (ni siquiera con un “comentario”) con todo este asunto. Cada cual podrá sopesar qué le conviene, según el caso.

El código JS será algo así:

// definir la funcion escribirCartelIE:
function escribirCartelIE() {
    // chequea que funcione el control del DOM desde JS:
    if (!document.getElementsByTagName){
        return;
    }
    // crear una referencia al body:
    var body_element = document.body;
    // modificar el contenido del body, agregándole un poco de HTML al principio:
    body_element.innerHTML = '<div id="cartel_ie"><p>Ups! Est&amp;aacute;s utilizando Internet Explorer.</p><p>El <strong>Microsoft Internet Explorer</strong> es un navegador web inseguro, inc&amp;oacute;modo y cuya habilidad para mostrar correctamente las p&amp;aacute;ginas web deja mucho que desear. Por fortuna, no es el &amp;uacute;nico navegador que existe en el mercado. Te recomiendo que pruebes alguno de los siguientes navegadores:</p><ul><li><a href="http://www.mozilla.com">Mozilla Firefox</a></li><li><a href="http://www.google.com/chrome">Google Chrome</a></li><li><a href="http://www.apple.com/safari/">Apple Safari</a></li><li><a href="http://www.opera.com">Opera</a></li></ul></div>' + body_element.innerHTML;
}
// hacer todo cuando se cargue el HTML:
window.onload = escribirCartelIE;

Desde ya, el mensaje puede ser otro. Estoy seguro de que tendrán más imaginación que yo a la hora de redactar el texto.

Fíjense que no incluí código JS en el html. Recuerden que es siempre conveniente mantener separado el contenido (HTML), de la presentación (CSS) y del comportamiento (JS).

CSS a gusto:

Cuando el IE termine de cargar la página, ejecutará la función escribirCartelIE, que modificará el contenido del HTML. A partir de ese momento, el HTML literalmente tendrá nuevos elementos: un div con id cartel_ie y su contenido.

Las órdenes de cómo deben presentarse estos elementos, pueden estar junto con los demás selectores, en el archivo CSS que se esté usando. Esto no afecta al resto del contenido del CSS. Los navegadores que no tengan ese elemento en el HTML, no aplicarán esas órdenes del CSS.

Aquí, a modo de ejemplo, el código CSS que se está utilizando en este sitio:

/* css para IE */
#cartel_ie {
    width: 428px;
    padding: 10px;
    border: 1px dotted #F0F;
    font: 13px/1.5em Georgia, "Times New Roman", Times, serif;
    margin: 10px auto 5px 249px;
}
#cartel_ie .titulo {
    font: 16px "Courier New", Courier, mono;
    color: #F0F;
}

¡Los invito a hacer una movida similar en sus sitios web personales! Un pequeño banner no basta.