The Design Of Everyday Things – Knowing What to do


        Al encontrarse con un objeto por primera vez, las personas observan la situación e intentan descubrir que partes pueden ser operadas y que operaciones se pueden realizar. Si hubiera una única parte que pueda ser operada y una única acción a realizar, no existiría dificultad alguna. Los problemas ocurren cuando hay más de una posibilidad. En estos casos podemos recurrir al conocimiento disponible en las cabezas (Conocimiento adquirido en situaciones similares en el pasado, recibir instrucción, etc) ó podemos usar el conocimiento disponible en el mundo e interpretarlo. Este último tipo de conocimiento se presenta en forma de las restricciones naturales y las affordances  de los objetos. Las restricciones nos limitan el número de alternativas mientras que las affordances sugieren el rango de posibilidades.

Tipos de Restricciones:

Físicas: Limitaciones físicas que restringen las posibles operaciones. Estas restricciones recaen en las propiedades físicas del mundo para limitar el conjunto de posibles acciones, no se requiere ningún tipo de entrenamiento. Suelen ser más efectivas y útiles cuando son fáciles de ver e interpretar, dado que limitan el conjunto de operaciones antes de cualquier acción en lugar de solo prevenir la ejecución de acciones incorrectas.

Semánticas: Estas restricciones recaen el contexto para limitar el conjunto de posibles acciones.

Culturales: Estas restricciones recaen en convenciones culturales aceptadas para limitar el conjunto de posibles acciones. Cada cultura tiene un conjunto de acciones permitidas en situaciones sociales que, como demostró el sociólogo Ervin Goffman, gobiernan el comportamiento de las personas cuando estas se encuentran ante una nueva situación o ante una nueva cultura1. Los asuntos culturales son la raíz de mucho de los problemas que se tienen con las nuevas tecnologías, dado que no existen aún convenciones aceptadas para lidiar con estas.

Lógicas: Estas restricciones recaen en el uso de relaciones lógicas para limitar el conjunto de posibles acciones. El mapeo natural funciona gracias al uso de restricciones lógicas entre la disposición espacial o funcional de los componentes y las cosas que son afectados por estos. No existen principios físicos ni culturales en este tipo de mapeo.

Usando sonidos para la visibilidad

        En ocasiones existe información que no puede hacerse visible. La utilización de sonido nos permite proveer información, necesaria para el usuario (indicar si algo se está ejecutando correctamente o no), que no estaría disponible de otro modo. A su vez el sonido también nos brinda información sobre algo aun cuando la vista está ocupada en otra cosa. Para que sean útiles los sonidos deben ser generados inteligentemente, utilizando una relación natural entre los sonidos y la información que estos proveen. Por otro lado los sonidos, al ser intrusivos, deben ser utilizados inteligentemente para no fastidiar o distraer al usuario y entorno.



1. Frame Analysis – Goffman Ervin 1974

author: Paltrinieri Alejandro | posted @ Wednesday, May 14, 2008 5:59 PM | Feedback (0)


The Design Of Everyday Things – Knowledge in the head and in the word


        No todo el conocimiento necesario para llevar a cabo las tareas se encuentra en la cabeza. Muchas tareas pueden ser realizadas correctamente aún cuando el conocimiento que se posee es impreciso. El comportamiento humano es determinado por el conocimiento interno junto con la información y restricciones externas.

        Cuando la información necesaria para realizar una tarea se encuentra disponible en el mundo, la necesidad de aprenderla se reduce (ej: El uso de restricciones, recordatorios y mapeo natural pueden servir para simplificar lo que debe ser retenido en memoria). Solo es necesario memorizar la información con el nivel de detalle suficiente para poder ejecutar la tarea con la calidad deseada. Una propiedad de la memoria consiste en recordar únicamente descripciones parciales de las cosas a recordar. Descripciones lo suficientemente precisas para poder trabajar al momento del aprendizaje, pero puede que no posea el suficiente detalle trabajar en el futuro cuando nuevas experiencias entre en juego.

        Uno de los aspectos más importantes e interesantes del conocimiento externo es el de actuar como recordatorio. Estos pueden servir para recuperar estructuras que de otro modo serian olvidadas. Los recordatorios están compuestos por una señal y un mensaje. La señal es el conocimiento de que algo debe ser recordado y el mensaje es lo que se debe recordar.

        El conocimiento interno es eficiente, no requiere de búsqueda e interpretación del entorno, pero la adquisición de del mismo requiere una cantidad de aprendizaje considerable. Por otro lado el conocimiento externo es más fácil de aprender pero más difícil de usar.

Estructura de la Memoria:

    Memoria Operativa (a corto plazo): Es la memoria del presente. Información es retenida en esta automáticamente y recuperada sin ningún esfuerzo, pero la cantidad de información que puede ser retenida en esta memoria es muy limitada. Esta memoria es frágil, una distracción puede hacer que la información en esta desaparezca.

        Memoria a largo plazo: Es la memoria del pasado. Lleva tiempo retener información en esta y tiempo y esfuerzo sacarla. Aquí es donde se almacenan las experiencias, no como un recuerdo exacto de los eventos, sino la interpretación a través del entendimiento de estos. La cantidad de información que puede ser retenida es prácticamente infinita. La dificultad de esta memoria reside en la organización, cómo poner información y cómo sacarla, no en la capacidad. Al examinar cómo las personas usan su memoria y cómo obtienen información de esta, se pueden distinguir tres categorías:
  • Memoria de cosas arbitrarias: Los ítems a aprender parecen arbitrarios por lo que el aprendizaje es costoso. Por otro lado, cuando surge un problema, la secuencia memorizada de acciones no dan ninguna señal de que es lo que fallo, como tampoco dan señal alguna de lo que se debe hacer para solucionar el problema.
  • Memoria de relaciones significativas: Los ítems a aprender forman relaciones significativas consigo mismos o con cosas ya conocidas. Cuando las cosas tienen sentido el nuevo material puede ser entendido, interpretado, e integrado con el previamente adquirido.
  • Memoria a través de explicaciones: El material no debe ser recordado, dado que puede ser derivado de algún mecanismo explicativo. Aquí los modelos mentales juegan un rol mayor. Los modelos mentales simplifican el aprendizaje dado que el comportamiento requerido puede ser derivado cuando se lo necesita. Además resultan invaluables a la hora de lidiar con situaciones inesperadas.
        Hay que destacar que existe un tradeoff entre la velocidad y calidad de actuación y el esfuerzo mental requerido. El uso de modelos mentales para recordar comportamiento no es ideal para tareas que deben hacerse rápidamente y sin interrupciones (ej: acciones de emergencia ante incidentes críticos). La derivación toma tiempo y requiere recursos mentales.

        Por otro lado los psicólogos distinguen dos tipos de conocimientos que se almacenan en la memoria a largo plazo:

