Posts Categorized: development

Android, UX & GPS

Desde hace apenas unos días tengo un HTC Magic con Android (*with* Google) en mis manos y, si bien no quiero entrar en el debate iPhone vs. Android vs. Blackberry, voy a contar mis primeras experiencias de uso.

Lo principal, y lo que más me llamó la atención: el proceso de configuración.

Según enciendes por primera vez el móvil te pregunta si tienes cuenta en Google. Si sí, está claro, user and pass; de lo contrario, te ofrece la oportunidad de crearte una al vuelo.

Una vez te logas con usuario y contraseña … ya! eso es todo.
Como por arte de magia tu correo, tu agenda, tus contactos, tu *todo* está en el móvil.

Lógicamente un producto de Google se entiende perfectamente con la nube de Google, pero no así con las cosicas de Apple. Te las tendrás que ingeniar para sincronizar todos tus cacharros Mac con Google (que no es tarea fácil).

Las aplicaciones Android, como en su día ocurrió con las de iPhone, van siendo más numerosas cada día que pasa, aunque a nivel visual pierden bastante puntos. También parece que van mejorando con cada versión renovada.

Uno de los puntos fuertes de Android es la integración de GPS con Google Maps, un A+.
Y bajo esta categoría voy a destacar una aplicación parida desde el MIT y ganadora de del primer puesto del Android Dev Challenge ($275,000).

Locale es una aplicación que se tenía que haber inventado hace años. Se ha hablado mucho de la tecnología Bluetooth por proximidad y acciones configurables, pero esto es historia con el uso del GPS. Locale permite configurar tu dispositivo dependiendo de dónde te encuentres, habiendo especificado previamente tus sitios habituales.
Con esto puedes conseguir silenciar automáticamente el móvil en el cine, cambiar el tono de llamada en el trabajo, incluso adentrarte en el terreno de la domótica y encender las luces de casa cuando te aproximas a ella.
Esto supone que tu móvil se adapte automáticamente al sitio donde te encuentres o que éste ejecute ciertas acciones dependiendo de tu situación geográfica.

Con los mensajes automáticos a Twitter según tu situación geográfica, sé de muchos que podrán ahorrarse teclear cosas del tipo “en la T4”, “llegando a la oficina”, “en el baño”, …

Aprovechando la misma tecnología GPS, otra idea no menos brillante, son las tareas localizadas de GeoLife. Dependiendo de la ruta que tomes, por ejemplo volviendo a casa, puedes decirle a tu dispositivo que te recuerde pasar por el super, la farmacia o la panadería. – Please, Mr. Android, recuérdame que la próxima vez que pase por Callao compre un disco en la Fnac – podría ser una caso práctico y útil.

Sin intentar persuadirte de nada, sólo puedo recomendarte que si usas las aplicaciones básicas de Google en tu día a día, Android puede ser una opción (y puede que alternativa) más que recomendable.

Habiendo usado anteriormente un iPhone por un breve plazo de tiempo, mi experiencia de uso se equipara completamente. Las aplicaciones *útiles* están a la par, y Android ha calcado la interacción no patentada de Apple, por lo que lo estarás manipulando a nivel pro antes de lo que podrías imaginarte.

[wiki] Git, a Quick Start Guide

I’m writing this entry as a personal wiki page, just to note some tips and paste some code I’ll find around while I’m learning a little bit about Git. It will be growing and modifying day by day at same rhythm as my knowledge.

But, what the hell is Git?

Git is a version control Swiss army knife. A reliable versatile multipurpose revision control tool whose extraordinary flexibility makes it tricky to learn, let alone master.

The above quote is from one of the best reference sites I’ve seen about Git: Git Magic.

And, how to use it?

At first you should be able to play with Git, so if you’re running OSX, try this simple installer: Git OSX Installer. Now you should be able to run git from your Terminal in OSX. Yeah! Let’s try!
The next sequence of commands will be used now and again, so don’t be lazy and memorize them ;). It’ll start Git repo and add all the files on you project folder. Last command line is for your first commit!
$ git init
$ git add .
$ git commit -m "My first backup"

Ok, now it’s time to create, add, modify, remove files from your great personal project. How to do it? It’s simple.
$ git add newfiles_or_newfolders
$ git rm oldfiles_or_oldfolders
$ git mv oldfile newfile

The first one from above commads will add new files or folders to your git local copy. Second one will remove them. And, at least, mv will rename the files.

If something fails just type:
$ git reset --hard
$ git commit -a -m "Another backup"

It’ll go back to where you were and save a new state.

Each time you have a fucking-great-power-version you can commit the changes to show it to your friends. So, just type:
$ git commit -a -m "A new fucking-great-power-version"

