eduardomillan.com

Dicen que una vez que pruebas algo, no puedes parar. La iniciación con el HTC Desire me encantó, y ayer me puse a tocar un Xperia 8, que tengo por casa. La experiencia de usuario con la versión 1.6 de Android no puede ser más nefasta: control táctil insufrible, organización caótica… Cuando lo pruebas, casi te da la sensación de usar un Symbian actualizado. Así que manos a la obra…

Buscando aquí y allá, fui recopilando información (hay que ver lo que se echa de menos un tutorial con todos los pasos, sirva este post de repaso) y lo primero que había que hacer era actualizar a la 2.1 (aunque posiblemente pudiera funcionar el rooteo con la 1.6) mediante el software oficial de Sony-Ericsson (descargable desde su página). Como suele ser habitual, este tipo de software tiende a infumable malo, pero…

Con la 2.1 cargada (tal versión sigue siendo bastante parca) tocaba hacerse root. Para ello, había que instalar el programa superoneclick, conectar el teléfono al PC (sólo para carga, activando el modo debug por USB y con los drivers Android instalados) y darle al botón “root“. Después había que instalar el BusyBox y el xRecovery, transfieriendo varios archivos (reemplazándolos si existieran) según este tutorial (hasta el paso 6).

Por último, siguiendo los mismos pasos en el xRecovery que con el Desire (copiar la ROM a la tarjeta SD, limpiar datos y caché e instalar desde el zip copiado con la ROM), quedaría instalar la versión definitiva. Buscando en Google también se encuentran muchas, yo elegí GingerCyborg v005, con la 2.3.5 de Android y la verdad es que también parece funcionar de maravilla.

Ahora me queda probar en ambos dispositivos qué tal van las aplicaciones desarrolladas en Flex. En las versiones anteriores, entre los problemas con el espacio de la memoria interna y el rendimiento general de Adobe Air, se hacía prácticamente imposible hacer algo trabajado, que pudiera funcionar de forma fluida. A ver, a ver…

Últimamente, mi HTC Desire dejaba mucho que desear en cuanto al manejo. La versión del fabricante / operador (2.2 con el Sense) tenía sus carencias, pero en las últimas semanas, entre los avisos constantes de la falta de espacio (y la imposibilidad de enviar muchas apps a la tarjeta SD), los cuelgues varios y los errores en las aplicaciones… se estaba haciendo insufrible. Así que decidí actualizar mediante ROMs, pues Orange se lo toma con mucha calma…

El primer paso era rootear el sistema, es decir, adquirir privilegios de root para tocar cosas “avanzadas”. En xataka hay un tutorial bastante trabajado, yo me bajé el programa unrevoked, para Windows. Además, hay que bajarse e instalar los HBOOT drivers, pues si no la cosa “petará” (yo no lo hice a la primera y se quedó colgado, aunque reiniciando no había males mayores). Conectando el móvil al ordenador con el cable USB (y en el modo de sólo carga, si no dará un error también), había que ejecutar el programa, siguiendo los pasos de los tutoriales anteriores. Tras un par de reinicios, voilá…

El segundo paso era instalar la ROM. En algunas webs se recomendaba el uso de una app llamada ROM Manager, así que me instalé la versión gratuita. Está muy “chula” y tiene muchas opciones para hacer backups, instalar ROMs… La versión de pago permite bajar directamente las ROMs disponibles en un catálogo, pero para la gratuita hay que bajárselas de internet. Tras seguir todos los pasos, (en mi dispositivo la tecla para seleccionar una opción era el trackball), y copiando el ROM a la tarjeta SD… hecho!

Primero probé una ROM llamada Redux. No estaba nada mal, pero tras probarla un poco, me daba algunos fallos con el market. Así que con el mecanismo acortado de lanzar el recovery, borrar los datos y cargar la nueva ROM, intenté instalar una que recomendaba mucha gente, la Doxygen. Sin embargo, no me funcionaba, ni tan siquiera instalaba. Me bajé la Ginger Villain, y ésta sí arrancó. Tiene una interfaz muy atractiva, y parece que funciona sin problemas. ¡Y me está gustando mucho!

