Proyectos

En el año 2009 mientras trabajaba para RD3 (compañía que a mi parecer actualmente -2012- ya no existe) se me comisionó hacer el sitio web en Flash para el libro de una escritora de San Francisco, Estados Unidos. El diseño, original de Dewie Right, consistía de un estante para libros; este obviamente con libros y varios objetos relacionados, esto como parte de un Estudio de Lectura. Items del escenario reaccionarían con el mouse para mostrar cierta información al usuario con respecto al libro, su autora, noticias, y un concurso.

Lo más complicado para ese momento, pero a la vez gratificante, fue la burbuja que aparece en ciertos libros al pasar el mouse, ya que, aunque no lo parece, es dinámica; esto quiere decir que su tamaño, posición, y contenido, cambiaban por si solos al reconocer al libro en el que el mouse pasaba por encima. ¿Por qué hacer esto tan complicado? ¿no hubiera sido mejor hacer un globo por cada libro? Aunque esto es técnicamente cierto, y solo hubiese requerido recortar la imagen del diseño original en PSD, por experiencia me ha quedado la enseñanza en que es mejor hacer los objetos con contenido dinámico, ya que el cliente, diseñador -o hasta jefe- pueden cambiar de opinión en cualquier momento, incluso faltando un día para la publicación. Satisfactoriamente para mí, fue la mejor decisión, aunque fuera un camino más largo, ya que según recuerdo, se hicieron varios cambios posteriores, como agregar un nuevo libro con globo, y cambiar un texto; por lo que estos cambios solo requerían mi modificación de un archivo XML del que se cargaba toda la información.

No todo el sitio fue realizado por mi, hubieron partes en las que mi compañero de trabajo tuvo que ver, como por ejemplo el desplegar la información del libro, y pasar sus páginas.

Efectos, transiciones, y animaciones de botones -como al hacer click que el objeto brinca- fueron realizadas por mi.

Al sitio de TechosSCT lo recuerdo con mucho cariño por su diseño; los diseños en negro me encantan, siempre le da elegancia a cualquier sitio, al contrario del blanco, que a pesar que no es malo, lo hace ver todo muy ordenado.

El cliente requería mostrar la gran variedad de productos y servicios que manejan, todo esto ilustrado con imágenes de gran calidad de cada uno de sus proyectos realizados alrededor de Costa Rica.

Uno de los mayores retos fue distribuir el contenido en categorías, acomodarlo propiamente en las URLs, y que fuera de fácil acceso a través del menú. Existen categorías de tipo de producto y servicio, y dentro de ella una lista de las variedades que contenía. La idea en concepto es bastante sencilla: Si veías la lista completa de productos y servicios, se iba a tomar un ejemplar de la lista, para sacar la fotografía y usarla en la descripción, todo esto para evitar estar creando nuevas imágenes de forma innecesaria, y luego el diseño se repetiría para listar los items de ese producto o servicio.

El menú de la parte derecha dentro de la sección de Productos y Servicios requería un estilo de acordeón; durante la investigación se pensó en usar alguno ya hecho -algún plugin-, pero el comportamiento de estos no rendía las especificaciones de comportamiento, ya que muchos de estos una vez después de hacerles click se mantenían desplegados, y era posible que el menú tuviese muchos items dentro y no podíamos permitirnos hacer que el usuario se desplazara mucho con el mouse. Al final la idea del plugin se desechó, y usé jQuery y manejo de eventos para activar la apertura y cierre del menú.

La rotación de imágenes en la Pantalla Principal, tuvo su reto, mucha gente está familiarizada con Flash, pero desconocen que hacer cada uno requiere muchas veces un esfuerzo tan grande como hacer una aplicación; por sí misma es un proyecto aparte. Nunca había hecho un flash así, por lo tanto fue un reto interesante; por lo general las transiciones de imágenes son simples, a esto me refiero que cada que se carga una imagen, se procede con la siguiente, pero esta requería 3 imágenes, desplegar su información, y hacerlo de forma cronometrada. Recuerdo que uno de los primeros demos fue algo "exagerado", ya que usé una transición de caída, y otra de movimiento de izquierda a derecha, por lo que luego se optó por el denominado "fadein" o transición por medio del canal alfa, que hace que la imagen aparezca de transparente a sólido.