Conocimiento declarativo: El conocimiento declarativo es información consistente en hechos, conceptos o ideas conocidas conscientemente y que se pueden almacenar como proposiciones. Este conocimiento es fácil de documentar y de enseñar.

Conocimiento procedimental: El conocimiento procedimental es el conocimiento relacionado con cosas que sabemos hacer pero no conscientemente, como por ejemplo montar en bicicleta o hablar nuestra lengua. Este conocimiento es muy difícil, incluso imposible, de documentar y difícil de enseñar. La mejor manera de transmitirlo es por medio de la demostración y se adquiere gradualmente por medio de la práctica.

author: Paltrinieri Alejandro | posted @ Monday, May 12, 2008 10:17 PM | Feedback (0)


The Design Of Everyday Things – The Psychopathology Of Everyday Actions


        En este capítulo se describe la psicología de las acciones realizadas por las personas. Es importante entender la manera de actuar de las personas a la hora de realizar un diseño. Esto nos permitirá comprender la forma de interactuar de los humanos con los objetos y de esta manera buscar sacar beneficio de este conocimiento.

Las personas se auto-reprochan falsamente

        En caso de ocurrir un error en una tarea que parece simple o trivial, las personas se suelen sentir culpables y o bien intentan ocultarlo o bien se reprochan a sí mismo por estupidez e incapacidad. Es como si tuvieran un orgullo perverso por sentirse mecánicamente incompetentes. Por supuesto que las personas cometen errores. Los dispositivos complejos requieren de algún tipo de instrucción, y alguien que intente usarlos sin esta puede esperar cometer errores y sentirse confuso. Pero los diseñadores deberían poner un empeño especial por hacer que los errores tengan el menor costo posible. Si un error es posible, alguien lo cometerá. Los diseñadores tienen que asumir que todos los posibles errores ocurrirán y diseñar de tal forma de minimizar la oportunidad de error en primer lugar, o los efectos de los mismos una vez cometidos.

        El fenómeno denominado incapacidad aprendida se refiere a la situación en la cual una persona experimenta un fracaso (generalmente más de una vez) al realizar una tarea y considera que es por su culpa. Esto genera como resultado que esta persona decida que es incapaz de realizar esa tarea y la próxima vez que tenga que realizarla ni siquiera lo intente.

Las personas son criaturas explicativas

        Como se mencionó en el post anterior, los modelos mentales resultan de nuestra tendencia a buscar una explicación a las cosas. Estos modelos son esenciales para ayudarnos a entender nuestras experiencias, predecir los resultados de nuestras acciones y manejar ocurrencias inesperadas. Basamos nuestros modelos en cualquiera que fuera el conocimiento que tengamos, real o imaginario, ingenuo o sofisticado.

        Los modelos mentales son construidos a partir de evidencia fragmentada con un pobre entendimiento de lo que está pasando, y con un tipo de psicología ingenua que postula causas, mecanismos y relaciones aun cuando no las exista.

        Todas las personas forman teorías para explicar lo que han observado. En la ausencia de de información externa, nos sentimos libres de dejar a nuestra imaginación libre siempre que los modelos mentales que construimos expliquen los hechos que percibimos.

Señalar la causa equivocada

        Las personas suelen buscar las causas de los eventos. La manera en que las personas realizan la asignación de una causa a un evento es muy compleja y poco entendida. Se basa en la percepción de una relación causal entre el evento y la causa señalada. El termino percepción indica quela relación causal no tiene que porque existir realmente, la persona puede pensar que existe. Si una acción A antecede un resultado R, uno suele concluir que A ha causado R. Aun cuando no exista ninguna relación real entre ambos. Un aspecto importante de la asignación reside en que generalmente se posee poca información en la cual basar el juicio de la misma, y incluso esta pequeña información puede estar mal.

Como la gente hace las cosas: Las siete fases de la acción




        A la hora de realizar algo, una persona debe empezar con una noción de lo que quiere realizar, es decir la meta que se quiere alcanzar. Luego debe realizar algo en el mundo y finalmente verificar que la meta se haya alcanzado. Entonces hay cuatro cosas a considerar: la meta, la ejecución, el mundo y la evaluación.

        La ejecución de una tarea no es tan simple. Para poder realizar la ejecución, la meta debe ser transformada a la intención de realizar algo. A su vez la intención debe ser traducida a un conjunto de comandos internos, una secuencia de acciones. Esta secuencia actúa como puente entre lo que queremos hacer y las acciones físicas posibles de realizarse. Pero esta secuencia es aun un evento mental, nada ocurre hasta que es ejecutada en el mundo real.

        La evaluación de las cosas tiene tres etapas: primero, percibir que paso en el mundo; segundo, tratar de interpretar esta información percibida; y, por último, comparar lo ocurrido con lo deseado.

        Hay que recalcar que en las tareas de todos los días, las metas y las intenciones no están bien especificadas: son oportunísticas en vez de planeadas. Las acciones oportunísticas son aquellas en las que el modo tomo ventaja de las circunstancias. Por otro lado, el proceso de acción descripto puede empezar en cualquier punto. Es más respondemos a los eventos del mundo en vez de elaborar planes y metas. Un evento pude disparar una interpretación y una respuesta resultante.

        La dificultad reside en encontrar la relación entre la intención mental y la interpretación y las acciones físicas posibles y los estados físicos del sistema. Es acá donde el diseño juega un papel muy importante intentando hacer más visible esta relación.

 

author: Paltrinieri Alejandro | posted @ Monday, May 12, 2008 10:10 PM | Feedback (0)


The Design Of Everyday Things – The Psychopathology Of Everyday Things


    Dada una introducción general al libro en el post anterior, me focalizaré ahora en resumir los conceptos y principios más relevantes de los distintos capítulos. El primer capítulo se focaliza en la llamada psicología de las cosas.

