Por si alguien a estas alturas no lo sabe, Los Talleres de verano Subflash es un evento que se realiza anualmente desde el 2003 en distintas ciudades de España. Como eje central hay conferencias de temática muy variada, y a partir de ahí se realizan todo tipos de actividades, desde partidas de ajedrez a fiestas por todo lo grande. Decenas de personas de distintos perfiles conviven durante 3 días en un ambiente inmejorable.

Esta edición 2010 ha sido mi primera vez y doy fe que no va a ser la última. Aquí va un visión muy particular de mi experiencia.

Nota: ya aviso que es un post laaaaargo y nada técnico (ni siquiera hay review de las charlas). Básicamente es un post para mí, para releerlo si alguna vez se me olvida todo lo que viví aquí.

 
El viaje

Marcos, uno de los principales motores que mueven Subflash, siempre dice que la aventura no empieza en los talleres, sino en el viaje de ida. Y tiene toda la razón. Así que le mandé un mail a mis amiguitos de Barcelona para que fuéramos juntos. Ahí fue cuando me enteré que ya lo tenían todo organizado y que no contaban conmigo. Por suerte para mí, en la frikineta en la que viajaba el grupo de la tarde les faltaba un sitio y yo llevaba coche, así que al final no les quedó más remedio que “invitarme” a ir con ellos. La expedición de la tarde estaba formada por Xavi, Joan, Elecash, Zguille, Javi (espabila con el twitter), Dani, Alfonso y un servidor.

Salimos to felices el viernes a las 17:30h como si fuéramos al Carrefour del Prat en vez de a Bilbao y no tuviéramos 6 horas por delante. Ya desde el inicio, Joan intentó perderme de vista por todos los medios: calaba el coche y luego salía fundiendo, iba cambiándose del primer al cuarto carril continuamente (la frikineta no tenía intermitentes…), se metía en el carril de salida de la autopista y en el último momento se incorporaba… (estaba claro que a pesar de que yo llevaba a dos de los suyos no tenían problemas en sacrificarlos por tal de librarse de mí). Jugándome la vida en varias ocasiones, conseguí no perderle el rastro. La verdad es que no había visto una conducción como la de Joan desde que estrenaron Mad Max.

Por suerte para mí (otra vez), a los 15 minutos paramos en una gasolinera y allí descubrieron que yo llevaba un TomTom, con lo que me dejaron ir delante y se dedicaron a seguirme. Nuestra vida continuó corriendo peligro, porque gracias a mi terrible interpretación del navegador me salí de la autopista y me metí en una nacional de dos sentidos llena de camiones asesinos. A los de la frikineta no les importó, porque por entonces ya habían acabado con 5 kilos de golosinas y llevaban un subidón de azúcar y de alegría considerable.

Previa parada en una gasolinera de IGay que disparó todo tipo de especulaciones, llegamos a Bilbao a las 12 de la noche, y aunque sólo nos quedaban 4 km para llegar al albergue, el camino era una locura y estuvimos dando vueltas durante una hora por lugares que le hubieran dado miedo al mismísimo Freddy Krueger. Llamamos a la gente del Subflash que ya estaban en el hotel, pero al saber que estábamos perdidos nos ovacionaron y colgaron. También llamamos a la recepción pidiendo ayuda, pero por desgracia habló Dani y se comunicaba con frases para la historia como: “sí, estamos como en una especie de pueblo…” o “a ver, si vamos dirección al mar, ¿dónde estáis?”. También nos colgaron.

 
La primera noche

Como acabamos llegando a la 1, obviamente nos perdimos la keynote de presentación. La mayoría de las personas se encontraban en el hall de la primera planta jugando a póker, charlando, haciendo el friki con sus cacharros o tomando unas birras (algunos lo hacían todo junto). Al ser mi primer Subflash apenas conocía a nadie, y como estaba poco sociable y muy cansado del viaje me retiré pronto a dormir. Por cierto, tuve la suerte de que me tocara en la habitación con Xavi, Joan y Guille, tres programadores de lo mejorcito que he visto.

La verdad es que la primera noche apenas dormí, básicamente por la emoción. No todo los días se comparte habitación con cracks como ellos. Para que os hagáis una idea, es como si coges a un actor de El Internado y lo pones a dormir con Bruce Willis y Michael J. Fox, ahí en gallumbos.

Ellos, en cambio, parece que dormían bastante a gustito.

 
Sábado mañana, las conferencias

Reinaba el buen ambiente en el comedor cuando llegamos a desayunar. Ahí ya empecé a socializarme y a conocer a gente del mundillo. Mola mucho poner cara a personas con la que hablas por internet o que sigues desde hace tiempo: nadie es como te lo imaginas. A ellos les pasaba lo mismo conmigo, y me costó mucho convencerles de que en las fotos no me quito las ojeras con Potoshop, que sólo había dormido poco.

El recinto de las conferencias estaba fuera del hotel, a un par de minutos. Una sala muy acogedora donde 60 y pico personas disfrutamos de la primera charla de la mano de Luis Adrián: Inteligencia Empresarial. Me gustó ver que las conferencias no técnicas tienen también cabida. Luis planteó una charla entretenida y fomentó bastante debate sobre las relaciones personales en el trabajo y cómo enfocar los problemas del día a día. Me gustó especialmente cuando alguien sugirió que de vez en cuando el programador debería liderar la cuenta. No pocos diseñadores temblaron ante tal idea.

Continuaron Joan y Andrés Cayón con Actionscript vs Javascript en Air 2. Fue una charla muy divertida, donde Joan jugaba el papel de cool con su Flex y Andrés de “el vecino que hace webs”, como el se definió xD Al final los dos conseguían los mismos resultados.

 
Sábado tarde, la conferencia

Pues no lo había comentado todavía pero yo di una de las charlas (fue uno de los requisitos para que Marcos me dejara asistir). Fue a las 16h, la hora perfecta para ir a echarse una siesta. Pero la verdad es que la gente se portó muy bien, vinieron todos y estuvieron muy atentos y participativos en la ronda de preguntas. Aunque había estado bastante nervioso durante todo el día por tener que hablar en público, la verdad es que me sentí muy cómodo y me gustó mucho la experiencia.

Al final, Xavi salió en representación de Adobe para preguntarnos qué nos gustaría ver en el futuro de la plataforma Flash y hubo un intercambio de opiniones animado. Bien por Adobe que nos escucha. Si yo fuera el Señor Adobe tendría muy en cuenta todo lo que se lo curra Xavi.

Eso sí, al llegar a la habitación le cambié el listado de peticiones por uno mío, con sugerencias como españolizar los nombre de los productos (Flex Grijander en vez de Gumbo, Flash Player Candemor en vez de Astro) o sustituir el canvas blanco de todos los programas por una foto de una gato. Además, el usuario podría enviar a Adobe fotos de sus gatos, compartir su Dreamweaver en Facebook y estas mandangas sociales. Ésta sugerencia creo que tiene posibilidades reales.

 
Sábado noche, la fiesssssta