For now it’s enough if your are, like me, a newbie at Git. With that simple lines of code you should be able to play around. Just create an account at github where you can host some open-source projects for free and look for me overthere.

Ok, if you have used SVN before, you can say: what’s new with Git? Nothing at all. Next time I’ll wrote some lines about the power of Git, but I have to learn it before :)

Feel free to comment and show me your tricks & tips about git. Sure they’ll be helpful for me and, please, remember I’m just a designer who wrote some lines of code sometimes, explain it for a dummy :D

skip photoshop

Jason Fried, de 37Signals, ha dejado en el blog corporativo una interesante reflexión sobre su metodología de trabajo. Aboga por un método non-photoshop a favor de un prototipado y diseño directamente en HTML/CSS.

Obliga al paso previo de sketcheado en papel, y anima a prototipar y diseñar con ejemplo reales, argumentando que todo lo que se vea en una pantalla debe ser clickable:

If it’s on your screen it should work

En parte puedo estar de acuerdo, sería un ideal, y es algo que llevamos a cabo en The Cocktail a medias (sólo a medias).

Cuando estás involucrado en proyecto para cliente tienes la obligación de iterar con el cliente. Asumir que vas a acertar con un diseño a la primera puede ser demasiado presuntuoso por tu parte. Para este grado de iteración, sin duda, es más rápido tirar de vectores.

Prototipar y diseñar en HTML/CSS es algo que sólo te puedes permitir cuando estés en perfecta sintonía con el cliente o estes trabajando para un proyecto de la casa.

Por no llevarle la contraria a Jason debo suscribir el título de su post: Why we skip photoshop, pero por motivos diferentes. En The Cocktail, y desde sus orígenes, nunca se ha usado Photoshop como herramienta de prototipado y diseño. Tras unos años de experiencia podemos argumentar y argumentamos que Fireworks, aún sin ser la herramienta perfecta, cumple con todas las necesidades básicas para poder desarrollar un proyecto sin echar en falta ninguna otra herramienta.

Photoshop queda relegado para el tratamiento fotográfico, Illustrator/Freehand para los vectores más complejos y, para todo lo demás, Fireworks.

  • El uso de vectores es real y básico, ni tan extremo como Illustrator ni tan fake como Photoshop.
  • Las herramientas son las justas para desarrollar un diseño moderado, sin excesos. Photoshop te invita al exceso de forma nativa.
  • Los textos son tratados como vectores, por lo que su manipulación es mucho más ligera. Photoshop convierte los textos en bitmaps, por lo que manejar grandes cantidades de textos se puede convertir en una pesadilla.
  • No tendrás problemas con la gestión de color porque trabaja de forma nativa con RGB, sin posibilidad de cambio.
  • El uso de librerías, paginas, frames, símbolos, 9-slice scaling guides, finalmente, la convierten en una herramienta excelente para nuestros fines.

Conclusión: Fireworks, aún sin poder decir que sea una herramienta perfecta, puedo afirmar que se trata de la mejor solución para el diseño de interacción e interfaz. Dependiendo del proyecto y sus características puede ser aún más ágil y versátil que iterar con HTML/CSS y cumple con todas las expectativas del resultado final.

Asumiendo tu buen criterio como diseñador / maquetador, me atrevería a afirmar que un 80% de las cosas que pudieras hacer con Fireworks son facilmente transportadas a código … ¿podríamos afirmar lo mismo sobre Photoshop?

Edito: A los pocos minutos de publicar este post y siguiendo en mi tarea de mantener al día mi GReader, encuentro un post de Stopdesign donde comenta y cita otras fuentes que mantienen un debate abierto sobre el tema. Una de las referencias es a John Hicks (Graphics Editor or Text Editor) también con un argumento en defensa de Fireworks. Interesante también leer el hilo de comentarios en todos los posts enlazados.

stressing out a bit right now

Mestoyquitando, sí, hace tiempo que no cuento a/en Twitter mis vergüenzas, pero no puedo evitar mirar por el ojo de la cerradura de vez en cuando para curiosear :)

Y lo que he visto hoy me ha gustado mucho:

twitter_tips.png

No es más que esa tontería del tooltip al pulsar sobre el enlace de “older”. En lugar de lanzarte a una página donde Twitter se lamenta de su estrés (cosa habitual últimamente), te avisa con un tooltip para que te quedes donde estás sin fracasar en tu navegación.

En más amigable y, al contrario que una página de error, se reciben de mejor agrado los petes de la aplicación por estrés.

Debería plantearme una solución similar en mí mismo. En lugar de gritar o llorar en una esquina cuando ya sea demasiado tarde, podría pegarme un post-it en la frente con un “animal estresado” bien explicativo :D