Buscando en Google también he visto que hay muchas compilaciones, y muchos listados, así que desde luego hay donde elegir, :D

La mala suerte no existe, no. O al menos no es la culpable de que un negocio vaya bien o mal. A menudo son fallos propios los que dan pie a esa supuesta mala suerte, que nos sirve como excusa para explicar por qué no estamos donde, según habíamos pensado, deberíamos estar. Es posible que ante una ejecución igual, puedan variar los resultados, pero un emprendendor no puede dejar cabos sueltos y esperar que la fortuna se los resuelva. Si algo no se ha hecho bien, ¿no deberíamos entonar el mea culpa? Está de moda echar balones fuera y culpar de todos los males a terceros. La crisis, las herramientas, el entorno, los medios… o la simple pregunta de ¿quién lo iba a imaginar? Y todo eso se acaba resumiendo en un “hemos tenido mala suerte“.

Pero esa entidad, mala o buena, tiende a no existir. Si se hacen las cosas bien, y los buenos resultados siguen sin salir, quizá es que no estaban tan bien hechas, o podían mejorar bastante. O tal vez un poco, lo suficiente para haber marcado la diferencia entre la “buena suerte” y la “mala suerte“. Si de algo hay que quejarse es de uno mismo, porque un emprendedor debe preveer las cosas y resolver los posibles contratiempos antes de que pasen. Y no, no debe hacer las cosas justas, esperando que la “potra” le sonría, y a que la falta de proactividad la complemente “su destino“. El emprendedor no puede ser mediocre, conformarse, dar el visto bueno a la primera. Ha de ser tenaz, estar siempre pensando en cómo mejorar lo ya hecho, en cómo repasar una y otra vez esa tarea para que quede, no bien, sino perfecta. Y tampoco puede lamentarse. Ha de aprender de los errores, para no volver a cometerlos. Ha de sobreponerse, buscar soluciones, mejorar.

La mala suerte no existe, es la excusa de los mediocres.

Los gestores de tareas es un tipo de software que para mí tiene mucha importancia, pues siempre que los he utilizado la mejora de la productividad y organización ha sido considerable. Unos me parecían mejores, otros más completos, otros peores… pero todos tenían un problema común: la necesidad de tener un subdominio o ubicación diferente de la del correo. Cuando Google Apps lanzó la tienda de aplicaciones, no le presté mucha importancia, hasta hace algunas semanas que me puse a examinar la oferta existente….

Google Apps me parece un servicio muy útil. Tienes una especie de intranet (wiki mediante los Sites, documentos colaborativos mediante los Docs, el calendario corporativo…) dentro del mismo núcleo donde tienes el correo, así que a nivel operativo resulta muy atrayente tener todo ubicado en un mismo sitio. Y si además añadimos la posibilidad de tener un gestor de tareas también integrado en la plataforma…

GQueues es la primera app que probé. Es un gestor de tareas muy sencillo, con una interfaz muy amigable, y orientada al nuevo look de Google Apps. La versión lite, tiene bastante funcionalidad, aunque se puede quedar muy corta por el hecho de que no permite asignaciones (y, por tanto, aviso mediante emails de la asignación de nueva tarea a un usuario). Comentando más cosas,

Mola

• Crear tareas y subtareas. Una tarea puede dividirse en partes más pequeñas asociadas a otros usuarios…. así que, ¡genial!.
• Asignar etiquetas, para hacer filtros, búsquedas… o que quede más claro de qué va una tarea…
• La versión de pago, integra perfectamente los hitos y fechas con el calendario de Google Apps…
• Hay colas y categorías, de tal manera que puedes tener una jerarquía y ordenar por proyectos y áreas, por ejemplo…
• Drag & Drop de items, asignación de colores a categorías… la UX es muy buena.