Algunos valientes ya hicieron una avanzadilla por la tarde a la ciudad y el resto bajamos por la noche después de descansar un poco y cenar en el hotel. Hay que decir que eran las Fiestas Grandes de Bilbao, y como los de Bilbao lo hacen todo por diez, pues imaginaos el fiestón.

Por lo que me contaron, el resto de ediciones de Subflash no se hicieron tan cerca de una gran ciudad, así que fue una gran suerte estar al ladito y encima en feria mayor, porque nos lo pasamos increíblemente bien. Toda la ciudad era como una discoteca gigante, y ver a miles de personas en la calle charlando, bebiendo, riéndose y bailando no tiene precio. Además, todos los subflasheros llevábamos unas ganas de fiesta tremendas (claro, como estamos todo el año encerrados picando teclas…) y se notó: lo dimos todo hasta las tantas (síííí). La gente de Subflash es tan cojonuda que te sentías como si los conocieses de toda la vida.

Demasiadas anécdotas para explicar aquí, pero seguro que por Facebook, Twitter y demás irá apareciendo material gráfico que dicen más que mil palabras. ¡Atento peña!

Por cierto, para quién le interese, esta noche pude dormir. Xavi y yo tuvimos que hacerle unos ajustillos a Joan y, a partir de ahí, como la seda. Supongo que la cantidad de alcohol ingerida ayudó también algo.

 
Domingo mañana, las conferencias, foto oficial, comida y regreso

Contando que la gente fue llegando al hotel desde la 1 hasta las 6 de la mañana, en una diversidad de estados considerable, fue casi milagroso que estuviéramos el 98% de gente en la conferencia de las 10 de la mañana. Eso sí, esta vez sin desayuno y con la marca de la almohada pegada.

La primera conferencia corrió a cargo de Marc Palau, Lesmes y Mario (¿twitter?), y llevaba por titulo “Internet, hasta dónde llegan tus datos“. Contando que Lesmes no apareció hasta el final y los primeros minutos de Marc, yo no podía dejar de pensar “Chicos, hasta dónde llega vuestra resaca”. La verdad es que fuera coñas, fue una charla muy divertida con el hilo conductor de Marc, llena de imágenes cachondas y con el apoyo de Mario en los comentarios más técnicos. Al final de la conferencia, Lesmes dejó constancia de sus conocimientos contestando todas las preguntas.

Acto seguido, Raúl Jiménez y Marcos nos deleitaron con Froyo Bolsón, tu nuevo amiguito.  Los pobres sacrificaron la mayoría horas de diversión de Subflash para poder acabar un ejemplo para quitarse el sombrero: una partida en tiempo real al Pong jugando cada uno con su Nexus. Además, cualquiera con un móvil o un ordenador se podía conectar al servidor para seguir la partida en su pantalla. Nos dejaron muchas otras joyas en forma de tips y de conversación. Ejemplo de sacrificio y entrega donde los haya.

Y ya para acabar, los patrocinadores, entre cachondeo y globos, nos obsequiaron con montones de regalos: camisetas, libros, juegos, packs de hosting, suites de CS5… Tremendamente generosos. Desde aquí, gracias a todos.

Y como no, la foto oficial del 2010, una comida para ir cerrando conversaciones y despedida emotiva con frases tipo “nunca te olvidaré” y decenas de abrazos.

Volvimos a Barcelona el mismo equipo que salimos, cansados, contentos, y hablando todo el rato de lo bien que nos lo habíamos pasado.

 
Resumen

Y después de este tochazo, resumen rápido: Subflash es el mejor festival que he visto en mi vida. A pesar del nivelazo de las conferencias, son una excusa. Lo importante es la calidad humana y ese sentimiento de estar 2 o 3 días lejos de cualquier preocupación, riendo a todas horas y ganando horas de vida.

Y si además te gusta la programación entorno a la plataforma Flash, estar rodeado de tanto crack, poder hablar con ellos de tú a tú y frikear un rato, no es un mal aliciente ;)

Me ha encantado poneros cara, conocer a todas esas personas que sigo y a aquellas que alguna vez han pasado por aquí. Elad, en su despedida, me comentó todo lo que se decía de mí debido a que casi nadie me conocía ni me había visto: llops en verdad no existe, llops es un snippet de código, los de barcelona no llegan porque llops se los ha comido… xDDD Creo que esto ya está solucionado ;)

Un abrazo gigante a todos los subflasheros y millones de gracias por todos estos momentos. ¡Nos vemos en Subflash 2011!

Nota: perdón si he confundido algún nombre o twitter, y siento no nombraros a todos. Cualquier rectificación es bienvenida.

Nadie ha comentado, se el primero | Permalink | Add to del.icio.us

LLops Blog, 2010

Empezando por las conclusiones, creo que fue un evento más que positivo. Más allá de las conferencias, es tan enriquecedor conocer a gente del sector, empaparte de las ideas de otros, poder hacer networking o simplemente ponerle cara a aquellas personas de nuestro mundillo, que el mero hecho de estar allí valió la pena.

Puntos a destacar:

• El ambiente y la gente.
• La sala de actos de la UPC, chulísima.
• La diversidad de las conferencias, que plasmó perfectamente la idea de que la Plataforma Flash abarca multitud de ámbitos.
• La ronda de preguntas/conversación en la sesión de Enrique-Xavi. No todos los días puedes “masacrar” a preguntas a gente de Adobe, y encima te ponen buena cara. Incluso hubo uno que les pidió licencias de Flash CS5!!! xD

Como puntos a mejorar (mi opinión, claro):

• ¿Demasiadas conferencias? Quizá 8 charlas fueron excesivas, nos comimos el tiempo y seguramente la gente hubiera podido participar más.
• La asistencia, muy por debajo de lo esperado. Apuntar que no fue culpa de la organización, ya que se inscribieron casi 500 personas. Aún así, para futuras ediciones será interesante avisar con más antelación aún, e incluso hacer una especie de sondeo para mirar fechas. Aunque estoy de acuerdo con Xavi: parece que es imposible acertar con el día/hora, cuando no es A es B :)
• Hubiera estado muy bien una “mesa redonda” para comentar temas de actualidad y contrastar opiniones. Como comentaba, en la charla final se dio algo más de conversación y fue muy positivo.

 
Conferencias

Natalia Rojas, de Cuatic. Cuatic es una empresa especializada en instalaciones interactivas y utilizan Flash en la mayoría de sus proyectos para las interfaces. Natalia habló de proyectos propios y de otras empresas en ámbitos tan diversos como proyecciones en suelos y paredes, fachadas digitales o realidad aumentada. Tecnologías en expansión que cada vez veremos más en nuestro día a día.

