jueves, agosto 05, 2010
Seguridad vs. Usabilidad
Seguridad vs. Usabilidad
viernes, junio 19, 2009
Mejorando la usabilidad en Ubuntu 9.10

No se de alguna otra iniciativa similar en proyectos de software libre de gran escala (como lo es Ubuntu), pero lo más probable, es que esta costumbre se convierta en una practica seguida para mejorar exponencialmente cualquier tipo de proyecto.
Ahora bien, quiero que quede clara la idea de un "Paper Cut". Los Paper Cuts son simplemente pequeños bugs o defectos de usabilidad, y con pequeño me refiero a: mensajes mal traducidos, mensajes mal redactados, usar X version de programa en vez de la Y, etc...
Lo interesante de un Paper Cut, es que probablemente SEA UN BUG para un nuevo usuario de Ubuntu, pero para el usuario veterano-linuxero curtido de software libre, sera simplemente uno de esas cosas "espero que alguien arregle, pero por el momento me vale que este asi".
De lo que si me siento emocionado, es que ya esten los primeros diez Paper Cuts realmente definidos para resolver en el Ubuntu development list.
¿Por qué me emociona? Porque ademas de que la gente de Canonical, se ve que realmente esta trabajando, el concepto del proyecto no solo es genial y noble, sino que también aporta mejoras significativas y funcionales que inciden en practicas "sanas" de calidad para cualquier tipo de software, y también refuerza los vínculos entre Empresa-Developers-Comunidad.
Después de todo, el software libre, siempre ha estado orientado a comunidades...

Algunas de las mejoras inmediatas para el "Karmic Koala", y que en lo personal, estaba esperando en Ubuntu es el uso del nuevo Kernel 2.6.31, GRUB2, y obviamente EXT4 como sistema de archivos(ficheros) por defecto.
Y hablando de Ubuntu, les recomiendo que lean la divertida anécdota de DKCross: "Ubunteando en Microsoft El Salvador". Mi única observación, es que la próxima vez espero que me inviten ;)
Si esta practica realmente es retomada por otros proyectos de software libre (distros, programas, etc) pronto veremos muchas mejoras significativas en la calidad del software que usamos y producimos.
Y tú, ¿usarías esta idea en tus proyectos de software?
ubuntu karmic koala usabilidad linux paper cuts
Mejorando la usabilidad en Ubuntu 9.10

No se de alguna otra iniciativa similar en proyectos de software libre de gran escala (como lo es Ubuntu), pero lo más probable, es que esta costumbre se convierta en una practica seguida para mejorar exponencialmente cualquier tipo de proyecto.
Ahora bien, quiero que quede clara la idea de un "Paper Cut". Los Paper Cuts son simplemente pequeños bugs o defectos de usabilidad, y con pequeño me refiero a: mensajes mal traducidos, mensajes mal redactados, usar X version de programa en vez de la Y, etc...
Lo interesante de un Paper Cut, es que probablemente SEA UN BUG para un nuevo usuario de Ubuntu, pero para el usuario veterano-linuxero curtido de software libre, sera simplemente uno de esas cosas "espero que alguien arregle, pero por el momento me vale que este asi".
De lo que si me siento emocionado, es que ya esten los primeros diez Paper Cuts realmente definidos para resolver en el Ubuntu development list.
¿Por qué me emociona? Porque ademas de que la gente de Canonical, se ve que realmente esta trabajando, el concepto del proyecto no solo es genial y noble, sino que también aporta mejoras significativas y funcionales que inciden en practicas "sanas" de calidad para cualquier tipo de software, y también refuerza los vínculos entre Empresa-Developers-Comunidad.
Después de todo, el software libre, siempre ha estado orientado a comunidades...

