No es que sea algo fácil de hacer. Si bien mis días de trabajar en Flash han quedado muy atrás y desde hace ya varios años me he dedicado más a HTML, CSS y Javascript, además de PHP en el backend, tengo muy buenos recuerdos de éste desde que pertenecía a Macromedia. Es por eso que mi primera reacción fue de dolor y tristeza, como quien ve un buen y viejo amigo golpeado y magullado. Pero bueno, no se trata de hablar de mi background, así que vamos al tema.

Antes de otra cosa, una aclaración: Este es mi blog personal y aquí hablo en tono personal, no como manager del Adobe User Group Venezuela ni en ningún caso en nombre de Adobe. Toda la responsabilidad de lo dicho aquí recae sobre mí y estas son sólo mis opiniones. Esto va a ser largo, así que búscate un café antes de empezar.

El primer shock que recibió la comunidad fue el despido de 750 empleados de Adobe alrededor del mundo, aproximadamente un 8% de su personal. Fue una noticia que dejó a todo el mundo impactado, empleados, miembros de los grupos de usuarios y gente relacionada a la tecnología y los negocios en general. Los AUG’s (Adobe User Groups) de Latinoamérica  y España sentimos esto en carne propia al enterarnos que John Koch, quien hasta entonces fungía como International Community Manager para Latinoamérica y Asia, era parte de ese grupo. Hay que decir que su trabajo y pasión puso a los grupos de usuarios hispanoparlantes de nuevo en el mapa y nos dio una voz en Adobe. Por eso y más, muchas gracias John.

Como si fuese poco, ese mismo día nos enteramos, sin más, que Adobe había decidido dejar de mantener el Flash Player para dispositivos móviles, y de eso tenemos que hablar con más calma.

No más versiones de Flash Player para móviles

Más allá de las pasiones que esto pueda generar en la comunidad Flash, esto es algo bueno, o cuando menos habría sido irrelevante de haber sido manejado mejor. El hecho es que muy poco o nada se estaba haciendo con Flash para la web móvil. Desde que es posible crear aplicaciones en Flash/Flex y empaquetarlos como aplicaciones para los distintos dispositivos, ése ha sido el camino que la mayoría de los desarrolladores en Flash han estado tomando y ahora mismo las tiendas de aplicaciones de Apple y Android cuentan con ellos. La cosa es que, al ser empaquetados como aplicaciones, el público general no sabe si están hechos en Flash/Flex o alguna otra plataforma, como es el comentado caso de Machinarium, el juego creado en Flash que estuvo de número uno de descargas en iPad en la Apple Store.

La verdad sea dicha, el Flash Player no pudo realmente conseguirlo en dispositivos móviles, frente a lo que hay dos puntos de vista en la web: Por un lado, están quienes alegan que Flash Player era inestable y con un pobre rendimiento en móviles, por otro lado, están quienes afirman que esto se debe al hecho de que la mayor parte del contenido que veía en la web móvil no estaba preparado para estos dispositivos. Hay que decir acá que, lamentablemente, la facilidad de uso de Flash ha sido al mismo tiempo su bendición y su maldición, permitiendo que exista en la web una buena cantidad de contenido pobremente realizado y mal optimizado y esto, junto al “Steve Jobs Phenomenon” (que no voy a discutir ahora acá), ha predispuesto negativamente a mucha gente hacia la herramienta y a veces con razón.

Ahora un par de datos importantes: El que Adobe decidiera dejar de desarrollar futuras versiones del Flash Player para móviles no significa que el Player para móviles dejará de funcionar, si ud. lo usa podrá seguir haciéndolo en base a las limitaciones que presente ahora mismo, simplemente ocurre lo mismo que ocurre con Adobe AIR en Linux, que dejó de ser desarrollado en la versión 2.6. Claro que lo más probable es que eventualmente ocurra lo mismo: que dejen de ser usados (y el Flash Player para móviles más rápidamente), pero, por ejemplo, yo uso TweetDeck en Ubuntu sin problemas ahora mismo, con Adobe AIR 2.6, y la verdad es que no tengo quejas al respecto.

Otra cosa importante de aclarar es que Flash Player y Flash Player para móviles son dos proyectos diferentes, lo que quiere decir que la decisión de abandonar el segundo no implica que el primero también sea abandonado. Al menos no existe de momento ningún indicio al respecto y la misma Adobe ha afirmado que, mientras FP 11.1 será la última actualización del FPM (Flash Player para Móviles), aún trabajan en su hermano para desktop y están ahora mismo desarrollando la versión 12.

También creo que debo insistir en que Flash, como plataforma no ha muerto ni hay indicios de que muera pronto. Ahora mismo hay un mercado creciente en el mundo de las aplicaciones y el desarrollo de experiencias multimedia en 3D que es perfectamente explotable con Flash, a lo que se une el anuncio de la Gran A de sus intenciones de agregar capacidad de exportar de Flash a HTML5 en las próximas versiones del programa. No es que ignore el hecho de que el modo como fue anunciada la muerte del FPM ha golpeado tremendamente a toda la plataforma (eso y el anuncio respecto a Flex, del que hablaremos más tarde), dando la impresión de que es un elefante moribundo, pero más allá de los rumores (los ciertos y los falsos), es un hecho que aún hay cosas que pueden hacerse y van a seguir haciéndose con Flash, dentro y fuera de la web.