Andrés Ortiz y Carlos Ordóñez de Bestiario. Intentándolo definir de una manera sencilla, Bestiario es un estudio de visualización de datos, cogen información y la representan. Es importante recalcar que el estudio está formado por arquitectos, matemáticos, artistas… y eso se nota en la complejidad de los proyectos que presentaron. Fue una de las charlas más impactantes por ese aspecto, porque realmente hay muy poca gente que haga estas cosas, pero también es verdad que sus trabajos son “densos”, y no para todos los públicos. Te quedas con la sensación de “No sé muy bien qué me están explicando pero qué jodido se ve…” :) Es una suerte que apuesten por Flash para toda la parte visual y sus atípicas navegaciones.

Después de esta charla subió gente del público a mostrar algunos proyectos. Siento decir que estaba preparando el portátil para mi charla y no me quedé con la intervención de la primera persona. Sí que vi la presentación de SocialPoint, una empresa que realiza aplicaciones y juegos para redes sociales. Bastante simpáticos los juegos que presentaron.

Dani Llops. Aquí intervine yo. Haré un resumen un poco más extenso al final del post (sino lo hago en mi blog… xD).

Sara Mayoral, de DoubleYou. Sara presentó en primer lugar una pieza para Cacique y nos contó cosas sobre el desarrollo. Se nota que hay un gran trabajo detrás y es una muy buena muestra del potencial de Flash. También habló bastante de realidad aumentada y de lo que están haciendo en DoubleYou en este ámbito. Me dejó una sensación ambivalente, porque comentaba que estaban haciendo cosas diferenciales en este campo pero tampoco pudo mostrar nada. Estaremos atentos.

Joseba Alonso, de Refr3sh. Joseba hizo una charla bastante pragmática: habló de elegir editores de código, frameworks que faciliten las tareas, programación procedural y OOP… Me gustó de su conferencia que tenía un fin, era didáctica. Estoy seguro que si había alguien que se estaba acercando al mundillo Flash le sirvió de mucho.

Comentar que Joseba mostró por un encima un proyecto que debía presentar más tarde Chema, y que no pudo hacer finalmente por falta de tiempo. Se trata de una aplicación AIR llamada Reforest para crear estructuras de proyectos a partir de un xml configurable. Es una app cuidada, bien diseña y muy útil. Os recomiendo que le echéis un vistazo ;)

Joan Llenas, de Codeoscopic. Seguramente la persona que más se “curró” su conferencia, ya que no se limitó a mostrar trabajos, sino que estuvo estudiando y jugando con las nuevas APIs del player 10 para generar audio dinámicamente. Fue bastante técnica, tuvo un punto muy friki cuando empezó a poner el “ruido” de las ondas, y acabó con una pequeña herramienta que realmente generaba música. Creo que todo el mundo supo valorar y reconocer su esfuerzo.

Enrique Duvós y Xavi Beumala, de Adobe. Enrique se centró en el Player 10.1 y Flash CS5. Mostró ejemplos corriendo en un Nexus One, exportación de Flash para iPhone y también hizo énfasis en las mejoras del player en rendimiento y consumo de memoria. Una buena demostración fue una aplicación Flex corriendo en móvil que parseaba 20.000 registros en pocos segundos (creo que no me equivoco con los números). Xavi nos sorprendió con algunos ejemplos en AIR 2 tales como grabación en tiempo real de audio/video, hacer un efecto de flipbook con el escritorio o controlar el mouse de su ordenador con el iPhone (ahí es nada). Cuando cuelgue sus demos supongo que ya explicará los trucos ;). Y como ya he comentado, también nos obsequiaron con su opinión sobre diversos temas de la Plataforma Flash.

 
Mi conferencia

La idea era compartir mis opiniones y experiencias como programador Flash. Mostré bastantes trabajos (propios y ajenos), pero ninguno era “gratuito”: intenté coger aquellos que tenían una moraleja detrás y que me ayudaban a transmitir una idea. Aunque lo llevaba todo bien estructurado, al principio estuve algo nervioso y creo que me faltó llevar mejor los tiempos de la charla y seguramente algunas ideas no las transmití como me hubiera gustado. Como parte más positiva, creo que tuvo unos cuantos momentos divertidos y se hizo amena.

He hecho una presentación con las diapositivas para ver online: http://llops.com/eventos/2010/flashday

Como los slides por sí solos no dicen mucho, intento apoyarlos con una explicación de los bloques principales:

• Introducción: presentación; programador Flash de la vieja escuela; envidia sana de tecnologías en auge como Flex o Flash Mobile; encantado de iniciativas como FlashDay para que Flash coja protagonismo.
• Publicidad y Flash: Flash es la herramienta para conectar emocionalmente con los usuarios; explotar la parte más experiencial y emocional de Flash; el programador interactivo tiene mucho que aportar.
• Experimentar: siempre hay que experimentar, abrir camino y proponer; no ir siempre a remolque de lo que hacen otros; no importa si el programador es de agencia, de pequeño estudio o freelance, se aplica a todos.
• Experimentos con pixels: un area donde he invertido muchas horas. Mostré mis primeros experimentos, lo más tonto que tenía, para transmitir lo importante que es empezar desde abajo y entender lo que se estudia. Ejemplos más logrados: http://llops.com/blog/tag/pixel/
• Complejidad != espectacularidad: no frustrarse buscando siempre lo más difícil; la idea prevalece sobre la técnica; ejemplo de algo fácil que me “llenó” más que experimentos más complejos: Gomets.
• Inspiración: no centrarse únicamente en el trabajo de los demás; coger lo que hacemos en el día a día y potenciarlo. Ejemplo de un banner del que sale un experimento.
• Experimentar en proyectos reales: a veces hay suerte y en el día a día podemos invertir tiempo probando y experimentado. Aprovecharlo. Ejemplo: Las plantas de Ikea.
• Trabajos inspiracionales: El banco de la imaginación; Labuat, ejemplo de algo “hecho en casa” que da la vuelta al mundo.
• Trabajos aspiracionales: tres obras de la agencia de Yugo Nakamura: FontPark, FPM, Muji Rhythm. Más allá de la exquisitez de las piezas, los trabajos de Yugop se viralizan increíblemente, ayudan a la marca y cumplen con creces las expectativas de los clientes, “a pesar” de estar en Flash. Los detractores de Flash deberían entender el concepto de “cumplir objetivos”, y que internet no son sólo blogs y webs indexables.
• Disfrutar: los que trabajamos con la Plataforma Flash somos afortunados, cada día tenemos la posibilidad de divertirnos creando; hay que disfrutar siempre.
• Cierre: A día de hoy, Flash es insustituible en muchos aspectos y, le pese a quien le pese, está más vivo que nunca.