El sitio fue realizado en 2009.

Por mucho el proyecto más grande y más impresionante en que he estado.

En el 2011, luego de cofundar PipoIdeas y formar parte de la Junta Directiva de 506Creative S.A. por un año, mi socio en su momento Jorge Jiménez Peraza viene a plantearme la posibilidad de una gran idea: Construir un sitio web que acumulara la actividad nocturna y social del país, ya que como mencionaba en su momento "el tico es muy fiestero", todo esto para lograr un abundante tráfico y tener estadísticas abultadas para mostrar a potenciales clientes que quisieran publicitar con nosotros.

A finales del 2010, para quien conozca del hecho, Conan O'brien volvía a la televisión, pero esta vez por cable, cosa que me hizo muy feliz, ya que este fue el hombre que dijo en el momento más bajo de su carrera 6 meses antes al ser despedido por NBC, y tener chance de decir lo que él quisiera: "...But if you work really hard and you're kind, amazing things will happen..." (Pero si trabajas muy duro, y eres amable, cosas asombrosas pasarán); esto produjo una serie de explosión multimedia por parte de su equipo creativo. Uno de estos ingeniosos giros en su producción, era usar pasantes para hacer sketches cómicos online cada viernes, en un show de un par de horas llamado "Live Coco Cam". Me llamó fuertemente la atención que la gente trabajara para aprender, sin un pago; y debido a que nuestro fuerte no era el capital para invertir, excepto en tiempo para desarrollar, la idea surgió que, desde un principio se planteara a los periodistas que técnicamente estarían trabajando gratis, esa decisión estaría en ellos, nadie estaba obligado a nada, pero que si accedían nuestro compromiso era exponerlos fuertemente por nuestros medios disponibles, como en mi caso twitter, y también por el Facebook de la página, nombrando en lo más posible a los autores.

El sitio pretendía tomar un nicho abandonado en el ámbito costarricense: La noticia joven. Por mucho tiempo dominado únicamente por el icónico sitio VueltaEnU que desapareció en octubre del 2010 -que sabemos que algún día volverá-, y por el sitio de apariciones aleatorias y muy bien mercadeado Fusil de Chispas al que siempre le notamos un enfoque más de "publirreportaje" ya que pocas veces era objetivo en sus notas y era más que todo enfocado a dar su opinión -muchas veces válida, otras no- y siempre con un buen cuadrito de publicidad que a veces parecía marcar la forma en que iba dirigido el artículo.

Durante nuestro periodo de investigación incluso encontramos otro sitio en el mismo nicho, que nunca salió al aire, propiedad de otro periódico costarricense -del cual no tengo el dato a mano-, que sus razones habrá tenido para ni siquiera ser estrenado, pero fue un interesante augurio que tal vez debimos poner más atención.

