Facilidad de uso de Moodle
Algunos apuntes, vínculos y recursos sobre el tópico "Facilidad de uso de Moodle".
Bike sheds
Debido a que los cambios relacionados con la Facilidad de uso de Moodle son necesariamente evidentes y notorios, podemos decir que estos son potencialmente un caso de "Bike sheds". Esta es una metáfora discutida en círculos "Open Source" que sugiere (en resumen) que entre más pequeño sea el cambio, más grandes son las discusiones que lo rodean en los foros y listas de correo. Las personas que propongan pequeñas mejoras a Moodle deberían estar enteradas de este fenómeno y no tomar el nivel de una discusión como una crítica implícita a su sugerencia.
Usted puede leer un documento bien escrito en las listas de correo BSD sobre esta metáfora en la siguiente dirección: http://a.mongers.org/clueful/1999-phk-bikeshed
Evite la palabra "intuitivo"
(Definición: Intuitive)
"Intuitivo" es una palabra que usted debería evitar en discusiones de facilidad de uso debido a que su significado es frecuentemente mal entendido.
Normalmente se acepta que gran parte de la facilidad de uso está basada en la familiaridad y la experiencia. Las pautas para la interfaz con el humano publicadas por entidades como Apple o Gnome enfatizan en la lógica y la consistencia de tal manera que el aprendizaje pueda ser más sencillo y la experiencia más valiosa. Utilizar la palabra "intuitivo" para indicar algo que es familiar con frecuencia da la impresión de que si algo es "intuitivo" lo es independientemente de conocimientos o experiencias anteriores y, por lo tanto, igualmente válido para cualquiera. La palabra sugiere que las bondades o falencias de una interfaz están situadas dentro de la misma interfaz en vez de estar en la relación entre el usuario y la interfaz.
Muy pocas personas objetarían la afirmación que "El software de Apple es más intuitivo que el de Windows", incluso aquellas que han utilizado únicamente software de Windows; obviamente este no es el punto. Si usted evita utilizar el término "intuitivo" y su interpretación mental que otras personas le dan como "algo que me gusta" (por ejemplo, el sistema de bloques de Moodle no es intuitivo = el sistema de bloques de Moodle no me gusta) eso puede ayudar a mediar argumentos porque es más difícil sustentar opiniones personales consideradas explícitamente personales que aquellas que se pueden disfrazar como afirmaciones objetivas sobre el software.
Por lo tanto a lo que se le califique como intuitivo, en el caso de Moodle, dependerá de su experiencia y expectativas sobre otros sistemas de aprendizaje, sitios o aplicaciones WEB, como del software en general y aún así varía de persona a persona. Es por esto que los estudios sobre facilidad de uso deben promediar las opiniones de muchas personas para determinar qué es "intuitivo" y revisar si diferentes grupos tienen diferentes puntos de vista (por ejemplo, usuarios de sistemas particularmente diferentes o nuevos usuarios).
El siguiente artículo explica ampliamente y de mejor manera este tema (¡incluye diagramas!):
http://www.uie.com/articles/design_intuitive/
Facilidad de aprendizaje versus facilidad de uso
Las personas confunden estos términos frecuentemente, y con razón, debido a que ellos comparten muchos puntos comunes. Generalmente cuando se hace referencia a mejoras en la facilidad de uso es porque se hacen más fáciles las cosas para aprender y para los usuarios experimentados. Ocasionalmente las decisiones deberán favorecer a una de las dos posiciones, y en esos casos es mejor indicar explícitamente a cuál de los dos se está haciendo referencia. Existen muchas aplicaciones de software exitosas que han sacrificado la facilidad de aprendizaje por el aumento en la eficiencia de los usuarios avanzados. Parece que Moodle continuará inclinándose por la facilidad de aprendizaje en estos casos, de tal manera que el 99% de las veces estas metas no entren en conflicto.
En proyectos de código abierto frecuentemente es más fácil (en el corto tiempo) conciliar cualquier diferencia "adicionando una preferencia". De esta forma usted puede terminar con el doble (o el triple) de código para realizar la misma tarea. Eso implica más código para escribir, probar, mantener, etc. Con todas esas preferencias interactuando la cantidad posible de combinaciones se vuelve astronómica y usted termina en una situación donde dos personas no ejecutan el mismo programa.
Con el pasar del tiempo este comportamiento conducirá a tener una amplia variedad de preferencias, cada una de las cuales tiene un costo que debe ser ponderado de acuerdo a su beneficio. Algunas veces encontrar una solución que satisfaga a todo el mundo (con cierto grado de insatisfacción) es mejor que adicionar una preferencia por cada idea.
Este tema está mejor explicado por Havoc Pennington en su ensayo sobre código abierto e interfaz de usuario, especialmente en la sección "El asunto de las preferencias" alrededor de la mitad del siguiente documento:
http://www106.pair.com/rhp/free-software-ui.html
¿Moodle es un sitio WEB?
Sobre la Facilidad de uso de Moodle existe de alguna manera un inconveniente. Moodle es una aplicación WEB, no un sitio WEB (aunque la línea que los separa algunas veces es borrosa) y muy pocos libros se han escrito sobre esta clase de software, tal vez ninguno. Aún así muchas recomendaciones aplicables (extraídas de la WEB o de manuales de facilidad de uso en el software o aplicado a los productos) necesitan volverse a evaluar teniendo en cuenta la naturaleza de Moodle.
Vínculos externos
- El weblog "Vistoso vs. Ruidoso" de 37signals: http://www.37signals.com/svn/
- El sitio WEB de Jabkob Neilson: http://useit.com/
- Diseño de interfaz de usuario para programadores, por Joel Spolsky:
- Principios básicos del diseño de la interacción, por Tog (Bruce Tognazzini):
Bibliografía
Sobre WEB
- "Don't Make Me Think" por Steve Krug. Un libro realmente bueno; abundante en buena información, pero conciso; bien escrito y asequible. Incluye un capítulo de ejemplos.
- "Defensive Design For The Web" por 37signals (Matthew Lindeman and Jason Fried). Incluye un capítulo de ejemplos.
Sobre computadores
- "The Humane Interface" por Jeff Raskin Jeff. Fallecido recientemente, se dedicó a la investigación enfocándose en los últimos 15 años desde su participación en la invención del primer Macintosh. Esto lo condujo a descartar todas las consideraciones prácticas para concebir la interfaz de usuario "perfecta", en vez de seguir el género pragmático de ejecución de una lista de pasos tipo "Mejore su sitio en 15 minutos". No obstante, su escritura es excelente porque culpa consecuentemente a los computadores y su software, y no al usuario, de ser la causa de los problemas. Normalmente es fácil caer en la trampa de pensar que los usuarios "estupidos" son la causa de los problemas, cuando simplemente puede ser un parámetro de diseño. De todas formas es importante recordar (a menos que usted sea un seguidor de la investigación) que muchos de estos errores técnicos pueden ser analizados hasta cierto punto y que "lo perfecto es frecuentemente enemigo de lo bueno".
En general
- "Psychology of Everyday Things" por Donald Norman. También conocido como "The Design of Everyday Things". Es un libro clásico. Algunos de sus ejemplos están un poco obsoletos, pero el mensaje esencial de que un diseñador (sin importar cuán inteligente sea) tendrá dificultades para ubicarse mentalmente en la posición de un usuario es totalmente válido hoy día. Yo recuerdo este simple mensaje de este libro cada vez que empujo una puerta que se supone debo halar, y visceversa.
- "Emotional Design: why we hate or love everyday things" por Donald Norman.
