Dando la chapa

Nope, no me he equivocado con el título. WWWW stands for:

WHO did WHAT, WHEN and WHY: Source control for Flash.

Y es el nombre de la charleta que voy a dar en el London Flash Platform User Group el 31 de Julio. Es la charleta que quería dar este año en Subflash pero como no puedo ir, pues le comenté a Tink que si le parecía interesante y me dijo que sí. Claro, que tampoco creo que haya muchos ponentes o público por Londres en mitad del verano : ) Lo cual me viene bien porque así salga como salga yo puedo decir que salió muy bien y no va a haber mucha gente que me pueda contradecir!

En fin, que veremos lo básico del control de versiones (SVN que está de oferta), por qué es tan importante, etc. La charla será totalmente práctica, una demo en vivo y en directo. Aun así quiero preparar algo más elaborado y tenerlo colgado antes de la fecha. Quizá hacerlo parte de Lo que yo sé de.

Pues eso, que si andáis por London en esas fechas y os apetece pasaros a criticar mi Inglés después de maś de dos años aquí, sois bienvenidos.

No he escrito un libro (bueno, no he publicado, escrito sí), no he tenido un hijo y no he plantado ningún arbol, pero lo que más me dolía hasta la fecha era no tener mi juguetito propio. No tener mis usuarios cabreados por mis bugs, o gente pidiendo mejoras a gritos. Y aunque aun sigo sin tenerlos, he puesto la primera piedra cual inauguración de carretera:

HippoHX

¿Qué es?

Software para hacer aplicaciones de escritorio en Flash. Técnicamente: APIs + herramientas encima de SWHX.

Podéis echarle un ojo a las FAQs y los tutoriales.

¿Pero esto no es lo mismo que AIR y Zinc?

Misma intención sí, las diferencias son:

*AIR está mucho mejor, mucho más robusto, muchas más APIs, puedes incluir páginas HTML (SWHX e HippoHX no), funciona en Linux (HippoHX sólo en Mac y Windows y no completamente aun) y tiene una gran empresa detrás.
*HippoHX es Open Source :)

Parece que lo digo de coña, pero no. Con la “caida” de Screenweaver (Edwin lleva desaparecido en combate casi 1 año desde que fichó por Adobe) nos habíamos quedado sólo con AIR y yo creo que es importante que haya una alternativa libre.

A mucha gente puede que esto no le diga nada, pero a mucha otra sí. Cuando hablas de extensibilidad o poder arreglar tus propios problemas, el código abierto gana por goleada.

Dicho todo esto, estamos a muuuuuuucha distancia de AIR o Zinc. Es más, NO USES HIPPOHX SI TIENES MUCHA PRISA Y POCAS GANAS DE RASCARTE LA CABEZA. Por ahora las herramientas sólo funcionan por línea de comandos y necesitas instalar un puñado de cosas si quieres recompilar los fuentes. Pero non ti preocupare, mi idea es hacer esto lo más fácil posible para el usuario final, por lo menos tan fácil como era Screenweaver en su tiempo. Simplemente aun no hemos llegado, un poco de tiempo por favor!

Publico esto por aquí más que nada para ver si hay gente que se anime a echar una mano con lo que sea. Especialmente ando buscando diseñadoiros que nos ayuden con ummm… el diseño. Si vais a la web podréis disfrutar del diseño Zárate-style, marca de la casa. Si os bajáis los ejemplos, no te quiero ni contar, feos a todo lo que dan clamando por una manita de pintura.

Necesitar necesitamos el lote completo: logo, web, usabilidad para la futura GUI… De todas formas como supongo que NO me llegarán millones de propuestas he pensado darle una oportunidad a 99Designs, echadle un ojo a este post en la lista de correo.

En fin, que a ver si se anima alguien y hacemos de esto algo útil.

Por cierto, hablo todo el rato en plural mayestático porque queda mucho mejor, pero el único friki picando soy yo.

¡Salud!

Esta semana he tenido que andar instalando y desinstalando players para solucionar un bug. Me bajo el archivo de players antiguos, el desinstalador y cuando voy a instalar el player 9.0.115 para IE me salta un error diciendo que natillas. Que estoy intentando instalar un player antiguo y que por motivos de seguridad no me dejan, que instale la última versión desde la web de Adobe.

Como no creo que Adobe hubiera llegado lejos siendo TAN tontos, me voy a Google y encuentro esto:

Safe versions security restrictions when installing Flash Player (Internet Explorer on Windows)