Ya tenia un año desarrollando sitios en Drupal-al dia de hoy enero 2012, 2 años-, así que era casi que seguro que el sitio iba ser desarrollado de esta manera. Drupal tiene una gran curva de aprendizaje, como lo explica aquí el mismo creador de Drupal: Dries Buytaert (http://buytaert.net/drupal-learning-curve), pero era una curva que ya había superado lo suficiente para desarrollar cualquier sitio sin dificultad. Wordpress y Joomla, usados respectivamente en Fusil de Chispas y VueltaEnU, si bien tengo mis quejas personales con cada uno de los sistemas, y estoy seguro que se han hecho sitios web fantásticos con ellos, como por ejemplo TechCrunch en Wordpress y DevShed con Joomla, ya Drupal lo conocía para el momento mejor que cualquier otro CMS, y la posibilidad de expasión a futuro que tiene Drupal no me hizo cambiar de opinión y Drupal 6 fue la elección, ya que a pesar que para su momento Drupal 7 ya estaba público, muchos de los módulos de la versión 6 no habían sido trasladados a la nueva versión y no era compatibles.

Si bien mi conocimiento de Joomla es NULO, y Wordpress lo he usado meramente casi como usuario estándar, un par de tópicos muy famosos que tiene cada uno, nunca me hicieron volverlos a ver para desarrollo masivo para sitios, por un lado Joomla tiene un horrible sistema para manejar URLs, que desde mi punto de vista aunque tal vez actualmente ya no sea tan mal visto, arruina el SEO, aparte que unas URLs en que tienen parte de la descripción en sí mismas, ayuda a que una persona tome la decisión si accede al sitio o no, y por otro lado Joomla, aunque no me consta por experiencia propia, tiene un terrible sistema de seguridad, ya que no es actualizado tan frecuentemente como Drupal, lo que siempre me ha hecho verlo de largo, ya que si vas a usar un CMS tiene que ayudarte y no complicarte. En Wordpress excepto para un sitio en que tuve que hacer una re estructuración del tema visual, no tengo mucha experiencia, pero siempre tuve esa sensación de que no era tan expansible en capacidades como lo es Drupal, luego he oído de que al intentar hacer crecer al sitio Wordpress, empezaban a aparecer conflictos entre "plugins", algo que a mi parecer es imperdonable. El argumento con que siempre vendo un sitio en Drupal es el siguiente: "El sitio de la Casa Blanca usa Drupal" y a partir de ahí... no hay más dudas...

He tenido sitios de todo tipo, grandes, medianos, y pequeños, unos duraban una semana de producción y el más grande, por su complejidad y monstruosidad en desarrollo, se encontraba Voz Metropolitana. Mucha gente se sorprende cuando les comento, ya que piensan "que lento" y en realidad no fue así en lo más mínimo, como mencioné, hay sitios pequeños que duraban una semana, y Voz Metropolitana duró 5 meses. El sitio es de una complejidad extraordinaria, tiene la capacidad de almacenar artículos hasta su revisión, para su posterior publicación luego de su aprobación, y esta publicación podría ser establecida a una hora determinada -por ejemplo a media noche del día siguiente-, cada artículo podría ser filtrado por una categoría global que equivalía a una sección del menú principal, y una serie de categorías menores para relacionarlos entre artículos, las galerías podrían ser relacionados con los artículos, las fotografías relacionadas a los artículos funcionaban de atractivo visual en las lístas; se creó posteriormente -por necesidad y demostrando la escalabilidad de Drupal- una sección dedicada exclusivamente a Eventos y otra que listaba en un mapa, nuestro ya existente directorio de Lugares nacionales, con un sistema de votación; también acceso a usuarios por medio de Facebook Connect, lo que permitía llenar sus datos y crear una cuenta con ciertos datos de la famosa red social. Un detalle no muy visible para el usuario común, es que a la hora de compartir el artículo por medio de las redes sociales, era que teníamos control absoluto sobre el texto expuesto en Facebook y Twitter, además de la imagen desplegada en Facebook utilizando las OG Tags que son las etiquetas creadas por el Open Graph Protocol para establecer semántica en web y buscadores web; muchos sitios costarricenses no lo tienen o lo tenían mal aplicado por lo que considero que fuimos unos de los primeros sitios en lograrlo bien, ya que a pesar que Facebook puede escanear las páginas web para obtener la información para sus links en publicaciones, muchas veces por estar mal etiquetado, el proceso se realizaba mal.

Cerca de terminar el sitio tuve una idea de reestructurar algunas partes del mismo y que si en algún momento se quisieran variar ciertas partes de la página web, se realizarían sin problemas; básicamente mi cambio era con respecto a los contenidos adheridos a cada artículo, por ejemplo, galerías de vídeos y de imágenes, ya que muchas veces el concepto de muchos sitios relaciona una galería con una sola página o publicación, en este caso, nuestros artículos eran las publicaciones, pero ¿qué sucedía si la misma galería se necesitaba en otra parte del sitio? bueno, la idea era no tener que crear otra, por lo que una forma sencilla de describir el cambio es que se agregó un campo especial para seleccionar una galería, cualquier galería, incluso más de una galería, ya que el visualizador SWF en la vista del usuario, tenia un combobox para seleccionar cualquier otra galería adicional; las galerías de vídeo, eran puestas en el diseño, bajo el contenido del texto. Lo hermoso de esto es que, podríamos agregar cualquier tipo de contenido externo, incluso referencias a otros artículos, sin afectar el diseño del sitio, e inclusive, dándonos el poder de colocar estos elementos en otras posiciones si fuera necesario hacerlo a futuro, así que el diseño no depende de la estructura, y viceversa la estructura no depende del diseño. Este cambio me alivió de varios posibles posteriores dolores de cabeza que luego se hubieran presentado si no hubiera hecho este excelente cambio.

El sitio es enorme no solo en diseño -creado por Jorge Jimenez Peraza- si no también en su forma de desarrollo, por lo que considero que podría hablar por horas del sitio, pero hay tópicos mucho más importantes.

Como programador al terminar un sitio, programa, o aplicación, existe un gran sentimiento de gozo que lo compararía con casi cualquier proceso creativo artístico, es como dibujar, es como pintar, tu corazón se llena de gozo y puedes decir "¡Yo hice esto!" y este fue un sentimiento general que tenía con el proyecto, un sentimiento de lo que hacía era perfecto, y que estaba completamente seguro que a la gente le iba a gustar, ya que mi gozo y emoción superaban muchos proyectos en que había estado.

Parte de terminar un proyecto en programación, cualquier proyecto, es que te puedes desconectar casi inmediatamente de él y dejarlo andar solo, ya que técnicamente eso es un programa, un ente que te facilita la vida, evitándote muchos problemas; desgraciadamente, este fue un paso mal calculado con Voz Metropolitana. 5 meses de programación y búsqueda de talentos nacionales en periodismo, nos distrajo del una simulación real del proceso funcional del sitio; ya que el mismo día de la publicación del sitio nos vimos envueltos en revisión y publicación de artículos, lo que significaría por lo menos para mi, durante los últimos tres meses que permanecí en el proyecto, un ritual diario, sin descanso de revisión tras revisión, empezando a acortar el tiempo de producción para otros proyectos...

El sitio tenía un tráfico aceptable, mas no el suficiente para vender publicidad, aunque considero que nunca hicimos el esfuerzo suficiente para conseguir patrocinio esperando que estos números fueran más elevados... Siempre sentí que teníamos un compromiso con los periodistas, ya que parte del plan era que apenas tuviéramos un poco de ingreso, este iba a ser principalmente para ellos, también la intención era hacer publirreportajes y venderlos bien y de igual forma dirigir estos ingresos a quienes mantenían el sitio funcionando, pero el hecho es que esto jamás se dio. Más tarde tuve una idea que discutí con Jorge para generar ingresos, ciertamente el modelo de negocio es todo en un sitio nuevo, así que mi idea consistía en que era evidente que nosotros no podíamos buscar los patrocinadores, pero era más probable que los mismos periodistas buscaran para sus artículos, así ellos generaría un buen volumen de artículos -lo que posiblemente generaría contenido basura a futuro- pero costearía su trabajo. El proceso en sí, tiene ciertas dificultades como de qué forma cobrar, cuanto cobrar, qué porcentaje nos dejaríamos -aunque Jorge y yo estábamos conscientes que lo mejor era dar la mayoría a ellos, cerca del 90%- en sí misma esta idea tal vez requeriría de otro sitio para administrar estos procesos, pero abría las puertas para que periodistas de muchos países pudieran entrar. Obviamente luego de mi partida esto jamás se concretó. Creo que es una buena idea que cualquiera en Costa Rica podría aprovechar, ya saben, las ideas son gratis, y se la dejo a cualquiera que quiera intentarlo, ya que para mi, las ideas no valen nada por si solas, lo que vale es cuando las desarrollas.

A Voz Metropolitana lo considero un éxito y un fracaso a la vez, a pesar que el sitio sigue funcionando a medias, su mantenimiento es sobre humano, y requiere de un equipo profesional y bien pagado de personas que se ocupen exclusivamente a revisar artículos, considero que a la fecha de hoy no ha tenido la recepción que esperábamos ya que como siempre he dicho, lo mejor es darle a poquitos las cosas a las personas, para que vayan digiriendo cada concepto y luego que se acostumbren, pero teníamos tanta fe en el producto, y sentíamos muy profundamente en nuestro propio ego que iba ser un éxito, que no pensamos en el usuario. Actualmente está demostrado que los startups deben ser lanzados poco a poco, esto para sentir o percibir si el usuario está interesado en tu producto, si el usuario no está interesado, ahorraste tu tiempo y tu dinero. Apuesto que usted dirá "esto no es cierto, si tienes fe en tu proyecto, seguro tendrá éxito", pues le tengo malas noticias, a la gente no le interesa si a usted le gusta su propio producto o no, a la gente lo que le interesa es si lo van a usar, si les parecerá útil, y lo viví luego con un proyecto experimental, otro emprendimiento sobre el que ya escribí, y sobre el que creo que es mejor hacer las cosas así, hacer las cosas sin esperar si va a tener éxito o no, claro, hacerlas bien eso sí, pero si falla no hay nada que lamentar, y si tiene éxito, retomarlo, mejorarlo y continuarlo en tanto la gente lo quiera.

Me quedan muchas enseñanzas con este proyecto, muchas me las reservo para mi mismo, y estoy seguro que las aplicaré en cualquier nuevo proyecto como ya lo he hecho en unos cuantos que he tenido el chance de realizar después de mi salida.

Durante el 2010-2011 aparte de crecimiento como desarrollador en Drupal, decidí por cuenta propia aprender otras formas para desarrollar; entre esas AIR for Android.

Mi amplia experiencia en Actionscript 3 de Adobe, me permitió utilizar muchas de las ideas que he desarrollado en años anteriores para web, pero AIR for Android brinda la capacidad no solo de crear aplicaciones móviles por medio de puro y crudo código as3, sino que también permite utilizar el ya conocido Flex Framework y colocar componentes que permiten -aunque muy pesados actualmente- crear una interfaz para el usuario rápida y fácil de usar.

Durante mucho tiempo tuve la inquietud de crear una aplicación para Android que uniese la habilidad de ver algo en vivo por medio de imágenes o vídeo, pero nunca llegué a tener una idea que me gustara completamente. La idea que más me gustó se basó en un demo que hice aplicación que leía después de un número X de segundos, una ruta de una imagen estática, que era actualizada desde el servidor, por lo tanto el contenido siempre era diferente. Esta imagen podría ser entonces una de las tantas famosas cámaras web que hay en Internet, apuntando hacia algún lugar de interés del mundo.

La cámara que finalmente decidí para usar en su momento, fue la del Volcán Turrialba -ahora desconectada- que para enero del 2011 estaba muy activo y dio un buen espectáculo. Me pareció genial la idea de poder verla sin tener que estar conectado a una computadora de escritorio o portátil, y poder verla hasta en el bus camino al trabajo.

Así la aplicación se volvió un crudo experimento, mi primera aplicación en el Android Market en realidad, si a la gente le gustaba entonces podría continuar con ella. Era una mezcla de varios botones estándar y Views de Flex, pero cumplía su función, más tarde lo cambié a un bonito diseño tabulado en cuanto la aplicación tuvo más movimiento.

La primera versión me tomó aproximadamente una semana, cosa que me parece increíble para alguien que nunca había hecho una aplicación para Android; si hubiera tomado la decisión de usar alguna herramienta en Java, estoy seguro que aun estaría haciéndola a la fecha; de todas formas, sé que es necesario aprender Java para acceder todas las capacidades del hardware y por lo tanto es uno de mis propósitos a futuro.

Hasta el momento he encontrado dos desventajas al momento de crear aplicaciones con AIR for Android; la primera de ellas es que usa el plugin de AIR para funcionar -de la misma forma que ocupa en las aplicaciones de escritorio o flash en el navegador- lo que hace que si tu usuario no tiene instalado al momento de instalar tu aplicación, te lo solicitará, y que si resulta en una negación pues el usuario nunca instalará tu flamante aplicación; también se puede incluir AIR dentro de la misma aplicación, pero esto hace que la aplicación pese más al final. La otra desventaja radica más que todo en el uso de Flex, que si bien te permite hacer un hermoso diseño y rápido, incremente increíblemente el peso de la aplicación; mi segunda aplicación que solo contenía unas tablas Flex, terminó pesando 18MB, contra unos posibles 500KB que podría pesar si se hacía solo con código Actionscript 3.

La aplicación sin embargo cumple su propósito, y me hace pensar que si en algún momento tuviese algún calendario apretado con una aplicación en Android, esta es la opción más rápida y funcional para cumplir con la tarea eficientemente.

Si desea ver e instalar la aplicación en su dispositivo Android, siga el enlace en Referencias; deberá tener Android +2.2 y con AIR for Android que puede buscarlo en el Android Market.

El proyecto de Tendencias Mundiales es un demo que verifica la viabilidad del uso de JqueryMobile para aplicaciones en dispositivos móviles; así como la re-estructuración de un viejo proyecto en uno más moderno y útil. El proyecto capta información de Twitter de diferentes países de habla española y los promedia en Tiempo Real, esto sin la necesidad de tener una cuenta en Twitter para poder visualizarlo, brindándole al usuario información y noticias actualizadas, así como imágenes cuando están ocurriendo.

En ella podemos encontrar imágenes referentes a la región seleccionada, que van desde Costa Rica, Nicaragua, Argentina, Chile y Venezuela, hasta información del clima, y links más utilizados por los usuarios de Twitter en esos países.

Desde un punto de vista más técnico, la aplicación utiliza PHP en su backend; este se comunica con Twitter via API/REST y simplifica la información para las necesidades de la aplicación, cosa que beneficia la cantidad de datos que llegarán al usuario final; esta información es enviada via JSON. La aplicación se actualiza cada minuto, pero solo si hay un usuario mínimo conectado, ahorrando no solo solicitudes al servidor, sino también a el API de Twitter. Cada aplicación cliente (jQueryMobile) hace una solicitud por minuto al servidor para verificar que los datos se hayan actualizado; el servidor almacena en caché la información hecha en el último minuto, así que si el reloj de la aplicación cliente hace una solicitud de la información entre los puntos de actualización, éste le devolverá la última información almacenada, evitando así solicitudes innecesarias al API como se mencionó anteriormente.

El cache realizado está inspirado en el "PoorsmanCRON", no utiliza el sistema CRON del servidor, si no que, hace solicitudes basadas en si existe o no un usuario conectado. Cada que se hace una solicitud, la ultima fecha se almacena y los datos se almacenan en la forma que el usuario requiera, en este caso un simple archivo JSON, pero podría ser una INSERT a MySQL por ejemplo; si una solicitud se hace antes que el tiempo indicado por una constante de segundos finalice -en este caso 60- el código se redirecciona y selecciona cargar los datos de la forma que el programador requiera, en este caso de la misma forma en que se almacenó: JSON.