La psicología de las cosas

    Es crucial que el diseñador esté familiarizado no solo con la forma de funcionar del objeto, sino también tenga conocimiento de la psicología del pensamiento y cognitiva de las personas. Los principios de diseño establecen una forma de psicología, la psicología de cómo las personas interactúan con las cosas.

Problemas en el diseño

        Diseñar bien no es algo fácil. Los fabricantes quieren algo que pueda ser producido económicamente. Los negocios quieren algo que sea atractivo para los clientes. Los compradores tienen diferentes demandas. En el negocio se focalizan en el precio y la apariencia, y tal vez en el prestigio. En su casa, la misma persona prestará más atención a la usabilidad y funcionalidad. Los servicios técnicos se preocupan por la mantenibilidad. Todos estos intereses son diferentes y, en ocasiones, conflictivos. El diseñador debe ser capaz de satisfacerlos todos.
       
        Algunos de los problemas más usuales que encontramos en el diseño son:

• Instrucciones pobres, especialmente la falla al relacionar nuevas funcionalidades con el nombre de funcionalidades similares que las personas ya conocen.
• La ausencia de visibilidad de la operación del sistema
• La ausencia de la visibilidad de los efectos de la operación (feedback)
• Problemas al mapear que se quiere hacer y que es posible hacer
• Funcionalidades no muy pensadas y ciertamente no probadas con los usuarios finales.
• El usuario debe recordar muchas cosas


Visibilidad

        Los objetos bien diseñados son fáciles interpretar y entender. Contienen pistas visibles para su utilización. Por el contrario los objetos mal diseñados resultan frustrantes y difíciles de usar. Estos engañan al usuario y obstaculizan el proceso normal de interpretación y entendimiento. Uno de los principios más importantes del diseño es la Visibilidad. Solo las cosas correctas tienen que ser visibles para transmitir que partes son las que operan y cómo, indicando de esta forma cómo interactuar con el objeto. La forma de utilizar el objeto debe estar dada por el diseño mediante símbolos naturales que permitan una interpretación natural del mismo. Sin que sea necesaria la utilización de palabras o símbolos escritos, ni que el usuario tenga que recurrir a la prueba y el error. La utilización de símbolos naturales es lo que el autor llama diseño natural.

        La visibilidad muestra el mapeo entre las acciones que se quieren realizar y las operaciones actuales disponibles. A su vez sirve como recordatorio al usuario de lo que se puede hacer. La visibilidad de los efectos de las operaciones (feedback) nos muestra si la operación fue llevada a cabo con éxito.

        La ausencia de visibilidad es la causante de que muchos de los dispositivos sean difíciles de operar. Y es, a su vez, el exceso de la misma la que los hace tan intimidantes
.

Modelos Conceptuales

        Los modelos conceptuales forman parte de un concepto importante en diseño: modelos mentales, los modelos que tienen las personas sobre sí mismas, sobre los otros, sobre el ambiente y sobre las cosas con las cuales interactúan. Las personas forman modelos mentales a través de la experiencia, entrenamiento e instrucción.

        Un buen modelo conceptual nos permite predecir los efectos de nuestras acciones. Sin un buen modelo operamos ciegamente, hacemos lo que nos dicen pero no entendemos completamente el por qué. No sabemos qué efectos esperar ni qué hacer si algo sale mal. Los modelos conceptuales no necesitan ser muy complicados. No es necesario que entendamos los principios físicos o químicos de las cosas que operamos, simplemente debemos saber la relación existente entre los controles y las salidas.



        El diseñador espera que su modelo conceptual del objeto diseñado (Design Model) sea igual al modelo conceptual que tiene el usuario (User Model). Pero el diseñador no habla directamente con el usuario, toda la comunicación es por medio de la imagen del sistema (System Image). Esta es la parte visible del objeto y se obtiene de la estructura física del mismo (incluyendo la documentación, las instrucciones y las etiquetas o símbolos que este posea). Si la imagen del sistema no es lo suficientemente clara y consistente, puede que el usuario termine formando un modelo mental equivocado del objeto.

Mapeo


        Mapeo es un término técnico que representa la relación entre dos cosas, en este caso entre los controles, sus movimientos y los resultados obtenidos. Una buena relación entre la ubicación de los controles y su fin ayuda a encontrar fácilmente el control apropiado para una tarea. Disminuyendo, de este modo, la carga de memoria requerida por el usuario.

        Cuando el número de acciones disponibles a realizar excede en número a la cantidad de controles aparece la dificultad ya que los controles con más de una función suelen ser más difíciles de recordar y usar. El etiquetamiento se vuelve difícil o imposible dejando funciones invisibles al usuario. Cuando estas cantidades son iguales, cada control puede ser especializado y etiquetado. Todas las posibles acciones son visibles, a cada una le corresponde un control. Y si el usuario olvida alguna, estos controles sirven de recordatorio.

        El Mapeo Natural, que significa tomar ventaja de las analogías físicas y de los estándares culturales, permite un entendimiento inmediato. Un objeto es más fácil de usar cuando los controles o visores del mismo explotan el mapeo natural. Este tipo de mapeo puede ser cultural, como es el caso del estándar universal de usar el símbolo “+” para representar el incremento de nivel y el símbolo “-” para representar el decrecimiento. Otro tipo de mapeo natural sigue los principios de percepción permitiendo un natural agrupamiento o identificación de patrones de los controles y feedback.


Affordances (Facilitantes)


        Este término hace referencia a las propiedades de actuación percibidas de las cosas, principalmente a las propiedades fundamentales que determinan como estas cosas pueden ser usadas. Las Affordances proveen las pistas necesarias para operar los objetos. Cuando las affordances son tenidos en cuenta, el usuario sabe qué hacer con solo mirar, no son necesarias etiquetas, imágenes o instrucciones. Las cosas complejas pueden requerir explicación, las simples no. Cuando algo simple requiere explicación, el diseño ha fallado.

Feedback


        Feedback es un concepto que hace referencia a remitir al usuario información sobre cómo fue llevada a cabo la operación y qué resultados se obtuvieron. Es un concepto muy importante a la hora de diseñar un objeto, imagínese intentando dibujar con un lápiz que no deja trazo. En este sentido hay que tener en cuenta que cuando una acción no tiene un resultado aparente, uno tiende a concluir que la acción fue inefectiva. Por otro lado algo que pase justo después de una acción parece como si fuera causado por esta.

