Encuestas

Los departamentos de informática, aunque a veces no nos demos cuenta, nacen con una evidente y destacada vocación de servicio al usuario. Nosotros no somos el fin, sino el medio. Una herramienta que la empresa, sea cual sea su área de negocio (administración, salud, energía, investigación, docencia...), pone a disposición de sus empleados para facilitar la consecución de sus objetivos.

Muchas veces los departamentos de informática nos perdemos en nuestras pequeñas guerras tecnológicas, y nos olvidamos de que nuestra finalidad principal es facilitar el trabajo de los usuarios. Esto puede llevarnos a perder el rumbo y a provocar en ellos una perjudicial sensación de insatisfacción con nuestros servicios.

Me refiero a que es habitual encontrar a todo un equipo centrado en implantar un maravilloso entorno de desarrollo, con un servidor de integración continua, herramientas de control de código, fastuosos servidores de aplicaciones y demás parafernalia, mientras un usuario lleva varios días esperando que se le cree una cuenta de correo electrónico, que es lo único que necesita para trabajar.

Como proveedores de servicios informáticos es nuestro deber adecuarnos a las necesidades de los usuarios y hacer todo lo posible por satisfacerlas, ya que ese es el verdadero indicador que nos dirá cómo estamos haciendo nuestro trabajo.

Y no existe mejor forma de saber hasta qué punto está satisfecho el usuario que preguntarle a él mismo. Ahí es donde las encuestas pueden ser útiles para nosotros.

Recoger información de un grupo de personas es una tarea muy difícil. Si uno se pone manos a la obra se encontrará con gente para la que nunca es un buen momento, gente que prefiere no opinar, gente que responde cualquier cosa para cumplir, gente que piensa que dar su opinión es una tontería... el caso es que al final obtener la información lleva lo suyo, así que es muy importante hacer las cosas bien para conseguir resultados útiles.

Así que hay una serie de claves que se deben tener en cuenta para tener éxito con los sondeos a usuarios.

Lo primero, y más importante: ¿Qué quiero saber? Esta es la clave y, posiblemente, el punto en el que debamos detenernos más tiempo. Aunque suene redundante, tenemos que saber qué queremos saber. Y tenemos que saberlo de forma concreta, claro. No vale con decir que quiero saber qué es lo que el usuario piensa de mi trabajo; hay que ser más concretos, ¿qué aspectos de mi trabajo quiero que se valoren? Pongamos un ejemplo.

- Quiero saber si mis usuarios están satisfechos con el tiempo de respuesta a sus peticiones.

- Quiero saber si mis usuarios están satisfechos con la calidad de las respuestas.

- Quiero saber si mis usuarios están satisfechos con el trato ofrecido por mi equipo.

- Quiero saber si mis usuarios están satisfechos con las herramienta puesta a su disposición para notificar incidencias.

- Etcétera, etcétera.

Tan importante como identificar qué quiero saber es reconocer qué no me interesa, para ajustar lo máximo el tiro. Si estoy valorando la posibilidad de cambiar mi gestor de incidencias por una herramienta más barata, pero que elimina alguna funcionalidad, como por ejemplo la notificación por correo, en lugar de la última línea lo adecuado sería preguntar: ¿sigue usted las notificaciones por correo electrónico de sus incidencias? ¿echaría de menos esta funcionalidad? Quizá nos sorprendamos al ver que la mayoría de los usuarios tienen marcados como spam lo correos del gestor de incidencias.

Lo siguiente es tener claro que al usuario hay que ponérselo fácil. Olvidémonos por supuesto de pasarnos a hablar cara a cara con cada uno de ellos, o de pasarles un cuestionario en papel. Al día siguiente todos estarían perdidos entre montañas de formularios. Hoy las encuestas online son la mejor opción. Colguémosla, demos acceso sin contraseña, y dejémosla ahí durante un periodo de tiempo suficientemente grande. Y, por supuesto, promocionémosla; empujemos a la gente a perder 5 minutos de su tiempo. Seamos pesados si es necesario, ya que este tipo de peticiones suele caer en saco roto la primera vez. Y si todo esto falla, sorteemos un iPad entre los participantes. Nada mejor para que te hagan caso.