Y hasta aquí el resumen, que casi ha sido más largo que el evento en sí ¬¬. Añadir que para algunos valientes el FlashDay se convirtió en el FlashNight, pero como de esto no se puede hacer resumen, te recomiendo que el próximo no te lo pierdas ;)

¡Hasta la próxima!

 
Dejo para descargar:

Fotos del eventos. Gracias a Adobe por facilitarme las fotos. He recopilado algunas y las he bajado de resolución.

Mi presentación

3 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2010

La mejor forma de resumir en qué consiste este evento es recopilar un par de definiciones del propio site:

FlashDay es un evento con carácter 100% inspiracional y participativo alrededor de la plataforma Flash.

FlashDay es un entorno para entrar en contacto con gente con las mismas inquietudes, un entorno en el que compartir y mostrar todos esos proyectos en los que andas trabajando (…)

Como punto de partida habrá una serie de conferencias de gente tan conocida como Xavi Beumala, Joseba Alonso o Joan Garnet, por poner algunos ejemplos (ahí es nada…). Y para bajar un poco el nivel, ahí estaré yo también dando una charla :p

Mi charla no girará sobre un tema específico ni ningún aspecto técnico, simplemente será un repaso sobre programación Flash, experimentación y algunos trabajos de agencia. Intentaré hacerlo ameno, prometido.

Si alguno de los que leéis habitualmente este blog vais a estar por ahí, me encantará que os acerquéis a saludar, y así os pongo cara :)

Nos vemos en un par de días!

10 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2010

 

Virtualización

Como no hay magia que valga, lo primero es hacerse con un programa de virtualización para instalar Windows. Los dos más conocidos son VMware Fusion y Parallels Desktop.

Cuando me pasé a Mac estuve leyendo bastante sobre ambos. Al final me acabó convenciendo más el primero, así que me compré una licencia de Fusion. Sin entrar en comparaciones, Fusion arranca bastante rápido, soporta copy/paste y drag&drop entre sistemas operativos, puedes acceder a las mismas carpetas desde ambos lados y tiene alguna otra característica interesante que ahora veremos.

No explicaré el proceso de instalación porque no es muy complicado y hay mucha información en la red, únicamente detallaré mi configuración por si sirve de ayuda.

 

Configuración de Windows y VMware

Yo tengo instalado un Windows 7 de 32 bits, FlashDevelop y poco más. Obviamente, si se necesitan más programas pues no pasa nada, pero es importante no tener procesos que se inicien en el arranque consumiendo memoria inútilmente, así que mejor instalar sólo lo imprescindible. Desaconsejo totalmente antivirus, ya que me parece muy difícil infectarse sin instalaciones ni navegación. Si se es muy desconfiado en este aspecto, mejor desactivar internet en Windows.

Importante desactivar el tema Aero, que para nuestro caso es absurdo. Yo utilizo el tema Windows 7 Basic y queda más que bonito. Y si no quieres dedicar ni un recurso a la estética, en "Herramientas de rendimiento", "Ajustar efectos visuales", activas "Mejor rendimiento" y te lo deja pelado.

En cuanto a la configuración de VMware, lo más relevante:

• Compartir: útil si vas a trabajar en Windows, ya que podrás acceder a cualquier directorio de Snow Leopard que añadas.
• Aplicaciones: aquí podemos añadir un acceso directo de FlashDevelop al Dock.
• Procesador: 1 núcleo. Esto quiere decir que el sistema virtual utilizará un nucleo del procesador, pero no de manera exclusiva. Nuestro Mac continuará utilizando los dos.
• Memoria: 1024 MB. En este caso la memoria sí que se reserva entera, es decir, que cuando Windows esté corriendo tendrá 1 giga reservado que no podrá utilizar Snow Leopard. Con Aero desactivado, para correr Windows y FD hay más que de sobras, así que no os preocupe darle "un poquito más" de este mínimo.
• Pantalla: sino tenéis dependencia de DirectX 9 (para juegos) ni utilizáis Aero, desactivar la opción "Acelerar Gráficos 3D".
• Disco duro: yo tengo una partición de 40 gigas, pero realmente bastaría con el espacio de Windows y poco más. Siempre es interesante cubrirse un poco para la memoria virtual, por si tomas muchos snapshots, porque al final siempre se acaban instalando cosas...

Una de las ventajas de virtualizar es que si la máquina no está corriendo, se puede cambiar toda la configuración, así que no tengáis miedo de ir probando configuraciones hasta que os sintáis cómodos. Pero si no queréis perder tiempo, con lo ya comentado, en un MacBook Pro Core 2 Duo de 2'66 y 4 gigas de ram, corriendo Windows 7 con FlashDevelop, más Flash, Chrome, Safari, Spotify y unos cuantos programas "menores" más, el ordenador "vuela" :)

Y un último apunte: cuando no se trabaje con la máquina virtual lo más cómodo y rápido es suspenderla, no apagarla, recuperando todos nuestros recursos y pudiendo volver luego en segundos.

 

Modo Unity

Una de las cosas más agradables y útiles de Fusion es su vista "Unity". En este modo, el escritorio de Windows desaparece y las aplicaciones aparecen como una ventana más de Mac. Perfecto, ¿no?

Y como comentaba antes, hacer un drag&drop de archivos, un copy&paste o cualquier típica operación entre programas funciona a la perfección. Un gran paso para sentirnos como si estuviéramos en un único sistema.

 

En busca del workflow perfecto

A pesar de que así está todo bastante integrado, falta una cosa básica: poder ejecutar películas en Flash desde FlashDevelop. Al principio pensé que mucha gente habría buscado una solución a esto y no sería difícil. No estaba equivocado ni nada...

Parece ser que en Parallels se puede instalar una herramienta llamada "Shared Applications" que te permite mapear programas, con lo que se puede configurar en FD la ruta a Flash.app (también vi que está lejos de ser perfecto y que muchísima gente tenía problemas). Desgraciadamente, en Fusion no existe nada similar.

Así que me puse a darle vueltas a la cabeza hasta encontrar un camino.

 

QuickSilver

QuickSilver es un programa que mucha gente del mundo Mac considera imprescindible y que sirve para lanzar aplicaciones rápidamente (esta es la utilidad más básica, realmente puede hacer mil cosas). Por ejemplo, yo para ejecutar Flash CS4 no lo busco en Aplicaciones ni el Dock, simplemente hago cmd+space, tecleo Fl y enter. Al principio puede parecer tonto, pero cuando te acostumbras no hay vuelta atrás.