Lamentablemente, creo que la terrible forma como Adobe trató esto en su comunicado puso a toda la plataforma en una situación difícil, cuyas consecuencias aún no podemos predecir. Si Adobe hubiese dicho simplemente “Hey, ahora vamos a potenciar la creación de aplicaciones con AIR y, en vista de que la tendencia en móviles es esa y no la web, no seguiremos desarrollando el Flash Player para móviles” habría evitado muchos intentos de justificación posterior y esta mala situación en la que los desarrolladores de Flash/Flex se sienten ahora. Nadie puso el grito al cielo cuando, al anunciar la adquisición de Nitobi dijeron que PhoneGap pasaría a la Apache Foundation, y esa es la misma situación en la que se encuentra Flex ahora mismo.

¿Qué deberían hacer lo “Flash developers” ahora?

Éste es un punto al que ansiaba llegar. El momento en que Flash se volvió popular para la web hizo que bajo su sombra se conglomeraran personas con los más variados perfiles: diseñadores que querían crear experiencias interactivas para la web sin tener que aprender nada o casi nada de código, flasheros (como son llamados comúnmente) que entendían que Web = Flash, desarrolladores que iban más allá de la web, aprovechando sus características multimedia para presentaciones, juegos, aplicaciones, etc.

En mi humilde opinión, éste es un momento para tomar decisiones claras. Si lo tuyo es la web, ya deberías haber aprendido HTML, CSS y Javascript, porque de eso es de lo que está hecho la web, no ahora, no por HTML5, sino porque siempre ha sido así y la tendencia de más HTML y menos Flash en la web puede ser cualquier cosa menos algo nuevo. Es verdad que la rápida adopción de HTML5 ha acelerado esto, pero ha sido sólo un empujón de una tendencia que ya existía antes de él (y la razón principal por la que, por ejemplo, yo mismo dejé de usar Flash en mi trabajo).

Si por el contrario, lo tuyo es Flash/Flex o la Flash Plattform en general, es el momento de atacar el mercado de las aplicaciones, precisamente con la disminución de la presencia del Flash Player, Adobe comenzó a mirar en otras direcciones (TV, aplicaciones para móviles, etc.) y si el desarrollo en Flash Plattform es lo que te gusta hacer, deberías mirar hacia allá también. Como decía, existe todavía un importante mercado en el que Flash tiene aún lugar. Incluso ahora mismo, e incluso cuando Windows 8 sea un realidad en producción, la web es parte de ese mercado (la de escritorio), menos que antes y que quizá disminuya con el tiempo, pero todavía es cierto aquello de que Flash está ahí para proveer aquello que HTML y sus amigos aún no pueden (por ejemplo, DRM, 3D con aceleración por hardware, etc.).

Para lo que no hay espacio ahora mismo (y nunca debió haber) es para el mal uso o el abuso de Flash, no importa lo que Macromedia, Adobe o los usuarios hayan pensado o dicho al respecto. Lo siento, pero si vas a hacer algo deberías poner todo tu esfuerzo en hacerlo bien. No hay lugar para la mediocridad en esto.

¿Y qué pasó con Flex?

Bueno, luego de la bomba (que repito, no debió ser tal, pero es lo que es) que significó el primer día de Adobe, al día siguiente se anuncia que Adobe entregará el SDK de Flex a un grupo después de liberar la versión 4.6, el 29 de noviembre de este año. El grupo estará conformado por miembros del actual equipo de desarrollo, desarrolladores de la propia comunidad y contribuyentes de algunas de las compañías que están trabajando ahora mismo con Flex.

En cierto modo, no parece tan grave, en el sentido que el SDK de Flex siempre ha sido Open Source y lo seguirá siendo. Lo que convierte las cosas en una situación difícil es que, en el mismo artículo, se dice que Adobe recomienda el uso de HTML5 en el largo término, poniendo una sombra de inestabilidad que no resulta nada fácil para los desarrolladores o las empresas que se dedican a ofrecer soluciones empresariales a través de Flex, ni siquiera cuando el mismo Adobe diga seguir comprometido con el desarrollo de Flex y el FlashBuilder. Sí, las cosas para la comunidad Flex no se ven demasiado prometedoras.

Pueden ver un panorama más claro de estas noticias en el artículo de Lime Rocket: Flash, Flex & AIR Future – via Adobe

HTML5 aún no está a la altura para este desafío

Por mucho que me guste HTML5 y sus tecnologías relacionadas, sobre todo las cosas que CSS3 y Javascript han logrado en los últimos tiempos, hay mucho de este tema que aún es promesa a futuro. Todavía lidiamos en un mundo de Internet Explorer 8, Javascript aún no tiene aceleración por hardware (como lo tiene, por ejemplo Flash Player 11) o manejo de sonido surround, o cancelación de eco al nivel de aquel. WebGL es un gran proyecto, pero aún está lejos de ser una alternativa seria… En fin, si los desarrolladores deciden dejar de usar Flash en la web, como consecuencia de todo esto, lo que veremos en el mundo web será un retroceso hasta donde HTML5, CSS3 y Javascript pueden ofrecernos ahora mismo, con la esperanza de que eventualmente lleguemos a estar de nuevo al nivel en que estamos ahora mismo con Flash. Quiero dejarlo claro una vez más, esto no es cuestión de fanboísmo ni preferencias, es lo que es. Eso de que HTML5 puede hacer todo lo que hace Flash ahora mismo es, en el mejor de los casos, un deseo, y en el peor, una mentira.