Resulta que para poder hacer estas pruebas no basta con un doble click fuerte, fuerte en el archivo, hay que tirar de línea de comandos para hacer esto:

uninstall_flash_player.exe /clean

Ahora sí, mucho mejor.

Nah, para que no perdáis el tiempo con estas nuestras cositas del día a día!

Adobe sigue dando pasitos en la buena dirección. Como (casi) todos sabréis, el formato de los archivos fla es binario y propietario. Eso quiere decir que la única empresa en condiciones de crearlos es Adobe. Los hay por ahí que se las han maravilleado para darle la vuelta y ofrecer solución al tan demandado: “se me han perdido los fla, sólo tengo los swf, ¿puedo sacarlos de ahí?“, pero son los menos y nunca te puedes fiar de no haber perdido información.

El caso es que todo parece indicar que la nueva versión del IDE de Flash va a manejar un nuevo formato de archivo llamado XFL, que no es más que un zip con los recursos y meta-información en XML.

Esto como siempre a la mayoría de la gente probablemente se la bufe, pero a la aldea de irreductibles galos (comunidad Open Source) le va a venir muy bien. Por ejemplo, cualquiera con ganas y tiempo podría crear un IDE de Flash para Linux totalmente compatible con el oficial.

También se podría crear un IDE de Flash on-line, un IDE de Flash en Flash. Possibilities are endless, que dicen por aquí.

¿Y por qué querría Adobe abrir la lata de esa forma? Como comenta Zguillez en Cristalab, la respuesta se llama Silverlight:

[Perdón Freddie por robarte comentarios]

mcapu:

No veo inteligente la aparción de un SDK para Flash, incluso este cambio de formato. Pasar a este significaría que aparecerían montones de aplicaciones capaces de generar swf a partir de la nada. ¿Quién se gastaría entonces el dinero de Flash?

Zguillez:

La pregunta no es esa.. la pregunta es: Habiendo montones de aplicaciones libres capaces de generar aplicaciones para Flash Player ¿Quién querría desarrollar para Silverlight?

Y es que la sombra de MS es laaaarga. Silverlight puede que no sea lo mejor de lo mejor a día de hoy pero MS invierte a largo plazo. Y tiene mucha pasta para invertir. Ya he comentado más de una vez que Adobe NO tiene la fuerza bruta que tiene MS para distribuir el player de Flash, así que lo mejor que puede hacer es salir del lado oscuro y usar La Fuerza en su favor. Y La Fuerza claramente vuelve a ser la comunidad Open Source. Sin ir más lejos la última versión de Debian aconseja explícitamente NO usar el player de Flash y utilizar GNash. En el OLPC también viene GNash instalado por defecto, todo por problema de licencias. Cuánto más abran sus formatos y herramientas, más posibilidades de luchar contra MS tendrán.

Más información en el blog de Moock y John Nack.

Y para terminar, este comentario en el blog de John Nack:

Ahhh, so what you’re saying is that Adobe is going to create something like Swfmill? ;)

Primero vino MTASC (compilador por línea de comandos) y luego vino el SDK de Flex (compilador por línea de comandos). Vino SWFMill (xml > swf) ahora viene XFL….

Open Source rulez :)

Yuju!

Me acabo de enterar en ASNativos de que Adobe está perpetrando una nueva actualización de la política de seguridad del player: Preparing for the Flash Player 9 April 2008 Security Update.

La actualización no es compatible hacia atrás y te afectará en los siguientes casos:

* You use sockets or XMLSockets, regardless of the domain to which you are connecting
* You use addRequestHeader or URLRequest.requestHeaders in any network API call when sending or loading data cross-domain or You provide access to content on remote domains as a web service provider
* You have SWFs that are exported for Flash Player 7 (SWF7) or earlier that communicate with the hosting HTML by any means
* You use “javascript:” through network APIs to communicate outside a SWF

Y digo yo que aunque es buena idea que Adobe avise con “tiempo” (la nota es del 10 de Marzo, 20 días no creo que sean suficientes, pero bueno) de las modificaciones, ¿no deberían habilitar una descarga de la nueva versión del player para desarrolladores? Lo digo porque una cosa es la teoría y otra la práctica…

Pues como comentaba hace poco, el viernes pasado tuvimos un día de testing con Mark, un chico ciego que además de ciego es biólogo con un master pero que no encuentra trabajo de lo suyo ¿Imaginas por qué? Efectivamente, porque es ciego. Pero dejemos eso para otro post.