Puesto que el fin de año está cerca, será propicio hacer el correspondiente balance, y seguro que entre las metas para el 2012 está volver a tener una buena frecuencia de actualización del blog. La verdad es que siempre digo lo mismo, y a pesar de que haya cosas que compartir o de las que expresar mi opinión, la falta de tiempo tiende a hacer estragos y siempre se acaban produciendo grandes periodos de inactividad. En resumen, a ver si esta vez no. Esperémoslo ;)

Este fin de semana he participado por tercer año consecutivo en el Global Game Jam, una “compo” a nivel mundial de 48 horas. El último día, en el grupo comentamos las cosas que no se deben hacer en una compo del estilo. Gorka, uno de los compañeros, ha publicado ya una versión más que recomendable y muy completa, así que recalcaré algunas cosas y añadiré alguna otra. Ahí va,

Gameplay: el objetivo es tener un programa jugable. Es decir, el “core” es la jugabilidad o gameplay. Por eso mismo, hay que comenzar pensando en cómo se va a jugar a nuestro juego, cuál va a ser su base de interacción con el jugador. La historia, el interfaz… es relleno, y se puede fijar o adaptar más adelante, sobre la marcha incluso, pero nuestro “core” debe ser diseñado lo primero.

Descarta ideas. La idea del juego debe ser realmente sencilla, explicable y comprendible en menos de 30 segundos, a lo sumo. Hay que empezar por definir una mecánica base y principal, que debe ser suficiente para jugar. Las posibles mecánicas extra, se deben ir añadiendo en función del tiempo sobrante, pudiendo prescindir de ellas sin problema. Con esta premisa, la idea debe estar muy ajustada al tiempo, y debe ser desarrollable (aka estimación fiable) por un sólo programador en la mitad del tiempo dado (si son 48 horas, se tendría que poder hacer en menos de 25..). Hay géneros que tienden a no encajar en esto, como RTS, TBG, aventura gráfica… (en general todo lo que implique mucha IA, física compleja..) así que hay que descartarlos a priori o darlos tanto la vuelta que apenas parezcan ese género. Eso significa que hay que darle muchas vueltas y descartar más y más hasta tener una idea factible (y a ser posible, original!), sobre la que maquillar un diseño. Y no se programa hasta que esto no se tenga claro.

GDD, máximo un folio. Si hemos hecho bien los dos primeros puntos, deberíamos ser capaces de tener nuestro documento de diseño en tan sólo un folio. Sencillo, entendible, ágil. Si alguien tiene una duda, se lo preguntará al productor (leer punto siguiente) o directamente lo verá en un golpe de vista. No hay tiempo para leer El Quijote! ;)

Productor = diseñador. En desarrollos largos / que conlleven muchas personas, es normal y necesario que diseñador y productor no sean la misma persona. Pero en una compo, tener esos dos perfiles separados es un error y un despilfarro de recursos humanos. El producer debe estar pendiente del game designer, “pactando” con él cada tema, algo nada eficiente con un tiempo más que escaso. La comunicación y la escucha es vital en el equipo y si hay un game designer y un producer, tiende a difuminarse mucho, por la definición de ambos perfiles. Una misma persona puede encargarse de ambos roles, tanto por carga de trabajo como por ser complementarios, y será mucho más productivo a la hora de repartir tareas, ajustar el diseño, coordinar los hitos y comunicar cambios…

Código funcional, que no atractivo. Cuando hay que centrarse en tener algo operativo, no hay tiempo para currarse el código. La arquitectura deberá ser tan simple, que hasta el programador más newbie pueda entenderlo, replicarlo, añadir cosas… y debe ser totalmente modular. Si hay más de un programador, uno será quien lleve el peso, la estructura general y el gameplay. El otro, se encargará de los menús, la UI, las funciones de mecánicas secundarias…  y todo tiene que encajar sin perder horas tratando de integrar o descifrando la arquitectura. Si sólo hay un programador, habrá que reducir al mínimo todo lo que no sea gameplay básico.