Algunas de las mejoras inmediatas para el "Karmic Koala", y que en lo personal, estaba esperando en Ubuntu es el uso del nuevo Kernel 2.6.31, GRUB2, y obviamente EXT4 como sistema de archivos(ficheros) por defecto.
Y hablando de Ubuntu, les recomiendo que lean la divertida anécdota de DKCross: "Ubunteando en Microsoft El Salvador". Mi única observación, es que la próxima vez espero que me inviten ;)
Si esta practica realmente es retomada por otros proyectos de software libre (distros, programas, etc) pronto veremos muchas mejoras significativas en la calidad del software que usamos y producimos.
Y tú, ¿usarías esta idea en tus proyectos de software?
ubuntu karmic koala usabilidad linux paper cuts
miércoles, marzo 04, 2009
Pruebas de Uso (Usability Test)
Resuelves bugs, tu código esta cubierto (Code Coverage), tu software pasa las pruebas unitarias (Unit Testing), y además, pasa las pruebas de deploy ("Deployar" como escuche mencionar alguna vez) y de pronto, algo realmente importante surge en tu mente, algo que tienes ahi en tu cráneo desde el principio...
¿Es usable mi programa?Rayos!, esa, si que es una pregunta muy importante, no solo porque tienes que saber:
¿Quien usa mi programa? o ¿Cuanto van a usar mi programa?... para ver si realmente lo que hiciste es útil. No, no solo es por eso. Es importante, debido a la simple y sencilla razón, de que el cliente o usuario final, es la razón, propósito y motivo ulterior por la que estas desarrollando software, y TU software (o el software que estas desarrollando) DEBE (si, DEBE) facilitar la vida del usuario final de la aplicación.
Que este sea el mantra de esta semana:
"Mi aplicación deberá facilitar la vida del usuario final."La manera para asegurarte de que este mantra se cumpla lo máximo posible es utilizando las Pruebas de Uso. En el sentido técnico una Prueba de Uso consiste en realizar una prueba de "caja negra" a tu software. Es decir, observar a las personas que van a usar el producto, REALMENTE usándolo para descubrir errores y ÁREAS de mejora.

- Rendimiento -- ¿Cuanto tiempo y cuantos pasos se requieren para que una persona realice una tarea básica? (Ordenar Productos, Buscar, etc).
- Exactitud -- ¿Cuantos errores realizaron las personas? (Fueron errores fatales, recuperables, etc).
- Recuerdo-- ¿Que tan bien se recuerda el uso del programa, después de largos periodos de no utilizarlo?
- Respuesta Emocional -- ¿Como se siente una persona al completar una tarea? ¿Estresada, Confiada, Emocionada?
¿Fácil no? ¿Ves a donde vamos con la implementar de una Prueba de Uso? Con estas pruebas, nos estamos asegurando que:
- No estas perdiendo tu tiempo (Codificas lo que realmente se necesita)
- Facilitas la vida del usuario final (Diseñar buenas GUI)
- Tienes una retro-alimentación constante (Alimentas el proceso de desarrollo con criticas constructivas y mantienes los pies en la tierra)
- Se mantienes una participación ACTIVA y proactiva del usuario y los developers (o el equipo de desarrollo).
- Eliges un usuario final (operativo, gerencia, financiero, etc)
- Se aísla al usuario, y se le presenta el software.
- Se le asigna una o un par de tareas a realizar en el sistema.
- Se observa al usuario resolviendo la tarea.
- Se pregunta al usuario que piensa de la tarea (¿cuando esta en el proceso?, ¿como cree que puede mejorarlo?)
- Cuando el usuario termina la prueba (si la termina sin que le de un ataque cardíaco, por la frustración), se le pregunta lo siguiente: ¿Como se siente con respecto a la tarea? ¿Que recuerda del proceso? etc...
- Repita el proceso, con los usuarios aislados (siempre es mejor, probar a un solo usuario, que a varios para las Pruebas de Uso) y evalué en base a los resultados de las pruebas anteriores.
Aquí la clave (resaltada en negritas) es no dejar que prevalezca la opinión del que grita mas, sino la mejor opción, pero para el usuario."A/B split testing
Por Lisa Halabi
A partir de cualquier estudio de usabilidad de sitio web, generalmente se encuentran un número de problemas de usabilidad. A menudo puede suscitarse un debate dentro de una organización para hallar la solución a cada problema, sin que nadie conozca realmente la solución óptima. En vez de dejar que prevalezca la opinión de la persona que grita más, una mejor opción puede ser probar dos soluciones en un entorno en vivo. Aquella que tenga el mejor rendimiento es claramente la solución superior. ¡Bienvenido al A/B split testing! ... click aquí para leer mas."

