Flash exporta a… ¿qué, exactamente?

Adobe sigue blindando o intentando blindar a Flash (la herramienta de animación, más que la de desarrollo, parece) frente a los dispositivos (cada vez más, distinguidos por llevar al dorso un tatuaje de una pieza de fruta) que no reproducen Flash (el formato). Cosa que no debería sorprender a nadie. Pero sí me sigue sorpendiendo la manera en que lo están haciendo. Hoy han publicado en sus Labs Wallaby, an experimental technology that converts the artwork and animation contained in Adobe® Flash® Professional (FLA) files into HTML.

Si queréis ver un ejemplo de lo que hace, podéis ver un original en Flash y su transformación a HTML (encontrados ambos vía Andy Baio en enwire.dk). Las cosas que sorprenden:

  • Si habéis abierto la versión HTML con Firefox, Opera o IE… no habéis visto la animación. Porque ahora mismo solo funciona bajo navegadores Webkit (esto es, básicamente Safari y Chrome). Eso era razonable cuando hicieron la primera demo (a finales de octubre). Pero ya han pasado cuatro meses desde entonces…
  • Si abrís el código fuente veréis que no hay un canvas de por medio: el código muestra una colección de piezas en svg en divs anidados y animados en JavaScript usando jQuery y las herramientas de animación en JavaScript propias de WebKit.

Sus motivos deben tener, pero, por un lado, cuatro meses para lanzar algo a los Labs sin que funcione más que en navegadores (hasta ahora, al menos) minoritarios no me parece una gran idea. Uno podría sospechar que la idea es hacer algo que funcione óptimamente en la implementación de Webkit de Safari Mobile pero, entre nosotros, acabo de abrir la página en un iPhone y funcionar, funciona, pero… se arrastra. Y, por otro, si tenemos que imaginar que los desarrolladores de Webkit (y de Firefox Mobile, y de Opera Mini y Mobile) van a optimizar algo en sus motores, votaría por Canvas mucho antes que por cualquier otra cosa.

Vaya, que no dudo de la brillantez de los estrategas y desarrolladores de Adobe, pero no salgo de mi asombro…

Flash en [casi] todas partes

Adobe MAX está a punto de empezar pero la nota de prensa que va a ser la estrella ya está en línea: Flash Player 10.1 va a correr, en cuestión de meses, en prácticamente todos los dispositivos del planeta con suficiente potencia. A parte de las habituales versiones Windows, Mac y Linux, durante este 2010 va a haber “public developer beta” para Windows Mobile y Palm webOS, mientras que las versiones para Android y Symbian estarán para “principios de 2010” y, de regalo, Adobe y RIM han estado hablando, o sea que el Flash Player para Blackberry no puede estar lejos. Todo como resultado del Open Screen Project (del que ya habíamos hablado, hace casi año y medio).

Desde luego, falta el iPhone: la compañía de la manzanita y Adobe andan a la greña desde hace tiempo y, a pesar de que los rumores indican que Adobe tendría el Flash Player para iPhone acabado desde hace tiempo, la cosa no progresa adecuadamente…

Los más curiosos ya os podéis lanzar a la correspondiente página de Adobe Labs.

Buenas prácticas para la web móvil, del W3C

El original y una traducción, libre, de la lista de 60 buenas prácticas que tratan en profundidad:

  • Asegura que el contenido al que da acceso un URI dé una experiencia temáticamente coherente al acceder a él desde diferentes dispositivos.
  • Explota las capacidades de los dispositivos para mejorar la experiencia de usuario.
  • Toma pasos razonables para subsanar las implementaciones deficientes.
  • Haz pruebas sobre dispositivos reales, además de en emuladores.
  • Haz breves los URIs de los puntos de entrada.
  • Da solo una navegación mínima en lo alto de la página.
  • Ten en cuenta los compromisos entre tener demasiados enlaces en una página y pedir al usuario que siga demasiados enlaces para llegar a lo que busca.
  • Da mecanismos de navegación consistentes.
  • Asigna teclas rápidas a los enlaces de los menús de navegación y a la funcionalidad de uso frecuente.
  • Identifica claramente el objetivo de cada enlace.
  • Anota el formato del fichero enlazado a menos que estés seguro de que el dispositivo lo soporta.
  • No uses mapas de imagen a menos que sepas que el dispositivo los soporta de manera efectiva.
  • No uses pop-ups ni hagas aparecer otras ventanas ni cambies la ventana actual sin avisar al usuario.
  • No crees páginas que se autorefresquen periódicamente a menos que informes al usuario y le dotes de un mecanismo para detener el refresco.
  • No uses marcado para redirigir páginas automáticamente: configura el servidor para hacer las redirecciones mediante códigos HTTP 3xx.
  • Minimiza el número de recursos externos enlazados.
  • Asegúrate de que el contenido es adecuado para su uso en un contexto móvil.
  • Usa lenguaje claro y simple.
  • Limita el contenido a lo que el usuario ha pedido.
  • Divide el contenido en porciones usables pero limitadas.
  • Asegúrate de que el tamaño total de la página sea apropiado para las limitaciones de memoria del dispositivo.
  • Limita el ‘scroll’ a una dirección, a menos que el scroll secundario sea inevitable.
  • Asegúrate de que el material central al significado de una página preceda al que no lo es.
  • No uses gráficos para el espaciado.
  • No uses imágenes que no puedan mostrarse en el dispositivo. Evita las imágenes grandes o de alta resolución excepto cuando de otra forma se perdería información crítica.
  • Asegúrate de que la información comunicada a través del color también esté disponible sin este.
  • Asegúrate de que la combinación de color de primer plano y fondo dé suficiente contraste.
  • Al usar imágenes de fondo, asegura la legibilidad del contenido en el dispositivo.
  • Usa títulos de página breves pero descriptivos.
  • No uses marcos.
  • Usa las características del lenguaje de marcado para indicar la estructura lógica del documento.
  • No uses tablas a menos que sepas que el dispositivo las soporta.
  • No uses tablas anidadas.
  • No uses tablas para maquetar.
  • En la medida de lo posible, da una alternativa para las presentaciones tabulares.
  • Da un equivalente textual para cada elemento no textual.
  • No confíes en objetos embebidos ni scripts.
  • Especifica el tamaño de las imágenes en el marcado, si tienen un tamaño intrínseco.
  • Cambia el tamaño de las imágenes en el servidor, si tienen un tamaño intrínseco.
  • Crea documento que validen según las gramáticas formales publicadas.
  • No uses medidas en píxeles ni unidades absolutas en los valores de los atributos de los lenguajes de marcado y valores de las propiedades de las hojas de estilo.
  • Usa hojas de estilo para controlar la maquetación y la presentación, a menos que sepas que el dispositivo no las soporta.
  • Organiza los documentos de forma que puedan leerse, en caso necesario, sin las hojas de estilo.
  • Usa hojas de estilo cortas.
  • Usa marcado conciso y eficiente.
  • Envía el contenido en un formato que sepas que el dispositivo soporta.
  • Siempre que sea posible, envía el contenido en un formato preferente.
  • Asegura que el contenido use una codificación de caracteres soportada por el dispositivo.
  • Indica en la respuesta la codificación de caracteres usada.
  • Da mensajes de error informativos y formas de navegar desde la página de error a información útil.
  • No confíes en que las cookies estén disponibles.
  • Da información de caché en las respuestas HTTP.
  • No confíes en los estilos de las tipografías.
  • Minimiza las pulsaciones de teclas.
  • Evita la entrada de texto libre en la medida de lo posible.
  • Da valores por defecto preseleccionados siempre que sea posible.
  • Especifica modo de entrada de texto, idiomas y/o formatos de entrada por defecto, si el dispositivo los soporta.
  • Crea un orden lógico para los enlaces, controles de formulario y objetos.
  • Etiqueta todos los controles de formulario apropiadamente y asocia explícitamente las etiquetas con los controles.
  • Posiciona las etiquetas de forma que que queden dispuestas apropiadamente en relación a los controles a que se refieren.