Lo más óptimo suele ser tener un equipo formado por un grafista, dos programadores y un diseñador / productor. No siempre es posible, y esto puede variar mucho, pero algo que hay que tener muy claro es que hay que adaptar el juego a los perfiles con los que se cuenta. No tiene sentido hacer un juego cuya base son las animaciones “chulas” si no tenemos grafista, o un juego con cierta complejidad en la mecánica si solo hay un programador y apenas tiene experiencia… Parece obvio, pero in situ se suele pasar por alto hasta que es demasiado tarde…

Por último, las primeras tareas están muy definidas: juntar a todo el equipo para la tormenta de ideas, sobre la que decidir y descartar. Con el esbozo de la idea en mente, el productor se pondrá a diseñar el esqueleto, a darle forma al diseño, a tareas logísticas (svn, cuentas…) mientras que el programador comenzará con la base del programa y el artista a probar con el look&feel. Con la base definida, ir refinando de forma iterativa… Resumiendo todo en tres palabras, producir, ajustar y gameplay. ;)

Al poco tiempo de comenzar a desarrollar el Zombie Master: Typing Trainer (juego más adictivo de la Imagine Mobile de Microsoft!) publiqué un post con las primeras impresiones sobre la plataforma. Con la segunda parte publicada (Zombie Master: Brain Trainer) y Snowflakes (juego ganador del concurso @meetapp) también disponible desde hace alguna semana, toca seguir comentando detalles acerca del desarrollo / publicación para los dispositivos con Windows Phone 7.

Segmentación. WP7 presume de no tener segmentación alguna. Un mismo .xap (el archivo comprimido de la aplicación) debería funcionar exactamente igual en cualquier dispositivo pero para hacerlo funcionar en el prototipo de Samsung y en los HTC, tuve que hacer algunos retoques al código. No daba error, ni excepciones, pero al iniciar el juego, “petaba“. Tocando allí y allá, se producían resultados dispares: “pete” al iniciar desde el teléfono pero no desde el compilador, que funcionase bien al darle a reanudar… Indagando y haciendo más pruebas, llegué a la conclusión de que los problemas se debían a un asunto de memoria, que en algunos terminales no debe estar muy pulida su gestión y hay que optimizar al máximo. Y, por otro lado,  algunos HTC tienen problemas extra con el driver de sonido…

Certificación. Hemos tenido varios “failed” en el proceso de certificación de las apps, debido a pequeñas “chorradas”. En algunos casos, sin embargo, fueron pasadas por alto y actualizamos a posteriori, pero no deja de ser curioso que la aprobación a la primera depende mucho de la “suerte”. Cuando se falla, se recibe un informe con las cosas a pulir, casi siempre muy concretas. En cuanto a rapidez, de 3 a 5 días parece lo normal…

Marketplace. El hecho de no tener una mínima interfaz web donde verlo (como tiene Apple) es un handicap importante, sobre todo a la hora de compartir el enlace directo del market, que sólo funcionará desde IE y con Zune instalado (Existen páginas que recopilan la info del marketplace, pero queda muy raro no tener un sitio oficial de Microsoft). Y desde el teléfono, no me gusta cómo está organizado, a nivel gráfico y estructural se ve bastante “pobre”, demasiado “simplón”. El punto más a favor es que todavía la aglomeración de apps no es excesiva, y puede dar lugar a una oportunidad. El estar en “novedades” es vital, pero si justo cuando tú publicas, al rato, salen muchas otras apps… el mismo problema de siempre, caerás pronto en el olvido…