El caso. Para empezar es increíble ver cómo una persona ciega utiliza JAWS. La velocidad a la que lo tienen configurado parece una broma. Muchas veces le tenía que preguntar “¿Ha dicho esto?” y el se escojonaba “Claro, ¿no lo has oido?”.

Trato de resumir cosas que me sorprendieron y llamaron la atención, aunque algunas pueden parecer obvias. NOTA IMPORTANTE: En ningún caso quiero decir que la realidad de *todos* los ciegos sea lo que cuento, estas observaciones vienen de un solo día de testing con una sola persona. El equipo era WinXP SP2, JAWS 9, Flash 9.0.115 (importante el 115 ya esta versión trae importantes mejoras con respecto a lectores de pantalla). Dicho queda.

- Para un ciego las webs o aplicaciones no tienen izquierda y derecha, son “verticales”. Es decir, para ellos lo importante es el orden en que los enlaces son leídos. Los primeros estan “arriba”, los últimos “abajo”.

- Hacen una pasada general por todos los enlaces y luego se van a lo que le interesa. Tiene todo el sentido del mundo, lo mismo que nosotros de un vistazo escaneamos una página y luego vamos al enlace o texto que nos interesa, ellos de un “oidazo” escanean la página y luego saltan donde les interesa.

- Por lo menos Mark no utiliza mucho atajos de teclado especiales, utiliza más la “fuerza bruta”. Quicir, va haciendo click en “siguiente enlace” a todo lo que da de velocidad y consigue levantarte dolor de cabeza casi instantáneamente.

- Parece útil que las aplicaciones tengan instrucciones específicas para lectores de pantalla. Esto lo haremos poniendo en pantalla un objeto con el primer tabIndex y añadiéndole las instrucciones a través de _accProps. Interesante el trabajo de optimización que hace JAWS, similar a lo que hacen los navegadores cuando hay wmode. JAWS sólo lee un objeto si es visible en la pantalla. Es decir, si le pones _alpha=0, lo sacas de la pantalla con _x=-1000 o simplemente está tapado con otro objeto, JAWS NO lo lee. Nosotros sólo lo mostraremos si un lector de pantalla está presente (cosa que se comprueba con Accessibility.isActive());

- Como ya vi en mis pruebas iniciales JAWS “lía” los tabIndexes de Flash. No pasa mucho, pero de vez en cuando le da por empezar por ejemplo por el tabIndex 3 en lugar de por el primero.

- Mark utiliza GMail sin ningún problema. El cabroncete dice que si no quiere oir la publicidad entra con JAWS 7 lo que fuerza la versión “basic HTML” de GMail. Dejo para otro post comentar la pasta que están perdiendo los anunciantes por no hacer publicidad accesible.

Seguro que me dejo millones de cosas de las que me acordaré cuando editemos los vídeos. Tenemos casi todo grabado, incluida una mini-mesa redonda de charleta con él, pero no puedo asegurar que se vaya a publicar. Yo voy a tratar de que me den tiempo para escribir algo y editar los vídeos, pero como siempre vamos jodidos de tiempo. Ya os diré algo si eso.

Ea!

De lo que se entera uno. Resulta que la opción -main de MTASC NO acepta parámetros. Es decir, esto:

mtasc -main Wadus.as

es lo mismo que esto:

mtasc Wadus.as -main

Porque -main no acepta parámetros. Esto puede parecer nimio, pero genera un problemita y es que en todo tu código, sólo puede haber un método público estático “main”. Posibilidades de que esto te pase? Ayer mismo a mi.

Si a alguien le consuela, que no creo, el compilador de haXe sí que admite como parámetro la clase que funciona de “lanzadera” con su método “main”.

Ea, dicho queda.

Ando probando una de las últimas versiones de JAWS (9.0.519) en aplicaciones Flash. Como siempre, buenas y malas noticias.

Las buenas noticias son que utilizando la propiedad _accProps de un MovieClip puedes especificar dinámicamente y por código lo que el lector de pantalla leerá cuando le llegue el foco a ese MovieClip.

[Aquí como siempre Adobe haciendo chapuzas de las suyas. No hay un objeto AccProps, si miras la referencia recomienda crear un objeto anónimo, lo cual apesta porque no tienes validación de tipos. Pero es que _accProps ni siquiera aparece en las propiedades de MovieClip sino como propiedad global, por lo menos para AS2.]

Una vez creado la propiedad _accProps, nos vamos al navegador y comprobamos. En general funciona más o menos de forma esperada tanto en IE como en FF (esto último sólo con la version 9.0.115 del player que es la que añade soporte para MSAA en navegadores alternativos). Es decir, JAWS lee con su metálica voz lo que le dices. ¡Yuju! Hasta aquí las buenas noticias.