Me acordé que el programa tiene un apartado llamado "Triggers" e indagé un poco. Un trigger permite asociar una acción (abrir una aplicación, correr un script, etc) a una combinación de teclas. Pensé que si podía correr un script funcionaría también con un jsfl... ¡y bingo!.

Así que abrimos Flash, creamos un nuevo archivo del tipo "Flash Javascript File" y escribimos la siguiente linea:

Lo guardamos en el escritorio como testmovie.jsfl

Ahora abrimos QuickSilver, vamos a "Preferences" y activamos la opción "Enable advances features" (no estoy 100% seguro que sea imprescindible, pero por si acaso). Después vamos al menú "Triggers", añadimos uno nuevo (parte inferior, en el +, "HotKey"), y nos sale una nueva ventanita. En "Select an item", sólo hace falta empezar a teclear el nombre de nuestro archivo y QuickSilver lo encontrará y nos pondrá por defecto la "Action" de "Open". Guardamos.

Nota: si al empezar a escribir no nos detecta el script seguramente sea porque no lo tiene indexado todavía. En el menú, junto a Triggers, hay una opción llamada "Catalog". Buscamos nuestra ubicación, en este caso Desktop, la seleccionamos y en la parte inferior, clicamos en el icono de refrescar (Rescan Source). Debería aumentar el número de elementos indexados. Ahora seguro que ya encuentra nuestro archivo.

Nota: QuickSilver no indexa todo el disco duro, sino que tiene unos directorios por defecto (el escritorio es uno de ellos). Si prefieres agrupar tus scripts en otro directorio tendrás que incluirlo a mano. Esto se hace también en "Catalog", en "Custom". Ahí añadimos un archivo o carpeta. Atención que si añadimos una carpeta, en el nuevo submenú que aparece, hay que indicar en "Include contents" que los queremos todos, sino coge el directorio pero no su contenido. Lo seleccionamos y volvemos a refrescar para que lo indexe.

Ahora que tenemos nuestro trigger, sólo falta asignarle una tecla. Click sobre la palabra "Hot Key" (o en la "i" del menú inferior, "Trigger Info"), "Edit" y ponemos nuestro atajo. En mi caso he elegido "alt+z". Para activar el trigger, desactivar-activar una vez el check de la izquierda.

¡Voilá, ahora ya podemos ejecutar en cualquier momento nuestra película desde FlashDevelop! (realmente desde cualquier sitio :p )

 

Guardar y compilar

Aunque ahora el flujo es bastante bueno, todavía falta que con el mismo comando se pueda guardar la clase que se está modificando y luego saltar a Flash para compilar. Sino eres tan purista-pesado-friki como yo, con la opción anterior es suficiente; si lo eres, a seguir leyendo.

La primera idea era buscar un script que pudiera guardar en FlashDevelop e intentar correrlo luego con QuickSilver, de la misma manera que hemos hecho con el jsfl. Lo primero, no encontré la forma de generar dicho script, y lo segundo, en QuickSilver con un único comando no puedes ejecutar dos opciones (realmente si he visto una forma, pero no entendí ni la mitad).

Leyendo leyendo fui a parar a un post de un tío que manipulaba Spotify vía AppleScript, así que ahí vi otro camino: crear un applescript que se comunicara con FlashDevelop y ejecutarlo desde QuickSilver también. Como seguía encontrando el escollo de "un comando, dos scripts", primero me puse a buscar la forma de poder hacer un "TestMovie" con AppleScript también, para tenerlo todo en un único archivo. Así que descarté el jsfl inicial y adapté el código del Spotify a Flash CS4.

Mac Os cuenta con "Apple Script Editor", que va de coña para ir probando los scripts. Lo abrimos, creamos un nuevo fichero y copiamos este código:

Este código pone en primer plano Flash o lo abre si no lo está, y simula un clic en la opción "Test Movie". La traducción del script es esta:

menu item "Test Movie" of menu "Control" of menu bar item "Control" of menu bar 1 of application process "Adobe Flash CS4" of application "System Events"

Increíble, ¿no?

Muy importante: es probable que el script os arroja un error similar a este "El acceso a los dispositivos de ayuda está desactivado". Esto pasa porque el comando "System Events" no puede operar. Para que funcione, hay que ir a "Preferencias del sistema" (sí, de Mac), "Acceso Universal", y abajo activar "Activar Acceso para dispositivos de ayuda".

Pausa para desahogo: ¿quién carajo sabe esto? ¿Por qué en todos los tutos que vi sobre AppleScript no lo comentan? Lo encontré tras un buen rato de búsqueda en un foro de frikis de World of Warcraft que lo utilizaban para configurarse nosequé del juego... En fin, para llorar.

Nota: Otra cosa que descubrí por la vía dolorosa es que los separadores del menú cuentan como 1, de ahí que "Test Movie" corresponda al número 8 aunque esté en la posición 6. Ojo con esto si intentais manipular cualquier otro comando.

Cuando por fin pude ejecutar el script y ver que funcionaba, fue fácil pensar que para FlashDevelop sería lo mismo. Así que me dispuse a probarlo. Una cosa que mola mucho del editor de AppleScript que si pones el nombre de un programa que no reconoce (yo por ejemplo ponía -tell application "FlashDevelop" to activate-), al ejecutar te pregunta dónde está y te ofrece la lista de programas (¡incluso los de Windows!) para resolver el nombre correcto:

Así que puse la ruta para llegar hasta el menú "File > Save" en FD y corrí el script, pero no funcionaba por un error de base que tarde un poco en detectar:

Efectivamente, el menú de FlashDevelop cuando tiene el foco no es el del programa de Windows, sino el del "wrapper" de Mac, así que otro "fail" para la lista.

Vuelta a leer tutoriales sobre AppleScript y posibilidades y encontré algo superútil: igual que se pueden simular clics de ratón se pueden simular pulsaciones de tecla. Así que tras unas pruebas pude comprobar que ganando el foco del programa y lanzando un "Ctrl+S" (estamos en Windows) guardaba el documento. ¡Por fin!

Nota: el 1 corresponde a la "s" en key code. Aquí os podéis bajar un pdf con los "key code" de un teclado Mac. Lo necesitaréis para configuraros vuestros propios atajos.

"Pues ya sólo queda ponerlo todo en un script", pensé, pero había una última sorpresa: el script saltaba a FD, acto seguido a Flash y compilaba, pero no guardaba. ¿WTF? Cuando volvía a ejecutar únicamente el código de guardar funcionaba, pero me di cuenta que tardaba unas décimas de segundo, y pensé que seguramente al intervenir la máquina virtual no era lo suficientemente rápido al enviar el comando y ganaba el foco Flash antes de poder guardar. Esta vez me costó apenas unos minutos encontrar una instrucción "delay", y efectivamente, era eso.

Finalmente, nuestro script queda de la siguiente manera:

Lo dejo para descargar aquí: http://llops.com/descargas/applescripts/save-test-movie.scpt

Dos cosas a tener cuenta:

1. la ruta que hay en el script para FD y Flash quizá no corresponda con la vuestra. Setearla como he comentado antes.
2. el delay de medio segundo es suficiente para mi máquina, pero quizá en otras deba aumentarse a un segundo o más.

Una vez guardado el script, volvemos a QuickSilver, repetimos los pasos para hacer un trigger con nuestro nuevo script, y ahora sí que sí, con una tecla podemos guardar nuestro fichero activo y compilar en Flash (ueeeee).

 

Guardar todos los archivos y compilar

Pero... ¿y si se quieren guardar todos los archivos en vez de únicamente el que tiene el foco? Esta es una opción que utilizo mucho, ya que voy saltando de archivo en archivo, picando código y compilando "de golpe". Pues otro problema, porque FlashDevelop tiene un atajo para "Save" y "Save as...", pero no para "Save all".

Esta vez no tuve que perder mucho tiempo, porque en la "investigación" inicial de FlashDevelop descubrí los "macros" (eso a lo que nunca se presta atención). Vamos a "Edit macros..." (Ctrl+F10), creamos uno nuevo, y en "Entries" añadimos el siguiente comando:

Asignamos el shortcut que queramos y guardamos. Ahora podemos añadir dicho atajo en nuestro script y cada vez que compilemos guardará todos los archivos abiertos.

 

Cerrar la película de Flash y volver a FlashDevelop

Y ya para acabar (lo juro), un script tonto que mejora un poquito más mi flujo:

Simplemente pone el foco en Flash, cierra la película y asigna el foco a FD. En mi caso tengo "cmd+0" para guardar/compilar, compruebo que va bien y pulso "cmd+9" para cerrar el test y volver a FlashDevelop para seguir trabajando.

Nota: a tener en cuenta que si no hay una película en test cerrará el archivo fla. Está con el método del "click" porque con teclas (cmd+w) no acaba de ir bien... no sé porqué...

 

Conclusión

Si no quieres renunciar a seguir trabajando con FlashDevelop y Flash Professional en Mac, hay mecanismos suficientes para tener un workflow "perfecto" en el sistema de la manzana. Todo el tema de guardar/compilar quizá sea un poco geek, rebuscado o como se quiera llamar, pero funciona. Y de eso se trata la tecnología, de ponerla a nuestro servicio para facilitarnos las tareas.

Por otro lado siento lo larguísimo del post. Soy consciente de que lo podía haber acortado mucho, pero QuickSilver y AppleScript me han parecido herramientas terriblemente potentes, y creo que ha sido interesante hablar sobre ellas y que cada uno le saque partido no sólo para esto, sino para lo que se le pueda ocurrir que facilite los flujos de trabajo diarios. Me encantará si a alguien se le ocurren nuevos scripts y los comparte.

Por último, espero el comentario que diga "Pero vaya matada! si esto se puede hacer así y así de fácil" :) Aún así, volvería a pasar por este proceso. A veces nos tiramos tanto tiempo rodeados de Flash que nos creemos que únicamente somos programadores Flash, cuando al final ser programador es tener una base para enfrentar problemas y sacar soluciones.

Con mucha ayuda de Google, claro.

16 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2010

Mientras leía artículos para decantarme por un editor, topé con esta frase que me encantó: "My mind continues to wander back to the days of using FlashDevelop, but I must push forward. Mac OS is my home now." Así que la hice mía y decidí probar Flash Builder primero y FDT después.

Adobe FB lo descarté en poco rato. Conozco sus bondades para trabajar en Flex (obviamente) o proyectos ActionScript, pero realmente no está pensado para trabajar con Flash Professional: la integración es nula.

Con FDT tenía bastantes esperanzas ya que mucha gente habla maravillas, pero a las 3 horas lo tuve descartado también. Aunque tiene algo más de integración con Flash, me pareció muy complejo la forma de "enlanzarlo", teniendo que crear una configuración específica para cada proyecto Flash, los Core Library, que copies una carpeta de clases en tu proyecto y no las reconozca hasta que hagas un "Add to classpath" explícito... Me agotó encontrar un "problema" cada 5 minutos y pasar 20 en Google para entender qué pasaba (con suerte!). E incluso a la hora de picar código, no me sentía del todo cómodo.

Así que visto lo visto, para mis necesidades, FlashDevelop sigue siendo la mejor opción:

• por su autocompletado y code hinting (el más potente de largo). Prácticamente no hace falta ni memorizar las variables: si tienes _planeta_azul y escribes "az" ya te ofrece la opción correcta
• por Ctrl+Shift+1, que te crea funciones parametrizadas, variables de clases, getters/setters ...
• por los snippets
• por la cantidad de atajos básicos de los que no puedo prescindir (duplicar linea, intercambiar linea, comentar bloques, etc)
• por su configuración mínima
• por su perfecta integración con Flash
• porque es gratis

Y muy importante, que al contrario de FB y FDT, que están concebidos para trabajar con proyectos enteros, FlashDevelop sirve perfectamente para programar/editar clases sueltas (cosa que yo hago muchísimo).

Soy consciente que algunas de las cosas que he listado las hacen igual o mejor los otros programas, y estoy convencido de que FDT es un magnífico editor, pero al final es un tema de compatibilidad: con el IDE de Flash y conmigo :)

Así que volviendo a la frase del principio, Mac es ahora mi casa, pero voy a hacer un cuartito para un programa Windows. Hoy mismo publicaré un post explicando cómo lo tengo montado yo.

Update: ayer no me dio tiempo porque he seguido trabajando en el workflow entre Flash y FlashDevelop. Ahora sí que sí lo tengo a medida :) Espero contarlo en unas horas...

9 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2010

No ha sido una decisión fácil, porque por la mitad de 1600 leuros te puedes comprar un Dell cojonudo, porque creía que no necesitaba un portátil sino un sobremesa, porque ya tengo una pantalla de 22 pulgadas y descartaba el iMac,  porque lo encargué un día antes de la salida de Windows 7, porque me encanta FlashDevelop, Tortoise, LiveWriter...

A favor jugaba tener a mis propios mac-evangelizadores, Cay y Vicente, las ganas de aprender a moverme por Mac OS (no había tocado nada de nada), querer probar las maravillas que todo el mundo cuenta y este post de Joan Garnet, que acabó de darme el empujoncito ;)

Y desde el primer momento se aprecia qué supone tener un Mac: el packaging ya te hace sentir que estás manipulando un artículo de clase,  los acabados son preciosistas, el teclado perfecto, el trackpad exquisito... Baste decir que antes de sacarlo de la caja ya tenía a varios compañeros a mi alrededor (alguno más expectante que yo!), que me tiraron fotos y que esa tarde me felicitaron como unas 15 personas (más que en mi cumpleaños!) xD