Steve Krug en su libro Don't Make Me Think!, en el capitulo nueve, plantea una serie de aclaraciones sobre las Pruebas de Uso, que toda persona que este encargada de crear software debe de leer, pueden encontrar el capitulo 9 (en Ingles) de la primera edición de este genial libro dando clic aquí.
Espero, sinceramente, que la próxima vez que estén en un proyecto de software, que se preocupen constantemente, en la opinión del usuario final, final, final (el que realmente usara tu software todos los dias, para hacer su vida mas fácil). Para que de esta forma, realmente estés produciendo software enfocado al uso o a la "usabilidad".
Saludos!
prueba pruebas uso usabilidad usability test software development desarrollo practicas
Pruebas de Uso (Usability Test)
Resuelves bugs, tu código esta cubierto (Code Coverage), tu software pasa las pruebas unitarias (Unit Testing), y además, pasa las pruebas de deploy ("Deployar" como escuche mencionar alguna vez) y de pronto, algo realmente importante surge en tu mente, algo que tienes ahi en tu cráneo desde el principio...
¿Es usable mi programa?Rayos!, esa, si que es una pregunta muy importante, no solo porque tienes que saber:
¿Quien usa mi programa? o ¿Cuanto van a usar mi programa?... para ver si realmente lo que hiciste es útil. No, no solo es por eso. Es importante, debido a la simple y sencilla razón, de que el cliente o usuario final, es la razón, propósito y motivo ulterior por la que estas desarrollando software, y TU software (o el software que estas desarrollando) DEBE (si, DEBE) facilitar la vida del usuario final de la aplicación.
Que este sea el mantra de esta semana:
"Mi aplicación deberá facilitar la vida del usuario final."La manera para asegurarte de que este mantra se cumpla lo máximo posible es utilizando las Pruebas de Uso. En el sentido técnico una Prueba de Uso consiste en realizar una prueba de "caja negra" a tu software. Es decir, observar a las personas que van a usar el producto, REALMENTE usándolo para descubrir errores y ÁREAS de mejora.

- Rendimiento -- ¿Cuanto tiempo y cuantos pasos se requieren para que una persona realice una tarea básica? (Ordenar Productos, Buscar, etc).
- Exactitud -- ¿Cuantos errores realizaron las personas? (Fueron errores fatales, recuperables, etc).
- Recuerdo-- ¿Que tan bien se recuerda el uso del programa, después de largos periodos de no utilizarlo?
- Respuesta Emocional -- ¿Como se siente una persona al completar una tarea? ¿Estresada, Confiada, Emocionada?
¿Fácil no? ¿Ves a donde vamos con la implementar de una Prueba de Uso? Con estas pruebas, nos estamos asegurando que:
- No estas perdiendo tu tiempo (Codificas lo que realmente se necesita)
- Facilitas la vida del usuario final (Diseñar buenas GUI)
- Tienes una retro-alimentación constante (Alimentas el proceso de desarrollo con criticas constructivas y mantienes los pies en la tierra)
- Se mantienes una participación ACTIVA y proactiva del usuario y los developers (o el equipo de desarrollo).
- Eliges un usuario final (operativo, gerencia, financiero, etc)
- Se aísla al usuario, y se le presenta el software.
- Se le asigna una o un par de tareas a realizar en el sistema.
- Se observa al usuario resolviendo la tarea.
- Se pregunta al usuario que piensa de la tarea (¿cuando esta en el proceso?, ¿como cree que puede mejorarlo?)
- Cuando el usuario termina la prueba (si la termina sin que le de un ataque cardíaco, por la frustración), se le pregunta lo siguiente: ¿Como se siente con respecto a la tarea? ¿Que recuerda del proceso? etc...
- Repita el proceso, con los usuarios aislados (siempre es mejor, probar a un solo usuario, que a varios para las Pruebas de Uso) y evalué en base a los resultados de las pruebas anteriores.
Aquí la clave (resaltada en negritas) es no dejar que prevalezca la opinión del que grita mas, sino la mejor opción, pero para el usuario."A/B split testing
Por Lisa Halabi
A partir de cualquier estudio de usabilidad de sitio web, generalmente se encuentran un número de problemas de usabilidad. A menudo puede suscitarse un debate dentro de una organización para hallar la solución a cada problema, sin que nadie conozca realmente la solución óptima. En vez de dejar que prevalezca la opinión de la persona que grita más, una mejor opción puede ser probar dos soluciones en un entorno en vivo. Aquella que tenga el mejor rendimiento es claramente la solución superior. ¡Bienvenido al A/B split testing! ... click aquí para leer mas."

Steve Krug en su libro Don't Make Me Think!, en el capitulo nueve, plantea una serie de aclaraciones sobre las Pruebas de Uso, que toda persona que este encargada de crear software debe de leer, pueden encontrar el capitulo 9 (en Ingles) de la primera edición de este genial libro dando clic aquí.
Espero, sinceramente, que la próxima vez que estén en un proyecto de software, que se preocupen constantemente, en la opinión del usuario final, final, final (el que realmente usara tu software todos los dias, para hacer su vida mas fácil). Para que de esta forma, realmente estés produciendo software enfocado al uso o a la "usabilidad".
Saludos!
prueba pruebas uso usabilidad usability test software development desarrollo practicas
Sunsetting Sr. Byte.
El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...