Aún cuando Adobe afirme que ahora apunta sus armas hacia HTML5, esté desarrollando herramientas de animación, como Edge y prometa la capacidad de importación a HTML5, Javascript y CSS3 en las próximas versiones de Flash, hay mucho camino que andar aún en esa vía y todavía queda pendiente el modo como los diferentes exploradores lidiarán con ello.

Curiosamente, esto no afectará demasiado la web móvil en particular, no es muy diferente a lo que está pasando ahora mismo en ella, pero sí es un impacto (sentido o no) en la web en general y pasar esto por alto no es más que jugar al conformismo, eso es triste.

¿Y entonces, qué viene? Es difícil de decirlo. bastante difícil, por un lado es posible que los desarrolladores en Flash/Flex decidan abandonar estas herramientas y prefieran dedicarse a Javascript o HTML + CSS, otro escenario posible es que estos mismos desarrolladores decidan subir el listón y comiencen a crearse cada vez mejores aplicaciones que justifiquen el uso del Flash Player en el escritorio, con su contraparte como aplicación en AIR para teléfonos y tablets. Un tercer escenario es expandir los conocimientos hacia ambas plataformas, como ha hecho Grant Skinner uno de los más renombrados desarrolladores en ActionScript, cuya agencia no se limita a Flash o HTML5, sino que abarca otras tecnologías y lenguajes.

Lo que sí está claro es que no es momento de sentarse a ver qué es lo que pasará en la web del futuro, es tiempo de tomar decisiones que creen esa web porque la verdad es que la web es de quienes la hacen, no de quienes esperan a que llegue su momento.

Nota: El gran Luís Sosa me mostró anoche Jangaroo, un proyecto Open Source que, básicamente, permite crear frameworks y aplicaciones en Javascript usando ActionScript 3. Por lo que vi, el proyecto parece prometedor y creo que le vendría bien a los desarrolladores en ActionScript 3 darle un vistazo. Eso sí, tengan cuidado de no quemar el CPU de sus clientes

HTML5, CSS3, Responsive Web, jQuery mobile, Sencha Touch, Titanium, Phonegapp, etc. dibujan un mundo nuevo y muy interesante para diseñadores y desarrolladores, no sólo por darnos un nuevo mercado sino por las características particulares que éste tiene, obligándonos a adaptarnos a las nuevas tendencias.

Sin embargo hay cosas que no han cambiado demasiado. Aún estamos pensando el mundo al revés –según creo– pasando del escritorio, de la “Web Completa” a los móviles, pensando en términos de Gracefull Degradation en vez de Progressive Enhancement. Esto, lejos de ser inocuo para la web, implica ciertos problemas, retos que aún no hemos superado porque enfrentar estos retos implica un cambio drástico, de 180º, en el modo como vemos y como desarrollamos la web del presente y perfilamos la web del futuro.

Hace ya casi un año, Bryan Rieger, nos mostró las implicaciones que este modo de asumir el mundo móvil trae consigo y la necesidad de repensar el modo como decidimos enfrentarnos a ella en su presentación Rethinking the Mobile Web, a pragmatic look at creating an accesible and inclusive mobile experience. Una verdadera joya que vale cada una de las 140 páginas que contiene.

Un material que sin duda nos pone a pensar en qué es realmente la web móvil y en cómo incluir en ella todo un universo de smartphones que, si bien no son iPhones o Androids, son, no sólo más numerosos sino también dignos de ser parte de este modo de hacer web (y claro, también pertenecen a potenciales clientes).

Acá les dejo la presentación, espero que la disfruten tanto como lo hice yo.

Bryan Rieger es diseñador web, quien junto a su pareja Stephanie conforma Yiibu, una consultora sobre experiencia de usuario localizada en Londres, Inglaterra.

Por fortuna, los primeros días de Año Nuevo no resultaron ser tan ocupados como pensaba y, contando con que era fin de semana, aproveché de darle una mirada a una pequeña joya que me encontré gracias a Google: se trata del libro en PDF Python para Todos, de Raúl González Duque. Básicamente se trata de una compilación de los conceptos que expone en su blog, mundogeek.net y es realmente una excelente herramienta para quien desee iniciarse en este lenguaje.

No importa si eres un programador experimentado o apenas estás iniciándote en las lides de escribir código, Python para Todos te llevará paso a paso, desde los tipos básicos (número, cadena, booleano) hasta la distribución de aplicaciones. La verdadera diferencia entre uno y otro nivel es simplemente que el programador experimentado se saltará algunas páginas que quien se inicia no querrá dejar de leer.

