Mostrando entradas con la etiqueta usabilidad. Mostrar todas las entradas
Mostrando entradas con la etiqueta usabilidad. Mostrar todas las entradas

jueves, agosto 05, 2010

Seguridad vs. Usabilidad

"La imagen de la discordia, origen y razón de ser de este post"

Recientemente por casualidades del destino me ví en la necesidad de ingresar al sitio en línea del banco agrícola. Tenía meses de no entrar a dicho sitio y al ingresar en esta ocasión me doy cuenta de un cambio significativo que han aplicado en la forma como escribes tu usuario, clave y token para ingresar al sistema. Resulta que ahora ya no puedes digitar de forma directa estos datos sino que debes hacer uso de un teclado virtual que te aparece en pantalla. Tal como se aprecia en la imagen inicial de este post.

Quizá la característica más particular que he encontrado junto con otros usuarios que pasaron por la misma experiencia de tratar de hacer login en dicha página, ha sido la que las teclas no se encuentran en un orden aparente sino mas bien ordenadas aleatoriamente. De hecho, por cada vez que refrescas la página (ej. en un intento fallido), dichas teclas vuelven a cambiar de posición y nuevamente de manera aleatoria.

"A ver... hoy donde quedó la A? y la L? la Ñ? OMG!"


Es cierto que hoy en día las instituciones bancarias sufren ataques de todo tipo en sus sitios web, el phishing y el cross site scripting por ejemplo, con el cual cualquier otro intenta vulnerar los sistemas web para tener acceso a las cuentas de sus clientes y sus datos privados están en juego. Es cierto que es deber de cada empresa en general proteger los datos de sus usuarios especialmente en el mayor punto débil de todos los sistemas seguros: sus pantallas de ingreso.

Todo esto es necesario para asegurarnos que los sitios a los que ingresamos se encuentren seguros de cualquier ataque pero no por ello se debe dejar de lado la usabilidad del sitio y la experiencia del usuario. Es posible mantener un balance entre seguridad y usabilidad?

La respuesta es SI.

Asumiendo que la inclusión de este terrible teclado virtual con teclas aleatorias que les mencionaba al principio se incluyó para prevenir que se intente ingresar por medio de un programa y no mediante la interacción con un usuario, existen alternativas mucho más usables para lograr este fin. Menciono las dos más comunes y útiles:

CAPTCHA

Captcha es un sistema ideado con la intención de diferenciar si la interacción con un sitio web la está realizando un humano o un programa de computadora. Para ello, muestran una imagen la cual contiene una palabra con el texto un tanto distorsionado o difuso, de manera que solamente un humano pueda leer e interpretar el texto, para luego escribirlo en un campo al final del formulario. No es 100% infalible ya que hoy en día existen programas para la interpretación de texto difuso pero sí es bastante confiable, ya que tanto Google, Facebook y otros sitios importantes hacen uso del mismo. Uno de los CAPTCHAs más populares es reCAPTCHA de Google, el cual es usado en la mayoría de formularios de login de Google cuando deseas crear una cuenta o cuando te has equivocado más de tres veces en tu login:

"Ejemplo de un cuadro de reCAPTCHA. Consiste en escribir el texto difuso en la caja de texto. En caso de no distinguirlo, click en el botón con forma de bocina para escuchar su pronunciación"

En este link puedes obtener plugins para blogs y el código fuente para hacer uso de reCAPTCHA en tu sitio.

Slide to Unlock

Este es un muy ingenioso sistema de ingreso que originalmente viene en los iPhone/iPod Touch, el cual se puede usar también en los sitios web para asegurarse que es un humano quien hace clic sobre el botón y lo desliza de izquierda a derecha. Esta interacción sería muy difícil (mas no imposible) de llevarse a cabo mediante un programa que intentara llenar automáticamente un formulario de login por lo que se podría considerar efectivo y fácil de usar.

"Ejemplo del mecanismo de submit 'Slide to Submit' similar al 'Slide to Unlock' del iPhone/iPod Touch"

En este link puedes encontrar el código fuente para incluir un botón de tipo "Slide to submit" mediante código Javascript.

Para mi punto de vista, usando alguna de las técnicas aquí presentadas, sumándole el uso de conexiones seguras por HTTPS, tokens, certificados digitales y mecanismos de prevención del XSS, un sitio podría considerarse lo suficientemente seguro como para no tener la necesidad de molestar más al usuario con pasos extra o peticiones para llevar a cabo su ingreso al sitio en cuestión.

Alguna otra técnica o sugerencia para crear sitios web tanto seguros como usables?



Bonus: Talvez estos 91 ejemplos de cajas de login te puedan inspirar para crear una página completamente usable y agradable a la vista de tus usuarios.