Y por último, e importántisimo también, esa gran palabra, el feedback. Demos feedback. Ya que los usuarios han perdido un rato en satisfacernos, dejémosles conocer los resultados, comentemos las conclusiones, y hagamos públicas las actuaciones aprobadas. Todo dentro de plazos razonables. Es muy probable que el ver que sus opiniones han significado cambios percibibles les impulse a participar en próximas ocasiones.

Y ahora, digan, ¿les ha parecido interesante el post? ;)

Configurar barras de progreso en Android

En estas primeras horas de mi andadura con Android me he encontrado un gran problema a la hora de trabajar con las barras de progreso.

Como ya comenté, la idea que tengo entre manos es desarrollar un juego para foguearme con la tecnología, y necesito mostrar en pantalla varias barras de progreso. Lógicamente interesa que no sean todas iguales, para que se pueda identificar cada una de ellas con lo que expresa. El caso más típico es el de mostrar la vida con una barra roja, por ejemplo.

El primer paso es definir el tipo de barra de progreso. Por defecto Android trabaja con barras circulares (o barras paradójicas). Para utilizar barras de verdad, tenemos que indicar explícitamente el valor del atributo style del elemento ProgressBar del fichero de layout que estemos utilizando (main.xml, o el que corresponda).

Sí, el valor es así de raro, y agradezco enormemente a Daniel Yankowsky el aporte.

Lo siguiente que nos plantearemos normalmente, ahora que tenemos la barra, es cómo cambiarle el color. El amarillo sobre gris está muy bien, pero hay todo un mundo más allá. En este caso vamos a necesitar crear un nuevo fichero, que ubicaremos en la carpeta res/drawable, y llamaremos progress.xml (por poner). El fichero tendremos que crearlo directamente desde el sistema operativo, y en él podemos definir con mayor detalle el estilo de la barra de progreso, mediante el siguiente código:

En este caso tenemos dos items, que se corresponden con el fondo y el progreso de la barra. Se podría añadir otro elemento secondaryProgress si lo necesitásemos. Para cada elemento se configura el radio de las esquinas, para que queden redondeadas, y se añade un gradiente, para que el color no sea uniforme, sino una degradación de los tres indicados. El ángulo indica cómo se aplica el gradiente (0 para hacerlo en horizontal, y 270 para vertical). Respecto al color, se identifica mediante ocho dígitos hexadecimales, donde los dos primeros indican la transparencia.

Existen otras opciones como poner relleno, y están bastante bien descritas aquí.

El último detalle que puede ayudar a personalizar la barra es el tamaño. En mi caso me interesaba presentar barras más finas para determinada información. Para conseguir este resultado nos vamos de nuevo al fichero de layout, y añadimos los atributos maxHeight y minHeight.

De esta forma conseguimos barras con distintas presentaciones. Como muestra, una captura (botones no me quedan ahora mismo).

Hope this helps!

Android TIP: refrescar recursos

En las últimas semanas he empezado a meterme en el mundo de Android con la idea de hacer algunas pequeñas aplicaciones, y poder publicarlas en el market.

Como punto de partida me he marcado el objetivo de crear un juego, y aprender así a manejarme con el entorno y herramientas de desarrollo. En futuros posts iré dando más detalles sobre el proyecto (si puede llegar a tener esa categoría). De momento, simplemente una pequeña ayuda para reducir tiempos de espera al trabajar.

Uno de los principales problemas que le veo al desarrollo para Android con Eclipse, mediante el plugin ADT, es que el emulador es bastante lento, sobre todo a la hora de arrancar, y en ocasiones puede hacerte perder la paciencia.

Si estás desarrollando una aplicación, y especialmente si es un juego, es normal que manejes ficheros de recursos, y concretamente imágenes. Y también es normal que las modifiques a menudo para ir metiendo mejoras en el apartado gráfico. Ante una situación de cambio en cualquier fuente del proyecto durante el desarrollo, siempre surge la duda de qué hay que hacer para que ésta se refleje en nuestra ejecución. ¿Compilo? ¿Redespliego? ¿Simplemente guardo? ¿Reinicio el ordenador?