La paradoja de la Tecnología


            La tecnología ofrece el potencial de hacer la vida más fácil y disfrutable. Toda nueva tecnología provee un incremento en los beneficios. Al mismo tiempo, agrega complejidades que llevan a incrementar nuestras dificultades y frustraciones. El desarrollo de una tecnología tiende a seguir una curva de de complejidad de uso en forma de U. Toda nueva tecnología suele ser compleja y difícil de usar. A medida que los expertos se vuelven más competentes y la industria madura, la complejidad disminuye. Los dispositivos se convierten en más simples, confiables y poderosos. Pero, luego que la industria se haya estabilizado, nuevos ingresantes descubren como agregar poder y capacidad. Pero siempre a expensas de la complejidad y, en ocasiones, de la confiabilidad.

       La siguiente frase de Bjarne Stroustrup, inventor del lenguaje C++, es un claro ejemplo de la paradoja de la tecnología de los telefonos moviles:


"Siempre deseé que mi ordenador fuera tan fácil de usar como mi teléfono. A estas alturas mi deseo ya se ha hecho realidad: ¡no tengo ni idea de cómo usar mi teléfono!"

author: Paltrinieri Alejandro | posted @ Monday, May 12, 2008 9:57 PM | Feedback (0)


The Design Of Everyday Things - Introducción


   
      Luego de una pausa vuelvo a trabajar sobre la tesis. Es el turno ahora de comenzar la relectura de “The Design Of Everyday Things” de Donald A. Normal. Libro que considero más que recomendable para cualquier diseñador. Este libro nos enseña a mirar el mundo de otro modo. Un modo en el cual no somos culpables por la frustración que sentimos al no saber usar algo. Un modo de ver las cosas que nos permite encontrar la solución a los problemas de diseño y aprender de los errores. Utiliza los objetos de uso cotidiano como puerta hacia esta forma de ver para que, luego, seamos capaces de aplicarlas en cualquier tipo de objetos, incluso los que involucran tecnología.

    El autor considera este libro como el fruto de años de estudio y experiencia en el campo de la psicología cognitiva. En un principio su trabajo consistió en estudiar el error humano, esperando que este conocimiento le ayudara a hallar formas de indicarle a la gente como evitar los errores. Pero la verdad emergió lentamente. Muchos de los atribuidos “errores humanos” no eran tal, sino que eran la consecuencia inmediata de un diseño pobre. Los humanos no siempre se equivocan, pero pueden hacerlo cuando las cosas que usan están mal concebidas y diseñadas.

    A modo de ejemplo se menciona el accidente nuclear ocurrido en Three Mile Island. Como en muchos casos, en este accidente se culpo a los operarios de haber diagnosticado mal los problemas. El autor formo parte del equipo encargado en investigar el por qué de la supuesta equivocación de los operarios. Para su sorpresa, el equipo concluyo que el causal del error yacía en el diseño de la sala de control. Norman nos invita luego a prestar atención en la frase: “… los operarios diagnosticaron mal los problemas”. Esta nos revela que primero hubo problemas, entonces: ¿Por qué no considerar estos problemas como la verdadera causa? Es más la equivocación, en el diagnostico, se debió a que los operarios no hicieron la doble revisión para determinar que la lamparita, que se tenía que prender en caso de error, no se prendió porque esta estaba fallada.

    Este caso me hizo recordar al que se menciona Enrique Piñeyro en el documental: Fuerza aérea sociedad anónima. En este se nombra un episodio donde se atribuye un accidente aéreo al error del piloto. En realidad lo ocurrido es que el avión no tenía una alarma que le indique la falla de uno de los sensores. Lo más curioso es el argumento que utiliza la fuerza aérea para excusarse del accidente y de la falta de la alarma. Considera que la existencia de otro indicador la hace innecesaria. Piñeyro, sorprendido ante semejante excusa, propone considerar a la alarma de los relojes innecesaria, ya que se pude ver la hora con el simple hecho de ver otro indicador: las agujas.

    Frecuentemente, al encontrarnos con un dispositivo por primera vez, nos vemos frustrados, confundidos y culpables de no saber cómo utilizarlo. La culpa no es nuestra, sino de los diseñadores y fabricantes. La apariencia de un dispositivo debería proveer las pistas críticas requeridas para la correcta utilización del mismo. No todos los diseñadores comprenden que el diseño debe cubrir la esencia del funcionamiento del dispositivo, la manera en que funciona, las posibles acciones que pueden realizarse y, por medio del feedback, lo que el dispositivo está haciendo en cada momento. El diseño es, para el autor, el arte de la comunicación. En el libro se analiza el diseño y usabilidad desde el punto de vista de los objetos de uso cotidiano, pero es importante destacar que los principios descriptos en el mismo aplican a todo tipo de objetos sin importar el campo. Norman decidió analizar estos objetos dado el hecho de que la tecnología cambia rápidamente pero que la interacción de las personas con los objetos está gobernada por nuestra biología, psicología, sociedad y cultura. La biología y psicología humana no cambian mucho con el tiempo; la sociedad y cultura cambian muy lentamente. Uno de los principales argumentos del libro resulta en que mucho del conocimiento se encuentra en el mundo, no en la cabeza de las personas. Esto podría resultar confuso. Se podría argumentar que: “El conocimiento es interpretado, cosa que solo pueden hacer las mentes. La información podría estar en el mundo, pero nunca el conocimiento.” Bueno, la distinción entre conocimiento e información no es del todo clara. Si combinamos un poco los términos se puede entender mejor el argumento del autor.

    Entre los temas que cubre el libro, hay tres que resaltan del resto. Primero, el hecho de que siempre que alguien tenga algún problema con un objeto, no es su falla. La falla es del diseño. El segundo de estos temas, consiste en los llamados principios de diseño. Estos son herramientas poderosas para los diseñadores, permitiéndoles que sus productos sean entendidos y utitilizables. Entre los principios que encontramos en el libro, los más importantes son:

Modelos conceptuales: Una de las mayores frustraciones es tratar de aprender cómo utilizar algo que parece completamente arbitrario y caprichoso. Para entender cómo usar las cosas, necesitamos tener modelos conceptuales de cómo funcionan. Un buen modelo conceptual marca la diferencia entre el uso exitoso y el erróneo de los dispositivos. Como se ha dicho: un buen diseño es un acto de comunicación entre el diseñador y el usuario, solo que toda esta comunicación proviene de la apariencia del objeto. Es por esto que este se tiene que explicar por sí solo.

