lunes, 18 de noviembre de 2013

Review of "CSS Fonts", by Eric A. Meyer from O'Reilly Media

0:09 by Rafael Flores · 0 comentarios

It's been a while since my last review, having changed jobs recently I've had to move away from front-end development and back to the "dark-side" of O.S., DBs and backend applications. However, a book like "CSS Fonts" is a very easy and short read.

If you are ever considering the use of CSS Fonts in any project (web, mobile...) this little one of 58 pages is a must. You will find no black magic here, but a great primer on how and where to add some CSS code and "hey presto!" have a much nicer looking web page. All using standards, everything from Font families, faces, weight, styles, etc. It even covers font matching, a rather unfrequent technique used to guarantee the most similar UI font experience on any user agent.
The book is full of little code bits that serve as good base for your own CSS stuff. I missed a more complete example, kind of a "walk through" sample showing what can be achieved with the use of CSS fonts (well, one can always revert to Google for that I guess). This makes this book more a quick-guide style than anything else.
Not much more to say, it's a short one you can read in a relaxed afternoon and since the book is all-standard, you will sure make use of some of it's contents sooner rather than later.

domingo, 21 de abril de 2013

100, 150... y contando!

23:45 by Rafael Flores · 0 comentarios

Cuando publiqué la App que mencionaba en mi anterior post (y que algunos habéis tenido la amabilidad de descargar y probar ¡muchas gracias!), pensé que sería interesante hacer otra entrada en mi blog cuando llegara a las 100 descargas activas (bueno, si llegaba...) comentando la experiencia que supone. No pretendo con ello decir que conozco la "fórmula del éxito" con esto ni mucho menos, sólo quiero anotar lo aprendido con la experiencia y si a alguien le sirve de algo, fenomenal!

Antes de seguir adelante, me voy a permitir "hinchar un poco el pecho" porque a día de hoy las estadísticas hasta ayer (Google siempre te da las estadísticas "a día de ayer") dicen que hay 158 instalaciones activas de la App, sobre un total de 214 instalaciones. Si bien toda estadística puede leerse de dos maneras, y la mala me dice que tengo un 25% de usuarios que no han encontrado lo suficientemente interesante la aplicación como para mantenerla en sus dispositivos, creo que me quedaré con la buena, la que me dice que 157 personas además de mí tienen la aplicación instalada. Para ser una App tan específica y creada con una herramienta tan básica como AppInventor, ¡creo que no está nada mal!