Y bueno, del sistema operativo no voy a descubrir nada nuevo porque soy el último en llegar, pero como resumen decir que a las pocas horas ya sabía que había acertado con la decisión. Todavía me extrañan varias cosas y echo en falta algún funcionamiento/programa de Windows, pero las mil y una características compensan sobradamente. Cuando pase un buen tiempo vendré a contar mis experiencias desde el punto de vista de programador flash.

12 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009

Para ponernos en situación: vamos a asumir que cuando hablamos de código fuente hay una parte que corresponde puramente al encargo, y en muchos proyectos hay otra parte de "valor añadido" (porque se está utilizando un framework propio, unas librerías muy complejas, una clase que facilita muchísimo x tarea, etc). Entiendo que con la primera no hay problema, porque al fin y al cabo te pagan por eso, y es en el segundo caso donde sabe mal "regalar" nuestro trabajo. A partir de aquí pienso todo el rato en situaciones con este "código de valor añadido".

Para mí, casi siempre se debe entregar el código fuente. Sino se hace así, el cliente está encadenado. ¿Qué le impediría luego al desarrollador pedir cantidades desorbitadas por cualquier cambio? En caso de que al cliente no le interese trabajar con el autor original, debe tener la posibilidad de modificar él mismo el programa o pasárselo a terceras personas. Obviamente habrá excepciones, por ejemplo desarrollos muy complejos donde se entra en un sistema de licencias para explotación.

Si el cliente puede (y debería) exigir los archivos, el programador también puede pedir una cantidad mayor. En el primer comentario del post original se lee "para entregarse los fuentes, tiene que haber mucho dinero encima", y me consta que hay muchísima gente de la misma opinión. Si un programador tiene el derecho de pedir mucho dinero, obviamente el cliente tiene el derecho de preguntar qué está comprando:

• ¿una clase propia para validar un mail? ¿un gestor entero de contenidos?
• ¿y qué calidad tiene el código fuente? ¿tipo Grant Skinner o tipo estudiante de segundo curso?
• ¿está el código 100% libre de bugs?
• ¿es fácil de implementar? ¿es fácil de extender?
• antes de que yo ponga encima de la mesa el dinero ¿me vas dejar investigar a ver si merece la pena?
• y más allá del código en sí... ¿me puedes asegurar que es imprescindible utilizar ese código que aumenta tanto el presupuesto?

Intento ilustrar las preguntas anteriores con un par de ejemplos:

1) Yo como "contratista", hago un encargo a un freelance que me pasa un presupuesto muy elevado porque incluye el código fuente de un motor de tweens que ha desarrollado durante 2 años. Habiendo librerías gratuitas tan buenas como GTween o TweenLite, me niego a pagar el coste (seguramente nadie lo haría)

Ahora lo hacemos extensible, por ejemplo, a un conjunto de Expresiones Regulares. El freelance se ha currado una librería durante meses con decenas de ellas, y piensa que el cliente podrá aprovecharse de ello para otros proyectos. Yo dudo si pagarlo, porque considero se pueden encontrar en google de manera más o menos fácil.

Y lo hacemos extensible a un algoritmo que se ha inventando Yugop para deformar imágenes y que no se consigue en ningún lado y blablabla y yo lo pago encantado.

¿Qué marca el límite sobre lo que es fácil de conseguir y lo que no? ¿qué es reutilizable y qué no? ¿qué es único y qué no? Y más importante, ¿tienen nuestros clientes un nivel de conocimientos suficiente para tratar estas cuestiones?

2) Un cliente me contrata para un proyecto. Decido utilizar mi package de utilidades, que simplifica un montón de tareas y me permitirá hacer el trabajo en 5 días. El cliente se niega a pagarme el código, así que yo rehago el presupuesto sin incluir mis "utils", lo voy a hacer todo de cero. Esto significa que en vez de 5 estaré 10 días y que doblo el presu final. Para el cliente no soy competitivo y se busca otra alternativa.

Son sólo dos ejemplos, pero a mí personalmente me responden muchas cuestiones. Y aún más, vamos a alejarnos un poquito de la perspectiva flash, por ejemplo pensando que hacemos un site en html+css+php, ¿no entregas todo? ¿el programador php teme que utilicen sus clases? ¿que aprovechen el css para otro site?

Mi conclusión final es que como programador siempre voy a dar el código fuente, y como cliente no voy a trabajar con nadie que no lo entregue. Y no voy a exigir más dinero al darlo, y no voy a pagar más si me lo dan. Para mí la gracia del negocio está en el valor que aporta el programador. Si trabajo con una persona que me resuelve cualquier problema, si puede aplicar cambios sin estar 4 días, si al pedir un cambio de funcionalidad no tiene que tirar media web abajo porque la implementó con patrones, si el código está perfectamente documentado... eso sí que no me importa pagarlo.  Y por contra, si el presupuesto es muy justo, pues se puede avisar de que se programará "rápido" (que no mal), que será más difícil de extender, poco modulable, etc.

Y en cuanto a nuestro trabajo de "valor añadido", pues seamos listos. Si no se le quiere dar un plus al cliente, pues no metamos el package entero, simplemente las funciones/clases imprescindibles; si se utiliza un módulo que se puede reutilizar para otros proyectos, pues se crea un biblioteca de clases (swc); si paga las horas justísimas, pues no se comenta el código por falta de tiempo; etcétera etcétera.

Y obviamente, lo expuesto aquí es mi opinión. Cada uno es libre de valorar su trabajo y sus horas como quiera. Al final, como cada proyecto, cada cliente y cada programador es un mundo, se convierte en una ecuación de infinitas posibilidades. Por eso, se piense como se piense, lo importante es dejarlo todo por escrito desde el principio.

14 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009

Básicamente lo que quería conseguir era que partiendo de cualquier tipografía y utilizando cualquier motivo, se pudiera representar cualquier texto de forma legible (y obviamente, de forma dinámica, que sino ya está photoshop). Y aquí está una demostración:

Los motivos que he escogido para este experimento son corazones, hojas, trazos y manchas de sangre; y las fuentes Supernova, Eras Demi, Kristen y Saginaw.

Nota: una vez elegido un motivo y el idioma, la única forma de volver a la home es clicar en "Recargar" o refrescar la página. Me daba muuucha pereza tener que limpiar todos los recursos para dejar el experimento en el inicio :p

Puedes ver el experimento aquí

6 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009

Desde el punto de vista de Flex, esto no supone un gran problema ya que por defecto el framework está dotado de un sistema que permite crear una interfaz líquida con muy poco esfuerzo. Pero si hablamos de Flash, no existe un mecanismo que nos ayude a adaptar nuestra película a cualquier resolución.

 
Diseño líquido vs diseño estático