Depende de con qué estés desarrollando. En el caso de Android, hasta donde sé, si haces un cambio en el código, simplemente tienes que volver a ejecutar la aplicación, pero no el emulador. Sin embargo, esto no es suficiente cuando el cambio se hace en un fichero de recursos. No vale ejecutar la aplicación, ni tampoco reiniciar el emulador, si no has refrescado antes la carpeta de recursos. Esto lo hacemos desde el explorador de paquetes, con el menú contextual.

Tras el refresco sí que podemos ejecutar de nuevo sobre el emulador que tengamos arrancado, y veremos que los cambios han sido aplicados.

Tutorial de GMF

El desarrollo guiado por modelos, o Model Driven Development, o MDD, es una forma de desarrollar software basada en la idea de que podemos obtener el código fuente directamente a partir de la definición de modelos, sin necesidad de codificar (o reduciendo lo más posible esta fase). En otras palabras, lo que pretendemos es centrarnos en la definición a alto nivel de la solución, y obtener su implementación concreta por medio de sistemas automáticos.

Un concepto inexorablemente relacionado es el de lenguaje especifico del dominio (DSL, Domain Specific Language). Es difícil explicar qué es un DSL siguiendo la norma de que lo definido no puede ser utilizado en la definición, dado que en este caso el término tiene un nivel de autodescripción más que suficiente. Pero bueno, podríamos decir que un DSL sería una especificación o técnica de representación pensada para un contexto o problema concreto.

En cualquier caso, para profundizar en estas ideas y ver en qué se traducen a nivel práctico, adjunto a este post ofrezco un tutorial en el que se muestra un ejemplo de uso de la herramienta GMF (Graphical Modeling Framework). Este plugin permite crear editores gráficos para Eclipse y, en conjunción con Mofscript, generar código a partir de lo modelado con ellas.

Aquí el tutorial, en el que estreno además mi nueva identidad corporativa.

Identidad corporativa

Una manzana mordida.

Una taza de café humeante.

Un caballo encabritado.

Una bandera de cuatro colores.

¿¿Te dicen algo??

¿¿Y ahora??

Seguro que has tardado poco en identificar cada uno de estos objetos con la marca a la que representan, claro.

Esto se debe a que todas las grandes empresas, y buena parte de las pequeñas, tienen bien definida su identidad corporativa. Básicamente la identidad corporativa es el conjunto de imágenes, tipos de letras, colores, etc., que una empresa utiliza y la hace reconocible frente a cualquier otra.

El elemento central suele ser el logotipo, pero no se reduce unicamente a eso. Un manual de identidad corporativa incluye también los tipos de letra, tamaños, colores, distribución de información, y todo lo que se te pueda ocurrir, que se debe utilizar para cualquier comunicación que provenga de la empresa.

¿Y todo esto para qué? Pues para obtener reconocimiento. Lo que consigue la empresa es que se le identifique rápidamente; que cuando veas un deportivo rojo pasar a 200 por hora y atisbes un caballo en su frontal digas: pedazo de ferrari. O que cuando estés trabajando con un programa y veas una tacita de café sepas: basado en tecnología Java. O, por qué no, que cuando veas una pantalla de ordenador con fondo azul y letras blancas pienses: estos de Windows...

Porque lograr una identidad corporativa es lo que tiene. Que te puede reportar beneficios o pérdidas, pero eso ya depende de lo bien que hagas las cosas. El primer paso está dado, y es que todo el que vea tu producto sepa que es tuyo.

El único beneficio que se obtiene de la identidad corporativa en sí misma tiene que ver lógicamente con la imagen. Orden, coherencia, pulcritud, son algunos de los mensajes que se envían. Y es por eso que he decidido implantar poco a poco mi propio manual de identidad, en este caso personal.

El primer paso lo doy en el campo que considero más importante y sobre el que tengo mayor control, que es la documentación que genero, principalmente tutoriales. Así que he creado una plantilla y he definido unas líneas a seguir que espero le den un toque personal (y profesional) a mis documentos.

Si el tiempo lo permite, y supero mis limitaciones en lo que se refiere al diseño, puede que los próximos pasos sean el logo y el formato del propio blog.