Es un libro realmente de fácil lectura y una buena forma de comenzar con este lenguaje. Además, Raúl promete mantener versiones actualizadas cuando resulte conveniente, y, por si fuese poco, es totalmente gratis. Licenciado bajo Creative Commons 2.5, ahora mismo cuenta con 160 páginas, pero no dejes que eso te desaliente porque realmente se lee rápido, yo llevo ya casi un cuarto del libro en un par de días en los que no le he dedicado más de unas tres horas cada día sin saltarme ninguna página.

Así que si estás buscando algún tutorial para aprender Python, y además en el idioma de Cervantes, te recomiendo que le des una mirada a Python para Todos, posiblemente termines disfrutándolo.

Los duendes de estadísticas de WordPress.com han analizado el desempeño de este blog en 2010 y te presentan un resumen de alto nivel de la salud de tu blog:

El Blog-Health-o-Meter™ indica: Wow.

Números crujientes

El Museo del Louvre tiene 8,5 millones de visitantes al año. Este blog fue visto cerca de 74,000 veces en 2010. Si el blog fuera una exposición en el Louvre, tomaría 3 días para verla.

En 2010, publicaste 17 entradas nueva, haciendo crecer el arquivo para 125 entradas. Subiste 16 imágenes, ocupando un total de 475kb. Eso es alrededor de una imagen por mes.

The busiest day of the year was 9 de febrero with 497 views. The most popular post that day was Programación Orientada a Objetos (un acercamiento para novatos).

¿De dónde vienen?

Los sitios de referencia más populares en 2010 fueran search.conduit.com, blogs.unellez.edu.ve, google.com.mx, twitter.com y cristalab.com.

Algunos visitantes buscan tu blog, sobre todo por programacion orientada a objetos, programación orientada a objetos, caracteristicas de la programacion orientada a objetos, que es programacion orientada a objetos y que es poo.

Lugares de interés en 2010

Estas son las entradas y páginas con más visitas en 2010.

Programación Orientada a Objetos (un acercamiento para novatos) diciembre, 2007
17 comentarios

Programación Orientada a Objetos – Características de la POO diciembre, 2007
21 comentarios

Programación Orientada a Objetos – ¿Qué es POO? diciembre, 2007
10 comentarios

Programación Orientada a Objetos – Clase e Instancia enero, 2008
34 comentarios

Programación Orientada a Objetos – Cómo Escribir una Clase febrero, 2008
17 comentarios

Muchas gracias a todos por pasar de vez en cuando por este humilde blog. Es un honor.

No creo que se me ocurra alguna otra cosa que escribir por lo que nos queda de 2010 y si es así, posiblemente la deje para el próximo año (quedan apenas cuatro días para el 31 de diciembre, después de todo), así que quiero aprovechar de desear a todos/as un muy Feliz Año, esperando nuevamente que sus metas se cumplan y que el año que viene sea incluso mejor que el que estamos terminando ahora. Que haya paz y felicidad en sus corazones y sus vidas y que no sea perturbada por otra cosa que no sea exceso de trabajo (con su respectiva ganancia) y exceso de alegrías (si es que tal cosa es posible). Tengan unas felices fiestas y mis mejores deseos para uds. y, como siempre, gracias por pasarse de vez en cuando por acá y leer algunas de las tonterías que un servidor escribe en este blog.

Lamentablemente, es muy común ver que estas cosas son ampliamente ignoradas, a veces por tiempos de entrega que se mueven entre lo mediocre y lo imposible, clientes que sólo quieren un sitio igualito a aquel, o simplemente por no considerar la verdadera importancia que tienen los aspectos arriba mencionados en el mundo web. Muchas veces esto ocurre porque olvidamos que el verdadero objetivo de un sitio web no es crear una especie de tarjeta de presentación en internet sino un medio de comunicación entre el cliente y su mercado. Esto no me parece una consideración menor, al contrario, comprender el objetivo final es algo vital a la hora de pensar en el producto en el que estás trabajando.

Ahora mismo nos encontramos en uno de los momentos más excitantes de la tecnología, posiblemente desde la aparición en escena de la web social (conocida también como web 2.0): HTML5, Flash en dispositivos móviles y televisores, tablets, smartphones y un largo etcétera que hace que nuestras ideas sobre nuevas formas de hacernos millonarios comiencen a surgir a borbotones y nuestra cabeza explote con las nuevas cosas que queremos y debemos aprender sólo para mantenernos al día. Creo que es en momentos como éste donde debemos recordar lo aprendido y no olvidar cosas como la usabilidad o accesibilidad justo en el momento en que se vuelven más importantes, sobre todo teniendo en cuenta que dispositivos como los smartphones y tablets nos exigirán repensar una y otra vez sobre nuestras aplicaciones y el modo como nuestros usuarios interactuarán con ellas. Estoy convencido que la idea de “trasladar la experiencia de la PC a los nuevos dispositivos” no es la forma más acertada de entender el futuro de la web.

Piensa en móviles primero

Crear sitios específicamente para móviles no es una idea novedosa (¿recuerdan el protocolo WAP?), pero la aparición de dispositivos móviles con cada vez mayores capacidades le ha dado un nuevo auge, aún cuando creo estamos lejos de ver lo que realmente pueden llegar a ser. En el nuevo mundo móvil tenemos browsers de verdad, mayor capacidad, Wi-Fi, etc. que nos da todo un nuevo abanico de posibilidades.