Ventas. El otro día leía que se habían alcanzado el millón y medio de Windows Phone 7 vendidos, aunque en España esa cifra tiende a cero. Sobre las descargas, se sigue notando mucho la diferencia entre “gratis” y “de pago”, aun con el sistema de prueba o trial. Microsoft “penaliza” las apps gratuitas (con una licencia, sólo puedes publicar 5) y el sistema de publicidad no está muy potenciado (la api de Microsoft es exclusiva para desarrolladores de USA), así que la estrategia es un poco que la versión trial sea la versión gratuita, y la compra añada funcionalidades premium. Pero sigue siendo difícil la conversión…

Panel de control: desde hace poco funciona el reporte de estadísticas, que tiene una semana de retraso (ves datos de hace una semana para atrás). Tampoco es que sea muy específico, pero si tiene la funcionalidad indispensable: descargas, ventas… echando de menos algún filtro que otro… (ratio de conversión, terminales… y cosas del estilo).

Apoyo. El apoyo de Microsoft para el desarrollo ha sido muy importante. Permitirnos hacer testing en sus oficinas / aula de la politécnica, los concursos, el soporte por email…  nada que ver con Apple. ;)

pd.- Y a todo esto, felices fiestas! ;)

Cumplidas las primeras semanas con el HTC Desire y, pasando por tanto a Android como móvil primario, toca hacer una revisión de ambas plataformas. En general, como usuario, Android me gusta, pero tiene muchos “handicaps“…

Gana Android (aka me gusta)

Aunque la usabilidad no es el fuerte, y todavía hay ciertas carencias de aplicaciones, la flexibilidad del sistema me parece un acierto. Muchas funcionalidades, como

• Notificaciones. La pantalla donde se reportan todas las notificaciones (desde menciones en twitter, updates de las apps, mails…) es muy útil.
• Carpetas. Aunque el nuevo iPhone también lo permite, es muy cómodo para ordenar las apps cuando comienzas a tener muchas de todo tipo.
• Themes. Tener como varias configuraciones en las pantallas / dashboards en base a temas, también es síntoma de potencia. Yo no lo uso, pero sí lo considero muy interesante, sobre todo al acortar de alguna manera el proceso de cambiar de uno a otro.
• Control. Sin el root se tiene mucho control de procesos, estados y demás, algo valorable. :D
• Efectos. No deja de ser una “pijada“, pero hay efectos gráficos “molones“, como el widget del tiempo.
• SMS. Los mensajes de texto están más a mano, con una pantalla dedicada. :D Idem el correo, aunque al igual que con iPhone, parece rayarse al querer meter más de una cuenta exchange…

Gana iPhone (aka no me gusta)

El punto más en contra, sin duda, está relacionado con la experiencia de usuario. Siempre que tocaba un móvil con Android, me perdía. Y adoptándolo como sistema primario, no fue menos. A todo se acostumbra uno, pero los primeros días uno se siente algo perdido, cosa que con iPhone no pasa. En relación a ello, hace alguna semana twiteaba..

Si iPhone es el amigo de los niños, Android es el amigo de los ingenieros.

En cuanto a puntos más concretos, por ejemplo,

• En un dispositivo táctil, más de un botón para gestionar la navegación, sobra. Todo ha de ser interfaz y usabilidad. Despista mucho el uso de botones para acceder a los menús, volver atrás o subir un nivel… También te esperas que el botón de home sirva para volver activo el teléfono… pero se activa con el botón de encendido… y algunas otras cosas del estilo. Y al trackpad no le encuentro utilidad alguna..
• Para desinstalar una app, hay que recorrer demasiados menús… Idem para encontrar otras cosas relativas a configuración.
• Que el navegador por defecto no recuerde las pestañas abiertas cuando te has quedado sin batería es algo…
• El aumento / bajada del volumen del ring… no parece poder ser cambiado sin hacer el unlock. Un poco incordio!
• Teclado. Será por la configuración tal vez, pero me resulta mucho más cómodo escribir en iPhone, parece que va bastante más “fino”.
• Landscape / Portrait. La orientación sólo funciona a un lado… no es especialmente grave, pero es otro detalle…

En otro post, tocará la comparativa desde el punto de vista de desarrollador…