Bonus No. 2: Me entero en twitter que @hkadejo desarrolló un muy útil bookmarklet para desactivar las cajas de texto y poder escribir de forma manual el usuario y clave en la página del Banco Agrícola. Pueden encontrarlo en este link.

Seguridad vs. Usabilidad

"La imagen de la discordia, origen y razón de ser de este post"

Recientemente por casualidades del destino me ví en la necesidad de ingresar al sitio en línea del banco agrícola. Tenía meses de no entrar a dicho sitio y al ingresar en esta ocasión me doy cuenta de un cambio significativo que han aplicado en la forma como escribes tu usuario, clave y token para ingresar al sistema. Resulta que ahora ya no puedes digitar de forma directa estos datos sino que debes hacer uso de un teclado virtual que te aparece en pantalla. Tal como se aprecia en la imagen inicial de este post.

Quizá la característica más particular que he encontrado junto con otros usuarios que pasaron por la misma experiencia de tratar de hacer login en dicha página, ha sido la que las teclas no se encuentran en un orden aparente sino mas bien ordenadas aleatoriamente. De hecho, por cada vez que refrescas la página (ej. en un intento fallido), dichas teclas vuelven a cambiar de posición y nuevamente de manera aleatoria.

"A ver... hoy donde quedó la A? y la L? la Ñ? OMG!"


Es cierto que hoy en día las instituciones bancarias sufren ataques de todo tipo en sus sitios web, el phishing y el cross site scripting por ejemplo, con el cual cualquier otro intenta vulnerar los sistemas web para tener acceso a las cuentas de sus clientes y sus datos privados están en juego. Es cierto que es deber de cada empresa en general proteger los datos de sus usuarios especialmente en el mayor punto débil de todos los sistemas seguros: sus pantallas de ingreso.

Todo esto es necesario para asegurarnos que los sitios a los que ingresamos se encuentren seguros de cualquier ataque pero no por ello se debe dejar de lado la usabilidad del sitio y la experiencia del usuario. Es posible mantener un balance entre seguridad y usabilidad?

La respuesta es SI.

Asumiendo que la inclusión de este terrible teclado virtual con teclas aleatorias que les mencionaba al principio se incluyó para prevenir que se intente ingresar por medio de un programa y no mediante la interacción con un usuario, existen alternativas mucho más usables para lograr este fin. Menciono las dos más comunes y útiles:

CAPTCHA

Captcha es un sistema ideado con la intención de diferenciar si la interacción con un sitio web la está realizando un humano o un programa de computadora. Para ello, muestran una imagen la cual contiene una palabra con el texto un tanto distorsionado o difuso, de manera que solamente un humano pueda leer e interpretar el texto, para luego escribirlo en un campo al final del formulario. No es 100% infalible ya que hoy en día existen programas para la interpretación de texto difuso pero sí es bastante confiable, ya que tanto Google, Facebook y otros sitios importantes hacen uso del mismo. Uno de los CAPTCHAs más populares es reCAPTCHA de Google, el cual es usado en la mayoría de formularios de login de Google cuando deseas crear una cuenta o cuando te has equivocado más de tres veces en tu login:

"Ejemplo de un cuadro de reCAPTCHA. Consiste en escribir el texto difuso en la caja de texto. En caso de no distinguirlo, click en el botón con forma de bocina para escuchar su pronunciación"

En este link puedes obtener plugins para blogs y el código fuente para hacer uso de reCAPTCHA en tu sitio.

Slide to Unlock

Este es un muy ingenioso sistema de ingreso que originalmente viene en los iPhone/iPod Touch, el cual se puede usar también en los sitios web para asegurarse que es un humano quien hace clic sobre el botón y lo desliza de izquierda a derecha. Esta interacción sería muy difícil (mas no imposible) de llevarse a cabo mediante un programa que intentara llenar automáticamente un formulario de login por lo que se podría considerar efectivo y fácil de usar.

"Ejemplo del mecanismo de submit 'Slide to Submit' similar al 'Slide to Unlock' del iPhone/iPod Touch"

En este link puedes encontrar el código fuente para incluir un botón de tipo "Slide to submit" mediante código Javascript.

Para mi punto de vista, usando alguna de las técnicas aquí presentadas, sumándole el uso de conexiones seguras por HTTPS, tokens, certificados digitales y mecanismos de prevención del XSS, un sitio podría considerarse lo suficientemente seguro como para no tener la necesidad de molestar más al usuario con pasos extra o peticiones para llevar a cabo su ingreso al sitio en cuestión.

Alguna otra técnica o sugerencia para crear sitios web tanto seguros como usables?



Bonus: Talvez estos 91 ejemplos de cajas de login te puedan inspirar para crear una página completamente usable y agradable a la vista de tus usuarios.