Pocas sorpresas, mucho sentido común y un lenguaje, inevitablemente, políticamente correcto. Pero una buena lista de cosas a tener en cuenta cuando nos ponemos a desarrollar.

Web móvil y otras cosillas…

Excelente el artículo The Web Beyond the Desktop, de Dave Shea en Digital Web Magazine. No habla solo de web móvil, sino de cómo la experiencia web huye del escritorio habitual y se marcha a la sala de estar, al dormitorio y, desde luego, a los dispositivos móviles. Su cuadro de “device viewing scenarios” tiene números de convertirse en un clásico. Interesante también cómo incide en que las mejoras de accesibilidad deberían repercutir también en la experiencia “fuera del escritorio” y en que es conveniente diseñar interfaces diferentes al del sitio principal para su consumo en pantallas “pequeñas”. Lectura muy recomendable.

Aprovecho que el Pisuerga pasa por Valladolid para enchufar aquí un par de cosillas que tenía como borrador desde hace una eternidad.

La primera. A veces una pantalla pequeña es mejor. Mucho más discreto leer Google Reader o charlar por Messenger en una reunión con el N95 que con el iPod Touch, por no hablar de cosas más grandes, como un N800 o un portátil…

La segunda. Safari para iPhone y iPod Touch es ‘la web’ y no la web móvil. Jobs dixit. Opera Mini para el N95 (y demás dispositivos sobre los que corre) también afirma lo mismo. Tristemente, cuando lo dicen lo que quieren decir en realidad es que pasan olímpicamente de las hojas de estilo para handheld. Todo parece indicar que las próximas versiones de Internet Explorer para dispositivos harán lo mismo. Si eso es respeto a los estándares… Y aún así Google, Facebook, Yahoo! y demás grandes propiedades de la web se afanan en diseñar páginas específicas para dispositivos, mientras que “startups” como Mowser se dedican a “movilizar” sitios web de terceros. ¿No querrá eso decir algo? En mi experiencia particular, además, hace dí­as que le dije a Google Reader que reformatease las páginas web que visito desde él tanto desde el Touch como desde el N95. Efectivamente, los dispositivos móviles que usamos hoy en día son potentes como los ordenadores de anteayer. Pero las pantallas tienen los tamaños y resoluciones que tienen, las interfaces de usuario de los dispositivos son las que son (sin importar que sea un dedo, un teclado numérico o un mando a distancia, decididamente no son un ratón) y muchos de los elementos habituales en el diseño de interfaces web dejan de ser válidos.

Esta segunda observación me lleva a una recomendación del W3C en sus buenas prácticas para desarrollo web que no me cuadra en absoluto. Dicen: Diseña para una web única. No. De ninguna manera. Diseña para una web plural. En la que no sabes si el usuario mira una pantalla de 3 pulgadas a un palmo de distancia, de 17 a 4 palmos o de 42 a unos pocos metros. Y en la que el usuario puede navegar con un teclado numérico, los dedos, un ratón o un mando a distancia (ya que estamos, no olvidemos la posibilidad de que el usuario, directamente, no vea la pantalla y solo la oiga). Lo que nos lleva a poner los contenidos textuales primero, el maquetado después (a poder ser adaptado al medio), añadir las imágenes a continuación (de nuevo, a poder ser, pensando en tamaños y depeís) y, finalmente, añadir comportamientos (para los dispositivos en que tenga sentido)…