Últimamente vengo observando ciertas prácticas nada recomendables, y me parece curioso el punto común de los “practicantes”: inmigrantes analógicos recién llegados al medio digital. Con este “palabro” me refiero a las personas que han adoptado internet como medio “ajeno” o como una oportunidad más, en contraposición a los nativos digitales, que han nacido o se han metido en el mundo digital desde sus inicios, evolucionando con él. (Por supuesto, sin connotaciones despectivas ;)

El caso es que la práctica observada consiste en registrarse en una red social (vertical o profesional, de forma mayoritaria), meterse en grupos y postear en ellos siempre los mismos mensajes, como si se tratara de un bot. En algunas ocasiones los mensajes son “spam” camuflado, preguntando o argumentando las bondades acerca de un producto / servicio que, curiosamente, su empresa ofrece, pero sin el mínimo tono de debate. Y en otras ocasiones, el anuncio es directo, sin ningún maquillaje.

Igual que con el spam masivo al correo, es algo que causa muy mala impresión. Es molesto, demuestra una obsesión (o desesperación) por vender y no contribuye a generar una buena imagen ni a dar pie al networking. Eso no es (un buen) marketing…

Si hay algo que puede resumir una buena o mala impresión de un producto, es la “experiencia de usuario“, (User Xperience ó UX). El término parece estar muy de moda, y es un concepto muy amplio, pero se traduce en ponérselo muy fácil, en todos los sentidos, al usuario. Que sea el aunténtico protagonista, que tenga el control, que sepa todo cuánto está haciendo sin volverse loco… Que cuando termine de usarlo, tenga una sonrisa en la cara, esté feliz.

Convertir al usuario en el rey, puede suponer la ventaja abismal entre un producto y otro, a pesar de que el menos usable tenga más funcionalidad y sea más potente. Pero si la gente no sabe usarlo, o le supone un “trauma“, no contará con una aceptación comparable al que, con menos capacidad, es una gozada de manejo. Y esto es aplicable a muchos ámbitos, incluso a una empresa de servicios, convirtiendo la experiencia de usuario en “experiencia de cliente“. Y un usuario / cliente enamorado puede ser el mejor marketing para una marca (los fanboys de Apple, por ejemplo).

Sin embargo, hay infinidad de casos en que es un auténtico suplicio tener esa buena experiencia, rozando en muchos casos lo ilógico. Hace alguna semana entré en una web para comprar unas entradas, que solicitaba el registro. ¿Registro para comprar, una vez puntual? ¿Al menos que sea opcional, no? Después de todo ello, una ventana detrás de otra, más datos… la página “peta” y he de rellenar el formulario de nuevo, funcionando finalmente, pero tras perder mucho tiempo y con un “mosqueo” importante. Si no hubiese sido “vital” a nivel personal, hubiera desistido.  Y el otro día, misma intención en otra página, pero sin resultado eficaz ni eficiente, por un proceso de pago traumático. Resultado: no hay compra.

Hará una semana, Orange me dejó 6 días sin teléfono. Hicieron la portabilidad puntuales, pero se equivocaron con el envío (pérdida de contratos). Mil llamadas a mil números, donde nadie solucionó nada. A base de insistir, por fin llega, pero sólo con una copia del contrato (fotocopias!). La sensación de “chapuza” tiende a infinito.

Como usuario, otra cosa que me llama la atención, es los botones en los smartphones táctiles. Si un dispositivo es táctil, más de un botón (que no sea teclado querty, que puede resultar más cómodo o el silenciador) sobra; se supone que toda la gestión del interfaz (como volver atrás, sacar las búsquedas…) debe ser a través de la pantalla.

Por lo que voy observando, parece que cada vez más se va contando con profesionales dedicados a estudiar la UX, al menos en startups de internet. E incluso he conocido alguna empresa dedicada a ofrecer servicios de consultoría en este campo. Aka puede ser una especialidad de futuro…