Feedback: En diseño, es importante mostrar el efecto de una acción. Sin feedback, siempre nos estamos preguntando si algo ha pasado (ej: Tal vez no apretamos el botón lo suficientemente fuerte), por lo podemos que terminar realizando la acción varias veces.

Restricciones: La mejor manera de hacer algo fácil de usar, es simplemente que no exista otra forma de usarlo. Es decir restringir las opciones.

Affordances: Las posibilidades de acción que rápidamente pueden ser percibidas por el usuario. Un buen diseñador se asegura que las acciones apropiadas sean perceptibles y que las inapropiadas sean invisibles.

    El tercer tema, que se resalta en el libro, es el poder de la observación. El problema es, que hay que aprender como observar. El autor intenta cambiarnos la forma de ver el mundo con el que interactuamos. De este modo nos encontraremos, sin darnos cuenta, criticando el diseño de las cosas y, mejor aún, proponiendo soluciones a los problemas.

    Si bien el libro hace énfasis en la usabilidad de los objetos, es decir en diseñar cosas que sean entendibles y usables. Solo lo hace por el simple hecho de que esta dimensión es la más descuidada por los diseñadores. Esto no significa que la usabilidad sea lo más importante, un buen diseño tiene que encontrar el apropiado balance y armonía entre belleza estética, confianza y seguridad, usabilidad, costo y funcionalidad.

    Por último, resulta curioso el hecho de que el libro haya sido publicado bajo dos títulos distintos. La primera publicación fue bajo el título de: “The Psychology of Everyday Things”. Esto se lo puede considerar como una lección de diseño. El autor admite que fue culpable de la falta de visión que lleva a tornar inusables las cosas de todos los días. La primera elección del título fue auto-centrada en sí mismo. Es decir, eligió el título que más le gusto sin considerar el impacto de este en los lectores. No tuvo en cuenta que es el título lo que leen los lectores en las librerías y que estos confían en que este les describa el contenido. Tampoco consideró que la palabra “Psychology” hiciera que el libro fuera a parar a la sección de psicología. Esta sección es consultada mayoritariamente por lectores interesados en las relaciones entre personas en vez de personas con interés en la relaciones de las personas con los objetos.

Continuaré releyendo el resto del libro y comentando lo que me resulta interesante. Hasta el próximo post. Como siempre, críticas y sugerencias son bienvenidas.

author: Paltrinieri Alejandro | posted @ Sunday, April 06, 2008 7:35 PM | Feedback (0)


Diseño de Interfaces Multi-Capa


        En este post hablaré sobre un paper escrito por una eminencia en cuanto a diseño de interfaces se refiere. Hablo nada más y nada menos que de Ben Shneiderman, en los links del foro encontrarán un vínculo hacia página web personal del autor donde se pueden encentrar varios papers del mismo. Continuando con el post, el texto en cuestión es: Promoting Universal Usability with Multi-Layer Interface Design.

        El mismo comienza con una introducción que nos comenta un poco el panorama actual de la usabilidad universal. Como está creciendo el interés académico sobre el tema y la importancia de disminuir la curva de aprendizaje para los usuarios principiantes y novatos. Cabe recalcar que aproximadamente el 45% del tiempo insumido por estos usuarios es consumido por experiencias frustrantes causadas por menues confusos, ventanas de dialogo indescifrables y funciones difíciles de encontrar [1].
   
        El objetivo de ayudar a los principiantes ha generado un gran campo de investigación y una variedad de estrategias para la generación de tutoriales, ayuda en línea y manuales de usuarios. A su vez se ha trabajado sobre la simplificación de las interfaces de software. Son ejemplo de esto el ordenamiento y modulación de funcionalidades, las interfaces adaptativas (tanto automáticas como controlables por el usuario) y los sistemas de recomendación que sugieren libros, películas, etc en base al historial de compras del cliente y patrones de compras del universo de clientes.

        Basándose en que las maneras más comunes de ayudar a los principiantes consisten en elegir formas de simplificación de las interfaces que limiten en número de características, el autor promueve el uso de interfaces multicapa. Cada capa da al usuario el control sobre un set creciente de funcionalidades disponibles. En estas un usuario novato puede comenzar trabajando en la primera capa y moverse a capas superiores cuando le sea necesario o cuando disponga de tiempo para aprender. Este tipo de aprendizaje por capas es análogo al aprendizaje por nivel que se utiliza en el entrenamiento de Karate. Ejemplos de interfaces multicapa exitosas son las que presentan distintos videojuegos, en donde el jugador se va enfrentando a desafíos cada vez mayores a medida que avanza por los niveles. Otros ejemplos exitosos son algunos buscadores que posen un diseño bicapa que provee tanto a los usuarios expertos, como a los novatos, un motor de búsqueda básico y otro avanzado.

        Existen distintas variaciones en el enfoque de diseño multicapa que permiten facilitar la adaptación de productos y alinearlos con las necesidades de distintos usuarios. La siguiente imagen presenta algunas estas.

    Variaciones en el enfoque de diseño multicapa.

        Algunas aplicaciones presentan desde el principio todas las funcionalidades disponibles organizándolas en módulos o grupos (Figura 1a). Por otro lado, un diseño multicapa presenta una clara secuencia de aprendizaje y aproximadamente la misma cantidad de funcionalidad nueva en cada capa (Figura 1b). Sin embargo, algunos usuarios y diseñadores encuentran esta primera aproximación muy restrictiva. Una posible variación, conocida como “Expanding multi-layer desing”(diseño multicapa expansivo), consiste en mantener una primera capa pequeña y luego unas pocas capas más que agreguen el resto de la funcionalidad de forma creciente (Figura 1c). Por último, otra variación posible es la conocida como “Multi-layer mushtoom”(hongo multicapa). Esta presenta dos o tres capas inferiores delgadas seguidas por un diseño modular de capas que permite elegir al usuario el set de funcionalidad que considere relevante. De esta forma este último podría adaptar la interfaz de acuerdo a su profesión. Tengamos en cuenta, como ejemplo, que un ingeniero y un abogado no le dan el mismo uso a un editor de texto.

        El diseño multicapa requiere de un desarrollo cuidadoso y de muchas pruebas de usabilidad que sirvan para refinar los conceptos. Resulta difícil encontrar un orden secuencial de presentar las funcionalidades en las capas. Asimismo surgen interrogantes a la hora de encarar el diseño: ¿Cuántas capas? ¿Deben tener nombres? ¿Puede el usuario modificarlas incluyendo/excluyendo funcionalidades? Es por esto que realizar pruebas y recibir feedback del usuario resulta esencial a la hora de diseñarlas.

        Para ayudarnos en la definición de las capas podemos basarnos en patrones de uso encontrados en las versiones actuales del producto o similares (en el caso que las hubiese). Para esto se podría realizar minería sobre los datos obtenidos por medio de Instrumented Versions (versiones que incluyen una función de tracking que el usuario puede habilitar de forma voluntaria).

        En el caso que existiese manuales de entrenamiento populares para determinado tipo de aplicación, podríamos basar las capas en las secuencias de aprendizajes propuestas por los mismos.


        Otra guía consiste en orientar las capas en base a la complejidad de los documentos producidos. Por ejemplo un editor de texto podría tener en la primera capa la funcionalidad necesaria para poder redactar una nota y las capas superiores podrían ir agregando la funcionalidad necesaria para redactar resúmenes, cartas, revistas, novelas, etc.

        Uno de los motivos que hace que el desarrollo deba ser cuidadoso y complica la implementación, consiste en que es necesario acomodar la ayuda online y mensajes de error de manera que sean simples y claros limitándolos a la terminología a los objetos, funcionalidades y acciones disponibles en cada capa.

        Para promover y facilitar la comprensión del diseño de interfaz multicapa, Shneiderman presenta, a modo de ejemplo, cómo pueden ser implementados un editor de texto y una herramienta de exploración geoespacial.