Sin embargo, no podemos olvidar que estos dispositivos no disponen de las ventajas que nos da un computador personal, ya sea en términos de resolución de pantalla, velocidades de conexión, etc. lo que nos obliga a crear una interfaz que funcione específicamente dentro de estas limitaciones.

Eso significa que, en miras de hacer un proceso escalable y siguiendo los patrones del Progressive Enhancement, lo ideal será pensar primero las interfaces con mayores limitaciones y luego aumentar las prestaciones a medida que los recursos aumentan: móviles primero, luego tablets y de allí a la PC.

Claro que siempre existe la posibilidad de que el proyecto en el que vas a trabajar no contemple móviles y entonces te preguntes ¿y para qué voy a diseñar para móviles entonces? Bien, dos respuestas: 1.- Deberías proponer a tu cliente la posibilidad de tener una versión para móviles (antes que a alguien más se le ocurra). 2.- Aunque no vayas a crear una versión móvil, pensar en términos de móvil te permitirá desarrollar ciertas habilidades que mejorarán tu producto en áreas como usabilidad y jerarquía de contenidos.

¿Qué implica diseñar para móviles?

Obliga a enfocarse en lo verdaderamente importante:

Dadas las limitaciones que tenemos en un dispositivo móvil (tamaño de pantalla, velocidad de conexión, etc.) es indispensable aprender a jerarquizar la información ¿qué es realmente lo que queremos que nuestros usuarios sepan? ¿Cuáles de los servicios que nuestro sitio ofrece son realmente usados como para aparecer de primero en nuestra lista de jerarquía? ¿Realmente es útil darle la bienvenida con un lindo texto de presentación o es mejor mostrar de una vez aquello que los usuarios realmente buscan en nuestro sitio?

Para ilustrar mi punto, quiero citar Steve Krug, en su ya clásico libro sobre usabilidad web: Don’t Make Me Think:

People often ask me:
“What’s the most important thing I should do if I want to make sure my Web site is easy to use?”
The answer is simple. It’s not “Nothing important should ever be more than
two clicks away,” or “Speak the user’s language,” or even “Be consistent.”
It’s…

“Don’t make me think!”

I’ve been telling people for years that this is my first law of usability. And the more Web pages I look at, the more convinced I become.

(A veces la gente me pregunta:

“¿Qué es lo más importante que debería hacer si quiero asegurarme de que mi sitio es fácil de usar?”

La respuesta es simple. No es “Nada importante debería estar a más de dos clics de distancia”, o “Habla en el lenguaje del usuario”, o siquiera “Sé consistente”.

Es…

“¡No me hagas pensar!”

He estado diciéndole a la gente por años que ésta es mi primera ley de usabilidad. Y mientras más páginas web veo, más me convenzo.)

Diseñar un sitio específicamente para móviles nos obliga a entender al usuario, a saber qué es lo que busca en nuestro sitio y darle justamente eso. Es imprescindible que sepamos enfocar nuestro sitio en aquello que realmente queremos mostrar al usuario o aquello que sabemos que realmente quiere de nosotros, desechando aquellas cosas que, por interesantes que puedan ser desde nuestro punto de vista, resulten secundarias o poco importantes para él.

Hace fundamental conocer al usuario final:

Uno de los principales problemas que enfrentamos con nuestros clientes es que, por lo general, no piensan en sus usuarios a la hora de crear el sitio web, haciendo solicitudes que responden básicamente a una mezcla entre sus gustos personales (o los suyos, los de su pareja, los de sus socios, etc.) y las cosas que desea que el sitio muestre sobre su producto. La mayoría de las veces esto se traduce en un montón de información (muchas veces innecesaria y sin importancia para el usuario final) combinada con una serie de pautas estéticas tomadas de otros sitios web: la galería de acá, la animación de allá, el fondo de más allá… Una especie de Frankenstein hecho a la medida de quien solicita la página pero que poco o nada tiene que ver con quien realmente debería interactuar con esta información.

Cuando las limitaciones propias de los dispositivos móviles nos obligan a prescindir de aquello que no es realmente necesario, conocer al usuario, sus preferencias, su comportamiento se convierte en algo vital. Si le damos sólo aquello que no necesita, si no entendemos qué es prioritario para él, si no nos preocupamos del modo como se comportan los usuarios cuando navegan desde un dispositivo móvil, nuestro sitio será un fracaso. No lo olvides, un sitio web es exitoso si es redituable, de lo contrario sólo es una pérdida de dinero.

Se hace entonces más evidente que a la hora de desarrollar nuestra idea, conocer al usuario final y actuar en consecuencia marca la diferencia entre el éxito y el fracaso de nuestro proyecto.

Nos obliga a presentar un buen producto, incluso con recursos limitados:

Por supuesto, cada vez que yo digo smartphone, lo más probable es que pienses en iPhone, Android o Blackberry, por decir lo común, y eso está muy bien si estamos pensando en lo que será el mundo móvil dentro de unos dos o tres años, pero hoy mismo, este mercado apenas abarca una fracción del mundo móvil en general y no hace falta tener un smartphone para acceder a la Mobile Web, por supuesto, un teléfono móvil no-smartphone tiene aún más limitaciones que un smartphone. Se hace necesario mostrar un producto que sea atractivo y –sobre todo– efectivo incluso con recursos muy limitados. Esto, aunque requiera un mayor esfuerzo en planificación, resultará en un producto más veloz y óptimo.

En conclusión, hacer el cambio de paradigma de móviles a PC en vez de PC a móviles no sólo nos prepara para el futuro cercano en el que desarrollar sitios optimizados para estos dispositivos no será simplemente un lujo de grandes empresas sino una necesidad real del mercado sino que además nos permite hacer un necesario ejercicio de arquitectura de la información en pro de un producto más efectivo y usable.

Estas son sólo algunas de las consideraciones personales que me motivan a exponer la idea de diseñar para móviles primero, si les parece interesante esta idea y quieren profundizar en ella, el primer lugar donde deberían buscar información es en el sitio de Luke Wroblewski, promotor de la idea de Mobile First! y que además agrega otras razones a las acá expuestas (excepto en el caso del enfoque, que también hemos tratado acá). Hay mucha más información al respecto allí y deberías revisarla.

Mucho queda por decir y aprender respecto a este tema, por supuesto, así que tendremos que volver a ello en posteriores artículos.

Utilizando Skype como plataforma de comunicación y un programa para Mac que encontró Rafael Ochoa, grabamos el pasado sábado, 25 de septiembre, nuestro episodio piloto, con el que iniciamos este proyecto quincenal, combinando tecnología, noticias, gadgets y un poco de humor, con sabor venezolano.

En este primer episodio escucharán a Rafael Ochoa y Juan Manrique, de RIA212, junto a quien escribe este blog, César Frick, conversando sobre el evento Adobe Hispano 2010, las últimas caídas de Twitter y Facebook y la salida de las tablets de RIM y Samsung.

Para darle un toque ameno, comenzaremos y terminaremos cada episodio con un tema musical.

Desde AUG Venezuela queremos agradecer especialmente a Javier Chaurán (@musicaymas) de Música y Más y a Félix Ríos (@infelix) de Oye Esto por el desinteresado apoyo y asesoría que nos han brindado en la publicación de este proyecto.

Pueden conseguir más información en el blog de AUG Venezuela, donde también pueden escuchar el episodio piloto.

Gracias a la cuenta de Twitter de creativeLIVE me entero que en asociación con  O’Reilly estarán dictando un Curso de Desarrollo Web para Móviles online y completamente gratuito .

El curso comienza el día 5 de Octubre, hasta el 7 de Diciembre, todos los jueves martes, con una duración de 10 semanas y cada sesión durará entre 90 a 120 minutos.

Por supuesto, el curso será dictado en inglés, lo que puede o no ser un problema dependiendo de cómo te defiendas con ese idioma (¿no te había dicho ya que tenías que aprender inglés?) y las sesiones comenzarán a las 3:00 p.m., hora del Pacífico. Sin embargo, hay que tener en cuenta que las primeras cinco sesiones se realizarán en horario PDT (Pacific Daylight Time), mientras las 5 siguientes se realizarán en horario PST (Pacific Standard Time) ¿Qué significa eso? que en el caso de Venezuela, las primeras cinco sesiones serán a las 5:30 p.m. (17:30) y las últimas cinco a las 6:30 p.m. (18:30), una hora más tarde.

Puedes calcular la hora correspondiente a tu país usando The World Clock – Time Zone Converter.

¿Qué vas a aprender en este curso? Veamos:

• Discover what’s new in HTML5, CSS3, and JavaScript for mobile development
• Build your own Twitter App with these technologies
• Create apps that detect the orientation of mobile devices
• Use geolocation and maps in a location-based app
• Enable mobile users to use your app offline
• Use HTML5 web forms to create an address book app
• Create drawings and animation with JavaScript and HTML5′s canvas element
• Use HTML5′s audio and video elements to build a movie trailer app

Interesante ¿no? Quizá esto es lo que necesitabas para animarte a trabajar con HTML5 y comenzar con el desarrollo de aplicaciones web para móviles, y ambas a la vez.

Importante: Hay algo que debes tener en cuenta, y son los requisitos:

• Experiencia con HTML, CSS y Javascript.
• Una laptop con Mac OS X (10.6).
• Safari 4 o superior.
• Simulador para iPhone y iPad.

Como ves, los dos elementos que están en negrita pueden resultar un problema para aquellos que no usamos Mac, así que miré en la descripción de las sesiones y noté que ninguno de los temas requiere algún elemento particular de OS X, por lo que lo de la laptop está descartada… excepto quizá por el tema del Simulador para iPhone y iPad.

Por supuesto, estos simuladores están diseñador para Mac OS, así que si no los tienes estás en problemas, a menos que –como yo- busques alternativas. Te cuento de algunas que he encontrado:

• iBBDemo2: Aplicación OpenSource creada por Shaun Sullivan, CTO de Blackbaud Labs, creada en Adobe Flex y corre bajo Adobe AIR, lo que significa que funciona tanto en Windows como en Linux y Mac. Básicamente es un emulador de Safari (lo que implica que no es posible llamar a elementos nativos de iOS) que tiene el plus de trabajar tanto como emulador de iPad como de iPhone, usando el User Agent correspondiente.
• iphonetester.com: Como puedes imaginarlo, un emulador de iPhone online. Para un mejor funcionamiento debe correrse (como es de esperarse) en algún navegador que haga uso de Webkit (como Safari o Chrome), permite rotación pero sólo emula a iPhone y sólo tiene acceso a aplicaciones en línea.
• MobiOne: No sólo un emulador (que también lo es) sino todo un IDE específicamente creado para diseñar aplicaciones para iPhone de forma completamente gráfica. No voy a ahondar sobre él ahora (porque apenas lo descubro) pero es una interesante herramienta de la que seguramente charlaremos en otro artículo. Lamentablemente no tiene algo parecido para iPad y es creado para Windows. Habrá que ver si puede correrse en Linux bajo Wine o algo parecido.

Bien, creo que con esto tenemos suficiente para atender este curso, así que yo que tú voy colocando las fechas en mi agenda (yo ya las puse en Google Calendar).

Eso sí, si yo fuese tú estaría muy pendiente de los sitios creativeLIVE y O’Reilly porque hay mucho material para aprender allí.

(Nota: Yo no soy fan de publicar las noticias que corren por todos los blogs el mismo día, pero creo que esta sí que merece la pena. Este artículo fue escrito originalmente para el blog del AUG Venezuela)

Esta es la noticia del día, yo diría que del mes. Después de la polémica decisión de Apple, hace algunos meses, de restringir el desarrollo de aplicaciones para la Apple Store, dejando por fuera frameworks de terceros, como Adobe Flash (que acababa de lanzar su compilador para iPhone), Mono Touch, Unity 3D y otros, hoy ha dado un paso atrás, relajando las condiciones para desarrollo de aplicaciones para Apple Store. De este modo lo han anunciado:

[…] Based on their input, today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year.

In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.

([…] Basados en sus comentarios [de los desarrolladores de aplicaciones para A.S.], hoy estamos haciendo algunos cambios importantes a nuestra licencia del Programa de Desarrolladores en las secciones 3.3.1, 3.3.2 y 3.3.9 para relajar algunas restricciones hechas anteriormente este año.

En particular, estamos relajando todas las restricciones en las herramientas de desarrollo usadas para crear aplicaciones para iOS, en tanto las aplicaciones resultantes no descarguen ningún código. Esto debería dar a los desarrolladores la felxibilidad que desean mientras preserva la seguridad que necesitamos.)

(resaltados obra del traductor)

Esto es todo un salto atrás respecto a la anterior política de Apple y un nuevo capítulo en la relación amor-odio entre la compañía de la Manzana y la Gran A.

Es de destacar que esta decisión no sólo afecta positivamente a Flash, sino también a otras plataformas de desarrollo, como las mencionadas más arriba. Y no puede ser más que una buena noticia para todos aquellos que desarrollan o quieren desarrollar aplicaciones para iPod, iPhone y/o iPad sin tener que aprender C, C++ u Objective C sólo para ello, ni qué decir para la portabilidad entre plataformas móviles.

Aún hay que esperar qué cola traerá esta noticia. Por supuesto habrá defensores y detractores, y es de esperar que nuevamente se levante alguna Flamewar, pero aún es pronto para decir más. De momento, sé de más de uno que debe estar desempolvando el compilador de Flash CS5 y haciendo pruebas desde ahora mismo

En cualquier caso, si deseas ver en detalle los nuevos cambios, puedes descargar el PDF oficial del iOS Developer Program License Agreement.

Happy Coding!

Actualización: Curiosamente Adobe no ha hecho mayores declaraciones al respecto, excepto por la publicada en su cuenta de Twitter:

“…We are encouraged to see Apple lifting its restrictions on its licensing terms, giving developers the freedom to choose what tools they use to develop applications for Apple devices….” — Adobe

Sin embargo, la actualización 11.0.1 de Flash CS5, del día 07/09/2010 (hace apenas dos días) incluye, entre otras cosas, soporte para crear aplicaciones a resolución completa para iPad, soluciones de ciertos bugs y mejoras de desempeño en el empaquetador para iPhone. Está claro que este anuncio de Apple no les ha caído por sorpresa

[...] nada mas por esto voy a usar guindows 1 mes

Sumido en mi profunda ignorancia y recordando que Adobe había desarrollado una versión de prueba de Flash Builder para Linux, me apresuré en decirle que no era necesario porque de hecho existía una versión para este Sistema Operativo. Debí averiguar mejor antes de contestar.

Al buscar la fulana versión me topé con el hecho de que Adobe había descontinuado el proyecto (cosa que sabía pero no recordaba, entre otras cosas porque apenas hace poco fue que realmente me animé a usar Linux) y que no había otra solución oficial al asunto.

Buscando alternativas, me encontré con FB4Linux, un proyecto bajo licencia GNU para portar Adobe Flash Builder a Linux, como plugin de Eclipse y me decidí a probarlo a ver si funcionaba.