Y ahora que ya me he permitido meter mi cuñita, empiezo con lo aprendido:
  • Lo primero de todo es que se empieza "fuerte", no sólo en el ánimo, sino también en las descargas. En cuanto al ánimo me refiero a lo contento que se queda uno cuando empieza a ver que la gente se descarga tu aplicación, los primeros comentarios, las primeras valoraciones... La verdad es que da cierto "gustito" ver que realmente algo que has hecho como una especie de hobby, a ratos, para probar... resulta ser útil para algunas personas y que encima probablemente son más de las que te esperabas. Lo cierto es que eso es Internet: mucho más de lo que parece y un canal de comunicación enorme y disponible para todos. Esto te da mucha idea de hasta dónde realmente se puede llegar con esfuerzo (con esto quiero decir que ya hay un montón de ideas más en esta cabeza...).
  • La "fuerza en las descargas" es algo que ya está estudiado por mucha gente, y a fondo: el modelo típico empieza con una gráfica ascendente más o menos empinada, que dura no mucho tiempo, y a partir de ahí se llega a una "zona plana" donde se estabiliza la cosa: bien un poco hacia arriba si la App es buena y merece la pena "vivir", bien un poco hacia abajo si los usuarios poco a poco la van desinstalando con lo cual acabará "muriendo". En el caso concreto de "Código Penal Artículo 384" todavía parece que no he alcanzado ese plano, sigue teniendo una cierta tendencia incremental, pero muy suave (es decir, lentamente). Esto es algo que ya me esperaba, por tanto aunque los resultados eran buenos lo importante es que realmente cumplían mis expectativas. Ya dije en mi anterior post que esta App no es ninguna revolución, pero eso no quita para que me fijara un objetivo realizable de descargas (100), que es el que me interesaba ver cómo se cumplía. Con esto quiero decir que aunque siempre haya "hechos esperables" (cosas que pasarán sí o sí, tal y como muchos eruditos han estudiado y demostrado) lo importante es aprender sobre cómo suceden, si hay o no desviaciones, por qué se dan, si son corregibles/mejorables/deseables, etc. Como digo para mí todo este proceso de publicar una App es un proyecto de aprendizaje, por lo que ya sólo por esto estoy muy contento.
  • Al hilo de todo esto, hay que decir que la promoción bien hecha de la App siempre ayuda. Personalmente no he realizado una promoción activa de la App más allá de este blog y los enlaces que se generaron automáticamente en Twitter y Facebook cuando publiqué la entrada anterior (¿he dicho ya que no creo que sea una "killer-App"? :) ), pero me consta que el amigo que me pidió que la desarrollara sí que se ha tomado la molestia de publicar comentarios en foros que él visita, decírselo a más conocidos, etc. y de hecho en ocasiones podemos asociar los incrementos en las instalaciones a hechos concretos donde él ha promocionado la App. Lo cierto es que desarrollar una estrategia de promoción de la App puede ser no sólo interesante sino también necesario para lograr una buena cantidad de instalaciones. De hecho, ya existen en Internet cursos on line para aprender a desarrollar estas estrategias (por ejemplo este de Udemy), así que para determinadas Apps yo contemplaría esto como una parte del proyecto de desarrollo de las mismas.
  • En cuanto a temas más concretos, el hecho de tratarse de una App "de nicho" (para un conjunto muy específico de usuarios) tiene sus ventajas e inconvenientes. Por el lado de las desventajas: poca base de usuarios (si nos referimos al total de usuarios de smartphones, por ejemplo); temática de interés muy determinado; que estos usuarios no nos conozcan como un "desarrollador autorizado" (por así decirlo) al que merezca la pena considerar... Pero también tiene sus ventajas: si la App funciona bien, el "boca a boca" es más sencillo y efectivo; la posibilidad de detectar nuevas necesidades en este nicho que podamos satisfacer facilmente con otra App (esta podría ser de pago...); que pueda ser un sector "poco explotado"por otros desarrolladores donde poder crecer facilmente, etc... En definitiva: trabajar con un nicho tiene ventajas e inconvenientes, como todo. Es cuestión de cada uno querer ver la botella medio llena o medio vacía (yo ya sabéis cuál me quedo!).
  • Como esta App surgió como una "prueba de concepto" para un nicho concreto, me permití el lujo de utilizar AppInventor para su desarrollo. Esta herramienta originalmente la desarrolló Google pero hace un tiempo se la cedió al MIT (que es quien la mantiene actualmente), y es un ejemplo de cómo se puede construir software a base de bloques tipo puzzle. Por una parte AppInventor me ha resultado demasiado simple y en ocasiones poco estable para lo que yo quería realizar. Sin embargo, es cierto que lo que empecé diciendo que iba a hacer y lo que he acabado desarrollando es bastante diferente. Por tanto no diré que la herramienta es mala, sino que no la he usado para lo que está diseñada. Aún así, creo que la App resultante es bastante presentable y que con un poco de imaginación los problemas de AppInventor o sus limitaciones pueden ser solucionados. Además, tiene una ventaja adicional: ¡no hay ni un sólo fallo o "error no recuperable" registrado en la App! Y eso, dado el número de usuarios, es algo que está muy bien y debo agradecer a haber utilizado AppInventor. Eso sí, para todo lo demás... usaré algo más potente.
  • En cuanto a cosas que tengo pendientes, la principal (que espero cubrir en breve para sacar la versión 1.1) es proporcionar a los usuarios un mecanismo válido de soporte, a través de una página o portal Web. Esto, aunque tal y como he dicho antes la aplicación no presenta actualmente errores y pueda parecer innecesario, es muy importante no sólo desde el punto de vista del soporte en sí, sino de conocer a nuestros usuarios y poder interactuar con ellos: desde plantear cuestiones a través de la web a los que accedan a la misma para decidir qué nuevas características añadir a la App o qué nuevas App crear, a obtener datos analíticos de valor mediante herramientas como Google Analytics, CrazyEgg, etc. El motivo es muy simple: los datos siempre nos aportan valor y por tanto debemos registrarlos y, por supuesto, analizarlos. No hacerlo es un lujo que no nos podemos permitir en un mercado como Internet y las Apps.
  • Está claro que esto implica que también debemos esforzarnos en tener una web como Dios manda, con todo el trabajo que eso implica, lo cual puede parecer que nos aleja de nuestro objetivo inicial que era simplemente "hacer Apps"... Pero es que lo uno no puede ser sin lo otro, sería como dedicarse a hacer procesadores sin que tengan un ordenador donde funcionar... 
  • Por último, y esto lo añado tras las últimas lecturas que he hecho, está claro que dentro de las Apps también hay clases, y no me refiero al tema de cada una sino a su modelo de "negocio" (si lo tienen): una App gratuita probablemente tenga poco que ver con una App de pago, y tampoco con una "freemium" (las que son gratuitas pero que te ofrecen comprar algo en cuanto quieres avanzar; un ejemplo muy claro son la gran mayoría de Apps de juego actuales). Sin embargo creo que todos los pasos que se aprenden lanzando un App gratuita sí que son comunes en todos los demás casos.