Hasta el próximo post. Como siempre, criticas y sugerencias son bienvenidas.


1. Determining causes and severity of end-user frustration. Ceaparu, I., Lazar, J., Bessiere, K., Robinson, J., and Shneiderman, B. Download

author: Paltrinieri Alejandro | posted @ Thursday, January 10, 2008 12:23 PM | Feedback (0)


El caso del Robot asesino


        Hoy le toca el turno a un cuento que leí hace un tiempo y que quizá fue unos de los que me motivo a interesarme por la problemática de las interfaces. El libro en cuestión es: The Case of the "Killer Robot"1. El autor narra el caso en que un robot de la empresa Cybernetic Inc mata a un operario. El mismo está redactado por medio de recortes periodísticos de un diario ficticio llamado Sentinel Observer. En estos se puede leer como el fiscal de la ciudad acusa al programador, que escribió la parte del software que causo incidente, de ser culpable de homicidio.

        A media que vamos leyendo los recortes correspondientes a los días posteriores al incidente, nos vamos enterando de distintos hechos que ayudaron a que este ocurra. Entre estos podemos encontrar los siguientes:

  • Los empleados trabajaban bajo presión ya que el robot se tenía que entregar a tiempo. De no ser así, “rodarían cabezas”.
  • El programador acusado tenía una personalidad que no le permite aceptar las críticas, o más precisamente, no puede aceptar su propia falibilidad.
  • El proyecto fue asigando a un gerente que no tenía experiencia en el desarrollo de proyectos de este tipo. Lo que llevo a que la metodología de desarrollo utilizada no sea la más adecuada.
  • Se le dio poca importancia a la interfaz hombre-máquina.
  • El proyecto no cumplió con los niveles de calidad acordados.
  • No se realizo un entrenamiento adecuado de los operadores.
  • El diseño de la interfaz no era bueno. Me explayaré más al respecto adelante en el post.
  • Los resultados de las pruebas fueron falseados para poder cumplir con los plazos bajo la “Teoría Ivory Snow [no existe el blanco perfecto, o bien, no hay blanco más blanco que el blanco nieve]”. Esta enuncia simplemente que el blanco nieve es 99,44 porciento puro y que no hay razón por la que el software de robótica deba ser más puro que esto.
  • El programador acusado hurto parte del software que uso en el proyecto.
        Para concluir se presenta una entrevista realizada a una eminencia en lo que respecta a Tecnología y Ética, el Dr. Harry Yoder. Es interesante ver su punto de vista sobre el tema. Él considera como responsable a toda persona cuya acción haya ayudado a causar el incidente. Su opinión al respecto es la siguiente:

    “El tema de la responsabilidad del individuo versus la responsabilidad de la corporación, es un tema muy importante. La corporación creó un entorno en el que podían ocurrir este tipo de accidentes. Aún así, los individuos, dentro de ese sistema, actuaron sin ética e irresponsablemente, y fueron los que de hecho causaron el accidente. Una compañía puede crear un entorno que saca a flote lo peor de sus empleados, pero cada empleado también puede contribuir a empeorar ese ambiente corporativo. Este es un lazo cerrado que se alimenta a sí mismo, un sistema en el sentido clásico. Entonces, hay cierta responsabilidad de la corporación y cierta responsabilidad de los individuos en el caso del robot asesino.”

        Es intersante la referencia que hace Yoder al método, propuesto por Kallaman y Grillo2, a seguir para toma de decisión ética:

               … parte de su método consiste en el uso de cinco pruebas:
                  • La prueba de la mamá: ¿le diría Ud. a su mamá lo que hizo?
                  • La prueba de la TV: ¿le diría Ud. a una audiencia nacional de TV lo que hizo?
                  • La prueba del olfato: ¿lo que Ud. hizo tiene mal olor?
                  • La prueba de ponerse en el lugar del otro: ¿le gustaría que el otro le haga lo que Ud. hizo?
                  • La prueba del mercado: ¿sería su acción una buena estrategia de venta?"



