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!

9 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.

11 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.

10 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í

5 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.

3 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

A principios de 2009 pasé a ocupar el puesto de director técnico en mi agencia. En parte fue un formalismo, ya que venía encargándome de la mayoría de tareas asociadas a ese rol, pero por otro lado me obligó a tener un conocimiento global de todos los proyectos, a implicarme mucho más en la gestión de recursos, en la supervisión de externos, a consolidar el equipo técnico, etc. Así que para poder llevar todo esto a buen puerto (dentro de lo que cabe xD) tuve que renunciar a estar en los proyectos como programador. Al principio pensé que sería cosa de unas pocas semanas, pero al final he estado como medio año sin tocar una linea de código (que se dice pronto). Esto se tradujo en un abandono del blog: es difícil escribir sobre una temática cuando no estás en el día a día, no surgen  buenas ideas para los posts... y no tenía ni tiempo ni ganas para liarme con experimentos.

La segunda parte de la historia es que en julio me metí en un gran proyecto no sólo en la planificiación y dirección, sino también programando. A parte de disfrutar, puedo decir que es uno de los desarrollos en los que más he aprendido. Esto se ha traducido en ganas de volver a escribir y de compartir conocimientos.  Así que, tras unas reparadoras vacaciones, todos estos elementos dan como resultado que a partir de ya retomo el blog :)

Siempre es agradable volver.

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

LLops Blog, 2009

Como ya comenté, la original es una aplicación AIR, pero como de momento no puedo poner el .air para descargar he decidido adaptarla para navegador. Así se pierden algunas opciones y la gracia de tenerla en el escritorio, pero el resto es básicamente igual.

Algo sobre el desarrollo

Empecé este desarrollo en enero de 2008 (la teconología AIR todavía estaba en el Lab de Adobe) y, aunque a primera vista quizá no lo parezca, estuve con él casi cerca de 3 meses! Yo diría que hubo 3 motivos clave por los cuales se prolongó tanto:

1. No era un proyecto en el que estuviera a full-time, llegando a estar periodos de 3-4 días sin tocarlo (con lo que cuesta coger el hilo tras un parón...)
2. No partimos de ninguna base gráfica para llegar al resultado final. Desde el principio toda la planta se construyó a partir de la programación: el tallo, la corola, las anteras, las composiciones de las 3 flores... Hasta que todos estuvimos satisfechos con el aspecto del diente de león tuve que hacer muchas muchas pruebas. El tiesto y el panel fue lo único que vino diseñado.
3. La interactividad se fraguó sobre la marcha: la relación entra la planta y el mouse, la fuerza del "viento", la elasticidad de los tallos, la pérdida de los filamentos, la regeneración, las explosiones finales... Si me hubieran dado un euro por cada vez que compilé...

Así que una vez que estuvo cerrada, empaquetada y lista para mandar, fue como quitarse un peso gigante de encima. Eso sí, a pesar de lo cansado que fue en algunos momentos, de los proyectos en los que he participado como (seguramente mal llamado) "programador creativo", sin duda alguna es uno de los que más he disfrutado.

Y por último, esta guerra no fue sólo mía. Estuvo Román como arte, asegurándose que ningún píxel se salía de lugar, Castellote aportando poesía, Rafa Soto dándole el acabado imposible (siento que no lo consiguieras! xD ) y el señor Carlos Torrecilla echándonos un gran cable con el audio.

>> Ver La Planta de Viento

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

LLops Blog, 2009