Personalmente no uso Eclipse, pero sí utilizo Aptana Studio, un IDE para desarrollo web basado en aquel, por lo que, tomando en cuenta mi anterior éxito para instalar en él el plugin de desarrollo para Android, decidí probar suerte con éste y en efecto, funciona. Así que lo que diga acá respecto a la instalación en Aptana Studio bien puede comprenderse también para su instalación en Eclipse.

Instalación de FB4Linux

Paso 1: descargar y unificar los archivos de instalación

Lo primero, claro, ir al sitio de FB4Linux y descargar los cuatro archivos de instalación: FB4Linuxaa, FB4Linuxab, FB4Linuxac y FB4Linuxad. Ten un poco de paciencia hasta que terminen de descargarse.
Una vez descargados, abres la terminal, vas al directorio donde descargaste los archivos y tecleas:

cat FB4Linux* > FB4Linux.tar.bz2

Con esto obtendrás un archivo tar/bz2 estándar donde se encuentran los archivos necesarios para la instalación.

Paso 2: Extraer los archivos

No hay misterio en ello, simplemente extraes los archivos (ya sea a través de la terminal o por medio de la interfaz gráfica) y los colocas en un sitio que te resulte cómodo para luego instalarlos en el IDE.

Paso 3: Instalar el Plugin

En mi caso voy a referirme a la instalación en Aptana pero, como ya dije antes, no debe ser muy diferente el proceso en Eclipse.

1. Lo primero, vamos al menú Help -> Install New Software…
   
2. Esto nos abrirá la ventana Install, que es donde se encuentran los repositorios de los plugins
   
3. Hacemos click en el botón Add.. que nos abrirá una ventana donde buscaremos el directorio donde descomprimimos nuestros archivos. Allí hacemos click en Local y buscamos la carpeta donde se encuentra nuestro plugin. Una vez allí, aceptamos, colocamos un nombre a nuestro repositorio (esto es opcional, pero altamente recomendable) y veremos los elementos que vamos a instalar.
   Nota: Si al momento de hacer estos pasos no ves nada en la lista de elementos sino un mensaje que dice There are no categorized items, deselecciona Group Items by category y entonces podrás verlos.
   
4. Una vez hecho esto, sólo sigue las instrucciones. Aptana te pedirá reiniciar una vez instalado. Acepta y voilá, ¡ya tienes un IDE para Flex en Linux!

Un Par de Notas sobre FB4Linux

1. Al hablar de esto, es necesario colocar una “nota de advertencia” y es lo referente a la licencia. Si bien el proyecto aclara que no es un proyecto oficial de Adobe y está él mismo licenciado bajo GNU, no queda claro el tema respecto a si respeta o no las licencias de Adobe que, si bien no desarrolla este plugin para su uso en Linux, el mismo no deja de ser una adaptación de alguna de sus versiones (supongo que la de Mac, pero realmente no lo sé) para ser usada de esta forma, así que no puedo recomendarlo sin más sin antes advertir al respecto (en mi caso, la instalación ha sido fundamentalmente por motivos educativos puesto que no uso Linux para mi trabajo en Flex).
   Por lo que he visto hasta ahora, FB4Linux no utiliza la interfaz gráfica de Flash Builder (a excepción quizá de su página de inicio) y al parecer sólo hecha mano del SDK que es de libre distribución, pero no soy un experto en licencias por lo que no puedo decir mucho más al respecto. De hecho en la página de Issues de FB4Linux hay una discusión respecto a este tema.
2. Es importante tener en cuenta que FB4Linux no incluye el SDK de Flex, que deberás descargar del sitio de Adobe, lo que no implica ningún problema mayor ya que es gratuito, y luego configurar Aptana (o Eclipse) para que trabaje con la versión con la que deseas, para ello ve al menú Window -> Preferences -> Flash Builder -> Installed Flex SDKs
   
   
3. En otro aspecto ya meramente técnico, cada vez que creaba un nuevo proyecto en Flex aparecía un error, que indicaba que no podía abrir la carpeta que se refiere a la configuración de localización por defecto del proyecto, que en mi caso, al estar en Venezuela, es “es_VE” y, por supuesto, no existe. Hay dos formas de resolver esto:
   1. Seleccionar el proyecto e ir al menú Project -> Properties. Aparecerá seleccionado por defecto “Flex Compiler”. En “Aditional compiler arguments” cambiar “es_VE” por alguno de los existentes (en mi caso lo cambié a es_ES). El problema con esta solución es que deberá hacerse por cada proyecto, individualmente.
   2. Una solución definitiva (y que encontré casi a las tres de la mañana después de buscar incesamente en internet) la encontré en los foros de Adobe, donde alguien presentaba el mismo problema.
      La solución en este caso es tan simple como modificar el archivo aptanastudio.ini (o eclipse.ini según el caso) y agregar al principio del archivo estas líneas:
      -nl es_ES

      Con esto, todos los nuevos proyectos tendrán la localización por defecto que hayan seleccionado. Para saber cuáles son las opciones disponibles hay que ir a la carpeta donde se encuentra el SDK y de allí ir a la carpeta frameworks -> locale.