Falencias de la Interfaz

        Las falencias sobre la interfaces son un tema que competen al desarrollo de mi tesis. Es por esto que decidí hacer énfasis sobre esta en este post.

        La interfaz consistía en un sistemas de menúes desplegables que permitía seleccionar una acción para controlar el robot. Ocacionalmente esta selección abriría un cuadro de dialogo. Cabe mencionar que la consola de control del robot no tenia mouse, lo que hace más tediosa la navegación por los menúes. Asimismo, estos contenían demasiados ítems y no presentaban una organización funcional o alfabetica que facilite la ubicación de la acción requerida y disminuya la carga del operador en términos de memoria. Una interfaz de manipulación directa, que mostrara literalmente al robot en la pantalla, habría sido lo ideal.

        Las pantallas de dialogo requerían que el usuario ingresara con el teclado números de partes, nombres de archivos, y otra información. El sistema podría haberse diseñado fácilmente de forma de mostrarle al usuario estos números de parte, etc., sin necesitar que el usuario recordara estas cosas de su propia memoria. Esto incrementaba la carga sobre la memoria del usuario.

        Hay que mencionar que a la hora de hacer el manejo de errores, la interfaz requería que el usuario ingrese la secuencia de comandos para cancelar el error. De este modo era necesario realizar una consulta al manual de intrucciónes a la hora de poder solucionar el problema. Hay que tener en cuenta que un problema puede requerir una actuación inmediata del operario y que una búsqueda por código de error en un manual puede insumir más tiempo del disponible. Sumado a esto, el área para escribir/leer estaba a bastante distancia de la pantalla de la computadora, o sea que era bastante incómodo y cansador para el operador manejar cualquier tarea que requiriera de mirar algo en el manual y luego actuar rápidamente con respecto al teclado de la consola.

        El uso de color y los efectos musicales en la interfaz fueron muy poco profesional. Había demasiados colores en un espacio demasiado chico y exceso de efectos musicales. Peor aun los mensajes de error podían aparecer en casi cualquier color, podían estar acompañados por casi cualquier tipo de efecto musical e incluso la ausencia de uno. Además, los mensajes de error podían aparecer en casi cualquier lugar de la pantalla.

        La interfaz no presentaba ningún tipo de ayuda en línea que permita encontrar la respuesta a las preguntas básicas del uso del sistema.

        Por último hay que mensionar que la interfaz desarrollada violó todas y cada una de “las ocho reglas de oro” de Shneiderman3 descriptas a continuación:
 

  1. Buscar siempre la coherencia. Es importante que una interfaz con el usuario sea coherente a muchos niveles. Por ejemplo, los diseños de pantalla deben ser coherentes de una pantalla a la siguiente.
  2. Permitirle a los usuarios frecuentes el uso de shortcuts. Los usuarios frecuentes (o, ‘power users’) pueden desalentarse ante tediosos procedimientos. Permitirle a estos usuarios un procedimiento menos tedioso para completar una tarea dada.
  3. Dar realimentación de información. Los usuarios necesitan ver las consecuencias de sus acciones. Si un usuario ingresa un comando pero la computadora no muestra ya sea que lo está procesando o lo ha procesado, esto puede dejar al usuario confundido o desorientado.
  4. Diseñar diálogos que tengan un fin. Interactuar con una computadora es algo así como dialogar o conversar. Cada tarea debe tener un inicio, un desarrollo y un fin. Es importante que el usuario sepa cuándo una tarea está finalizada. El usuario necesita tener la sensación de que la tarea ha alcanzado su término.
  5. Permitir manejos simples de los errores. Los errores del usuario deben estar diseñados dentro del sistema. Otro modo de decirlo es que no debe haber ninguna acción por parte del usuario que sea considerada como un error que está más allá de la capacidad del sistema para manejarlo. Si el usuario comete un error, debe recibir información útil, clara y concisa sobre la naturaleza de tal error. Debe resultar fácil para el usuario deshacer este error.
  6. Permitir deshacer las acciones con facilidad. Más genéricamente, los usuarios deben poder deshacer lo que han hecho, sea ésto o no de naturaleza errónea.
  7. Respaldar que el centro del control esté internamente. La satisfacción del usuario es alta cuando el usuario tiene la sensación de que es él o ella quien tiene el control y la satisfacción del usuario es baja cuando el usuario siente que la computadora tiene el control.
  8. Reducir la carga de la memoria inmediata. La memoria inmediata del ser humano es notablemente limitada.
        Luego de realizar el análisis de las falecias de la interfaz se me viene a la mente la siguiente frase:
       
   “La mayoría de los accidentes son atribuidos a errores humanos, pero en casi todos los casos el error humano es el resultado directo de un diseño pobre”

        Esta frase la leí en el libro “The Design Of Everyday Things” de Donald A. Norman. Libro que seguramente releeré con más detalle y escribiré sobre el mismo en este Blog.


Hasta el próximo Post.


1. The Case of the Killer Robot”, Richard G. Epstein [Ingles, Español]
2. “Ethical Decision Making and Information Technology”, Kallaman y Grillo
3. Designing the User Interface”, Shneiderman, Ben 

author: Paltrinieri Alejandro | posted @ Wednesday, January 09, 2008 1:39 PM | Feedback (0)


¿Cómo escribir una tesis?


En este post haré un breve resumen del texto: ¿Cómo escribir una tesis? de Joe Wolfe. Antes que nada quiero decir que este es un texto de lectura recomendada para cualquiera que este con la idea de escribir una tesis.
        En mi caso, a la hora de empezar me surgieron varios interrogantes: ¿Qué es una tesis? ¿Cómo debe estar escrita? ¿Cuál es la estructura que debe tener? No solo es posible encontrar una respuesta a estas preguntas en el texto, sino que también encontramos sugerencias útiles a la hora de encarar el desarrollo de una tesis. A continuación expongo un breve resumen de las respuestas a estas preguntas.

¿Qué es una tesis?

“Su tesis es un trabajo de investigación. El informe concierne a un problema o conjunto de problemas en un área definida de la ciencia y debe explicar lo que se sabe de él previamente, lo que se hacía para resolverlo, lo que sus resultados significan, y dónde o cómo se pueden proponer progresos, más allá del campo delimitado por el trabajo.”


¿Cómo debe estar escrita una tesis?

“Sin descartar la posibilidad de descubrir de pronto, un verdadero genio escritor de ciencia, que con su estilo personalísimo cautive el interés de acreditados lectores, más allá de lo supuesto, es necesario afirmar, que un escrito científico debe expresarse siempre en voz activa, con el verbo en modo infinitivo . Una tesis es un escrito científico.”

“Esta afirmación cobra mayor verdad cuando los descubrimientos científicos son de tal magnitud (como los de Albert Einstein) que la persona del científico en si, pasa a segundo plano en los escritos. Este debe despersonalizarse por completo, siempre que el escrito sirva para comunicar ciencia.”