Las malas noticias son:

- Bastantes inconsistencias con el orden de tabulación. Es decir, sin JAWS activado la tabulación dentro de Flash funciona como un reloj. Con JAWS activado, algunas veces de forma aleatoria empieza por la que le viene en gana. Tanto IE como FF.

- JAWS interfiere en la captura de ciertas teclas. Una de las aplicaciones captura Key.onKeyDown y si es ENTER ejecuta unas acciones. Sin JAWS perfecto, con JAWS no llega el evento a Flash. Pero es que no sólo pasa con ENTER, pasa con más atajos de teclado de JAWS, por ejemplo “r” (ir a radio buttons) o “a” (ir a “anchors”). Aún no sé cómo voy a maravillearmelas para saltarme esto.

Una cosa que mola es que podemos pasar instrucciones específicas a los usuarios que usan un lector de pantalla añadiendo _accProps a _root. Así en el momento que le llega el foco, lee esas instrucciones específicas que pueden diferir bastante de las instrucciones para una persona con visión. La otra forma de hacerlo sería con un div oculto en HTML, lo cual mola menos.

De todas formas lo mejor con diferencia es que en mi curro han contratado a tiempo parcial a un chico ciego para que nos ayude con temas de accesibilidad. Estoy intentando que venga a la oficina un día para hacer user testing con él. Pero testing en plan:

Prueba esto a ver qué tal. ¿Mal? Espera, que recompilo haciendo esto otro y vuelve a probar.

Tener a un ciego en plantilla es de un valor INCALCULABLE para hacer testing REAL. Una cosa es cómo yo utilizo JAWS (al que odio porque me da dolor de cabeza) y otra muy distinta cómo lo hace un usuario avanzado.

En fin, ya os contaré cómo va la cosa y si tengo tiempo haré un artículo algo más extenso. Si alguien tiene preguntas específicas para Mark (que así se llama), que me mande un mail. Si alguien sabe donde hay información *actual* sobre lectores de pantalla y Flash, que me lo cuente también, por favor.

Una vez que tengamos JAWS controlado, intentaremos pasar la prueba con Windows Eyes.

Salud!

Seguimos con los títulos laaaaargos para los posts.

Algunas de las charlas y ponencias de Flash on the Beach me han dado alguna idea para el tema de la accesibilidad en Flash. Dando por descontado que algún día wmode y SeamlessTabbing serán solucionados, qué os parece esto:

Acceso a las preferencias de accesibilidad del sistema

Uno de los principales problemas de Flash es que no reacciona a las preferencias de accesibilidad que el usuario ha puesto en su máquina. Si por ejemplo ha cambiado la letra a gigante, en Flash no hay forma de saberlo.

Sería muy interesante que esas preferencias se ofrecieran en modo sólo lectura mediante un objeto. Cosas como tamaño y color de las fuentes, color de fondo preferido… tampoco me sé todas las opciones, especialmente porque cambian entre distintos sistemas operativos.

Si por la razón que fuera el player dentro del navegador no pudiera acceder a esto, estaría bien que al menos dentro de AIR sí que fuera posible.

Formato de texto por defecto

¿A quién le gusta la Times New Roman 12 que por defecto usa el navegador o Flash? A nadie. ¿No sería bueno que si el programador no define ningún estilo concreto el formato de texto fuera por defecto el que el usuario tiene definido para su sistema? Esta medida es imposible que moleste a nadie, porque quien quiera puede seguir aplicando estilos como hasta ahora, pero quien quiera “respetar” las opciones del usuario, lo tendría simple, no aplicar ningún formato. Igual es algo que también se podría aplicar al color de fondo, no sé, habría que pensarlo con ciudado.

A mi estas 2 cosas me parecen muy sencillas de agregar por parte de Adobe y no creo que dependa de nadie externo para realizarlas. ¿Qué os parece?

Estas cosas pasan hasta en las mejores familias. Un día llegas a la oficina y te dicen que tu aplicación va sobre un servidor Windows. ¡Maldición! Pero bueno, tú piensas: “¡eh! Si yo hago Flash, a mi casi me da igual quién sirva los archivos”. Bueno, pues casi. En Windows IIS necesitas autorizar específicamente que quieres servir archivos FLV:

Windows 2003 Server does not stream FLV videos

Lo digo porque habrá que habilitar los nuevos formatos de vídeo:

New File Extensions and MIME Types

¡Salud!