Mientras que en html se han acuñado muchos términos a la hora de hablar de los diseños (fijo, estático, flexible, líquido, fluido, elástico…), en flash, básicamente, podemos hablar que un site tiene un diseño líquido o estático.

En un diseño líquido el contenido se posiciona en función del tamaño del navegador. El programador debe decidir elemento por elemento si está anclado, si se ha de reescalar, reposicionar, etc. Y dependiendo de la complejidad del site puede ser un trabajo realmente complejo y tedioso.

Por contra, en el diseño fijo le damos un alto y un ancho a nuestra película y todos los elementos quedan ubicados de manera absoluta. Aunque a nivel de diseño y de programación es comodísimo, el problema estriba en que si alguien accede con una resolución mucho mayor verá la página pequeña desperdiciando mucho espacio, y si es menor se generarán barras de scroll que pueden dificultar la experiencia y la navegación.

Se elija uno u otro, siempre hay que decidir qué resolución mínima tendrá nuestra web.

 
Resolución mínima

Una de las primeras tareas que deberíamos hacer cuando empezamos un proyecto es decidir qué resolución mínima usaremos, o dicho de otra manera, a partir de que resolución de pantalla nuestros usuarios verán el contenido sin problemas. Hace unos años el estándard era 800x600, encontrándose ahora normalmente en 1024x768.

Aún tratándose de una web líquida, es recomendable fijar un mínimo para que los elementos no queden apelotonados cuando el navegador se reduce demasiado.

 
El problema

De manera más o menos consciente, cualquier site está pensado para trabajar con una resolución mínima, pero el gran problema es que mucha gente se olvida de las resoluciones inferiores. La razón de escoger medidas es ofrecer garantías de que una web será visualizada correctamente en la mayoría de los casos, pero en aquellos que no se pueda, todo el contenido debe seguir siendo igualmente accesible.

Nota: en este contexto, accesible hace referencia a que el contenido se puede ver/clicar, no hablo de accesibilidad web.

Y este problema no está asociado únicamente a nuevos programadores o gente inexperta. Sin ir más lejos, aquí hay dos ejemplos sacados del FWA (ambos recientes, nada de buscar en el 2006):

• http://www.energylab.tv
• http://www.harrypottertweet.com

En el primero de ellos reescalan el contenido, pero si tu resolución es de 800x600px se corta y no se puede acceder al menú inferior de opciones. En el segundo, con la misma resolución, no se puede acceder al botón para detener el audio.

En ambos casos, los programadores decidieron que la resolución mínima de sus webs sería de 1024x768, pero han descartado al resto. Detectando que la medida del navegador era inferior y añadiendo un scroll vertical posibilitarían que todo el mundo pudiera acceder a todos los elementos.

 
Un ejemplo de lo impredecible de la web

Muchas veces nos creemos con derecho a descartar a x usuarios pensando que son una minoría, como cuando empezamos a dejar de lado a los usuarios con monitores de 800x600, pensando que una altura de 600px nunca más se daría.

Pues bien, un tiempo después empieza a proliferar un pequeño ordenador llamado netbook, cuya resolución estándard es de 1024x600. En los últimos 3 años, mientras que la venta de ordenadores cae de manera incremental, el crecimiento de los netbooks lleva un ritmo que nadie era capaz de predecir.

Yo, en mi netbook, ¿por qué no puedo navegar la web de energylab? ¿o porqué no puedo detener el volumen en la de harrypotter?

No caigamos en la demagogia fácil de las minorías, en la que alguien pudiera decir “Pues no uses Flash entonces, que hay unos cuantos que no tienen el plugin”. Cualquiera, en función de objetivos, es libre de escoger la tecnología que mejor se ciñe a su propósito, así como la resolución. Si un artista considera que la resolución mínima para ver bien sus pinturas ha de ser de 1920x1050, perfecto. Pero si descarta las inferiores muchos sólo verán parte de la pintura, mientras que si habilita el scroll dará la posibilidad a todo el mundo de verla íntegra.

 
Eligiendo una resolución

Un error frecuente a la hora de elegir la resolución es pensar que el tamaño del swf puede ser el mismo. Se elige siempre una resolución de pantalla, pero a estas medidas hay que restar otros elementos como el menú del sistema operativo y el tipo de navegador, teniendo en cuenta además la configuración de éstos (con/sin favoritos, barras de estado, barras alternativas como la de Google, Yahoo, etc). Horizontalmente apenas afecta, pero verticalmente bastante.

Yo, a día de hoy, suelo plantear las webs con una resolución mínima de 1024x768. Esto se traduce en un tamaño de 996x578 para mis películas flash. Los 28px que resto horizontalmente lo hago contemplando la posibilidad de que se genere scroll vertical de sistema, mientras que los 90px que pierdo de altura corresponden a la configuración de un Firefox estándard en un sistema Windows.

Nota: a excepción de Chrome que cuenta con una interfaz muy limpia, el resto de navegadores cuentan con menús similares, así como los distintos sistemas operativos, que tienen un menú principal.

Como es imposible tener una medida que encaje en todas las combinaciones, es preferible dejar unos cuantos píxels de margen. A veces, por intentar ajustar demasiado se genera un scroll mínimo de 3 o 4 píxels que ensucia más que ayuda.

Así pues, 996x578 es el tamaño mínimo que garantizo para que una web se vea correctamente. Si el navegador tiene menos espacio para mostrar, se generará scroll de sistema.

Nota: hay gente que prefiere utilizar un scroll propio en flash. Yo no soy muy partidario para este caso concreto.

 
Swffit

Para no tener que lidiar directamente con javascript, existe una utilidad llamada swffit que permite fijar las medidas mínimas y máximas de tu película y se encarga de todo: mostrar el scroll cuando es necesario, reescalar la película para que ocupe todo el tamaño disponible, centrar la película, etc. Imprescindible.

 
Resumiendo

Los que trabajamos con Flash estamos acostumbrados a ver como la gente lo ataca por distintas razones. El tema de las resoluciones es una de ellas. Y con razón.

Resulta difícil de creer que programadores que hacen piezas tan espectaculares como para ganar un Favourite no tengan en cuenta este punto. Por no hablar de todos aquellos que "aprenden flash en 2 días" y venden webs al vecino.

Si queremos quitarle la razón a los detractores de Flash, tanto los diseñadores como los programadores debemos hacer las cosas bien, y esto pasa por empezar con las cosas básicas.

5 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009

Por cierto, sino fuera programador creo que me gustaría trabajar maquetando. Los css tienen un rollito puzzle-lógico que me mola mucho...

Bueno, el próximo post relacionado con código. Lo juro :p

4 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009