¿Cuál es la estructura de una tesis?


  • El resumen: Esta será la parte más publicada y, por ende, más leída de la tesis. Es mejor escribirla hacia el final, pero no en el último minuto, porque requerirá de varias consideraciones vigentes relativas al proyecto. El resumen debe ser auto-contenido.
  • El índice del contenido
  • La Introducción: ¿Cuál es el tema y porqué es importante? En esta sección, hay que exponer el problema global tan simple como se pueda. No hay que sobrestimar la familiaridad del lector con el tema de la tesis. Hay que escribirla de manera de interesar al lector a continuar leyendo, este es el lugar para ser lirico. “Trate de inducir al lector a que "se muera" por leer ese kilogramo de A4.”
  • La revisión de la literatura:  ¿De dónde vino el problema? ¿Qué se sabe ya sobre el problema? ¿Qué otros métodos se han tratado para resolverlo?
  • Materiales y Métodos: “Esta sección varía enormemente de tesis en tesis, y puede estar totalmente ausente en tesis de tipo teóricas. Debe ser posible para un investigador competente, poder reproducir exactamente lo que usted ha hecho, siguiendo sus indicaciones.
  • La teoría: “Cuando usted está informando un trabajo teórico que no es original, necesitará normalmente incluir material suficiente para dejar al lector convencido de los argumentos usados y sus bases físicas.
“Cuando informe su propio trabajo teórico, debe incluir bastante más detalle, pero debe derivar explicaciones largas hacia los apéndices.”

  • Los resultados y la discusión: “Los resultados y la discusión se combinan muy a menudo en las tesis. Esto es posible debido a la longitud de una tesis.”
“En la mayoría de casos, sus resultados requieren discusión. ¿Qué significan? ¿Cómo encajan en el cuerpo de conocimientos existentes? ¿Son consistentes con las teorías actuales? ¿Dan discernimientos nuevos? ¿Sugieren nuevas teorías o mecanismos?”

  • Las conclusiones: “Son las contribuciones del autor en la confirmación o el rechazo de las hipótesis planteadas en la introducción. En cualquiera de estos casos se produce el saber científico, por lo que los artículos que los sustentan deben ser publicados de todas maneras.”
“Los resultados y las discusiones deben ofrecer suficiente evidencia científica como para respaldar a las conclusiones. Debe existir además una fuerte correlación entre la introducción (responde al qué) y las conclusiones (responden al cómo).”

  • La bibliografía: “Debe reunir los datos precisos, pertinentes y oportunos, que lleven identificar inequívocamente a la fuente de información.”
  • El apéndice


Sugerencias:

Para finalizar quisiera recalcar las siguientes sugerencias que me parecen que pueden resultar muy útiles:

  • Realizar un esquema de la tesis, esto vendría a ser como un bosquejo con los títulos, subtítulos de los capítulos y algunas otras anotaciones. Esto no solo servirá contra el “bloqueo del escritor”, sino que servirá acordar una estructura lógica con el tutor y para establecer una agenda.
  • Organizar los distintos archivos (artículos, textos, etc) tanto físicos como los lógicos. En mi caso para la organización de los archivos lógicos pretendo usar el repositorio svn junto con este blog.
  • Crear un archivo llamado “ideas” en donde volcar las distintas ideas que se nos vallan ocurriendo. Es importante tener este archivo abierto mientras nos encontramos escribiendo ya que es frecuente que se nos ocurran ideas mientras trabajamos sobre un capitulo. Las ideas hay que escribirlas rápido y sin darle mucho tiempo a la redacción, ya habrá tiempo para eso.
  • Las referencias bibliográficas son el medio para documentar los conceptos que no son propios. Las buenas referencias dicen a los lectores cuáles partes de la tesis son descripciones de conocimientos previos y cuáles partes son las contribuciones originales del autor a ese conocimiento. Por otro lado hay que tener en cuenta que estas referencias son “un indicador directo del grado de profundidad de la investigación”.
  • Es terapéutico encontrar un colega escribiendo una tesis, aunque sea de una disciplina distinta, para poder quejarse de las dificultades. En mi caso ya encontré a mis colegas. Eugenia Hesse y Lautaro Mazzitelli.

Hasta el próximo post.

author: Paltrinieri Alejandro | posted @ Thursday, January 03, 2008 7:11 PM | Feedback (0)


¡Mi primer post!



    Bueno este es mi primer post de, espero, muchos. En estos post voy a tratar de escribir sobre temas, artículos, etc que considere de interés para mi tesis de grado. También el principal objetivo de este blog es poder concentrar todo el material leído organizado de manera de poder acceder al mismo fácilmente a la hora de encarar la escritura de la tesis. Por otro lado me permitirá ver el avance realizado, cuestión que me resulta más que importante para poder mantenerme motivado y poder avanzar más rápido.
   
   El tema de estudio de la misma no lo tengo bien definido por el momento, pero mi intención es tratar sobre la problemática de las interfaces de usuario de los programas de computación. Considero este un tema sumamente importante y, lamentablemente, muy poco tratado (al menos en el ámbito de mi universidad). No olvidemos que sin una buena interfaz, puede que nunca llegue a utilizar las mejores características de un programa. Un programa puede disponer de unas herramientas muy potentes, pero si no se puede acceder a ella de forma fácil e intuitiva, el programa pierde parte de su potencia.
 
    ¿Cuántas veces se vieron mareado al abrir un programa por primera vez y encontrarse con muchísimos iconos y botones sin saber para qué sirven? Un ejemplo típico de una aplicación que presenta este tipo de problema es el editor de texto: Microsoft Word. Conozco muchos usuarios que no usan realmente todas las herramientas que este editor presenta, y no porque no las necesiten sino porque no saben que existen. Igualmente tengo que destacar que veo grandes mejoras en este aspecto en la última edición de este editor, el Word 2007.
 
    Por otro lado, quiero recalcar la importancia de la interfaces a la hora de posicionarse como líderes en el mercado. En este sentido, solo hace falta ver el desenvolvimiento de Apple para confirmarlo.
 

     Bueno, para terminar el post, me gustaría compartir con ustedes la dirección svn en donde iré guardando el material de mi tesis. La misma es: svn://drworm.no-ip.org/Tesis

    Hasta el próximo post. Criticas y sugerencias son siempre bienvenidas.



En el siguiente link pueden encontrar información de cómo usar svn en el caso de no saber: Tutorial Svn

author: Paltrinieri Alejandro | posted @ Wednesday, January 02, 2008 8:01 PM | Feedback (0)