Así que ahora tendré que plantearme conocer alguno de esos otros modelos de App...

Seguramente me habré dejado algo por comentar, así que si cualquiera de los lectores de este post quiere añadir algo más, ¡bienvenido será!



sábado, 30 de marzo de 2013

En marcha!

1:04 by Rafael Flores · 2 comentarios

Finalmente hoy he publicado mi primera App para Android en el market de Google, está disponible aquí.
La verdad es que me ha gustado hacerlo, me ha recordado buenas (y algo viejas ya) sensaciones, cuando creaba programas que servían para algo... Lo cierto, y lo que es mejor, es que he aprendido unas cuantas cosas en este "viaje", por lo que las anoto en este Blog para que no se me olviden.
Lo que comenzó siendo una POC (proof of concept) sencillita para un amigo, acabó cogiendo más cuerpo y complicándose según se me iban ocurriendo muchas mejoras para la idea inicial. Al final tuve que tomar una decisión y "parar de añadir mejoras" a algo que todavía no "existía" como tal. Ese es un fallo típico de los proyectos informáticos, que se debe que evitar: no definir claramente dónde parar. Es decir, qué tiene que tener el producto para que se "entregable" al menos en la versión actual. Y todo lo demás deberá ir en las siguientes versiones. O no hacerse, si el primer producto demuestra no ser bueno y no se sigue iterando en él. Esto sigue la línea básica de las Metodologías Ágiles: iterar, iterar, iterar... Eso sí, si uno es creativo lo mejor es tener a mano una buena pizarra blanca para anotar todas las ideas/mejoras que se le van ocurriendo, y puntuarlas por interés o necesidad, para determinar en qué orden acometerlas.

Total, que en vez de hacer caso a mi amigo Mario López de Ávila y seguir su muy sabio consejo de crear siempre primero el producto MVP (Minimum Viable Product), alargué este desarrollo de una idea simple a un producto más completo. Bueno, el resultado desde luego ahora es muy útil, eso creo. Esa para mí es una de las premisas que debe cumplirse siempre: todo producto informático debe ser siempre útil. Será más o menos bonito, rápido, ligero, perfecto... pero siempre debe ser útil. Es decir: si nadie lo usaría para nada... ¿para qué usarlo? Para hacer porquería ya está la televisión... :D

Donde sí decidí aplicar la idea del MVP (tras darme cuenta de que había errado al no usarla en la App) fue en los "productos laterales": todo aquello que uno considera que tiene que tener, pero que no es "el producto" en sí. En mi caso era la necesidad de tener una presencia web, que creo que hoy en día es indispensable. Al principio me lié, quería montar una web guapa, con una plataforma de comunicación 2.0, enlazada con todo, rollo CMS, multilenguaje (hay que vender a todo el mundo, con lo cual inglés sí o sí)... Me lié a montar una en inglés con Drupal, otra en castellano con Joomla, una en Wordpress para aprenderlo también... Hasta que me di cuenta de que todo eso, para la App, eran "productos laterales" y sólo me ralentizaban. Así que, técnica de MVP para los "productos laterales": una web simple "uni-página" donde poner un email para contactos y consultas y punto. Eso sí, con el código de Google Analytics: los datos valen mucho siempre!!

Así que nada, la aventurilla está en marcha. Vamos a ver qué tal van las cosas estos días, y a ver qué más aprendo ahora!