Bonus No. 2: Me entero en twitter que @hkadejo desarrolló un muy útil bookmarklet para desactivar las cajas de texto y poder escribir de forma manual el usuario y clave en la página del Banco Agrícola. Pueden encontrarlo en este link.

viernes, junio 19, 2009

Mejorando la usabilidad en Ubuntu 9.10

Apenas hace un par de dias (17 Junio 09), Canonical, en un intento de mejorar la usabilidad de Ubuntu (específicamente de "Karmic Koala", lista para salir el 29 de Octubre de 2009), inicio un proyecto llamado One Hundred Paper Cuts, la idea del mismo es arreglar cien errores de usabilidad que se encuentran en esta popular distribución.


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".

"Koala de Origami"

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?

Mejorando la usabilidad en Ubuntu 9.10

Apenas hace un par de dias (17 Junio 09), Canonical, en un intento de mejorar la usabilidad de Ubuntu (específicamente de "Karmic Koala", lista para salir el 29 de Octubre de 2009), inicio un proyecto llamado One Hundred Paper Cuts, la idea del mismo es arreglar cien errores de usabilidad que se encuentran en esta popular distribución.


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".

"Koala de Origami"

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?

miércoles, marzo 04, 2009

Pruebas de Uso (Usability Test)

Supongamos que estas trabajando en un software, por los últimos... cuatro o cinco meses. Y tienes que entregar un producto terminado en dos semanas (tu deadline es en dos semanas).
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.

"Google realiza pruebas de uso, para conocer que áreas de una pagina son las que mas son 'visitadas' por el cursor (esto también es conocido como HeatMap)"

Suele ser de caja negra, porque no importa lo que hace en el fondo el sistema, sino la forma. Generalmente una prueba de uso, medirá que tan bien responden los usuarios en cuatro áreas: eficiencia, exactitud, recuerdo o familiaridad (recall), y respuesta emocional...
  • 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?
"Es necesario conocer que piensa el usuario final del software que usara"

¿Fácil no? ¿Ves a donde vamos con la implementar de una Prueba de Uso? Con estas pruebas, nos estamos asegurando que:
  1. No estas perdiendo tu tiempo (Codificas lo que realmente se necesita)
  2. Facilitas la vida del usuario final (Diseñar buenas GUI)
  3. Tienes una retro-alimentación constante (Alimentas el proceso de desarrollo con criticas constructivas y mantienes los pies en la tierra)
  4. Se mantienes una participación ACTIVA y proactiva del usuario y los developers (o el equipo de desarrollo).
Y definitivamente, es algo que quieres estar haciendo cada quince días o un mes como máximo, no es necesario que cien usuario prueben constantemente el software, uno siempre es mejor que ninguno. A continuación, les describo la mas simple Prueba de Usabilidad que se puedan imaginar:
  • 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.
En el blog de Robin Good, se puede encontrar en detalle una introducción al método "A/B Split Testing", les presento un extracto:

"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."

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.


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!

Pruebas de Uso (Usability Test)

Supongamos que estas trabajando en un software, por los últimos... cuatro o cinco meses. Y tienes que entregar un producto terminado en dos semanas (tu deadline es en dos semanas).
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.

"Google realiza pruebas de uso, para conocer que áreas de una pagina son las que mas son 'visitadas' por el cursor (esto también es conocido como HeatMap)"

Suele ser de caja negra, porque no importa lo que hace en el fondo el sistema, sino la forma. Generalmente una prueba de uso, medirá que tan bien responden los usuarios en cuatro áreas: eficiencia, exactitud, recuerdo o familiaridad (recall), y respuesta emocional...
  • 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?
"Es necesario conocer que piensa el usuario final del software que usara"

¿Fácil no? ¿Ves a donde vamos con la implementar de una Prueba de Uso? Con estas pruebas, nos estamos asegurando que:
  1. No estas perdiendo tu tiempo (Codificas lo que realmente se necesita)
  2. Facilitas la vida del usuario final (Diseñar buenas GUI)
  3. Tienes una retro-alimentación constante (Alimentas el proceso de desarrollo con criticas constructivas y mantienes los pies en la tierra)
  4. Se mantienes una participación ACTIVA y proactiva del usuario y los developers (o el equipo de desarrollo).
Y definitivamente, es algo que quieres estar haciendo cada quince días o un mes como máximo, no es necesario que cien usuario prueben constantemente el software, uno siempre es mejor que ninguno. A continuación, les describo la mas simple Prueba de Usabilidad que se puedan imaginar:
  • 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.
En el blog de Robin Good, se puede encontrar en detalle una introducción al método "A/B Split Testing", les presento un extracto:

"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."

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.


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!

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...