1. PRESENTACIÓN
1.1. Datos de la asignatura
Temario
-
End-user development y lenguajes visuales y de bloques
-
Interacción multimodal y verbal
-
Entornos inmersivos: realidad virtual, aumentada y mixta
-
Videojuegos y aprendizaje: ludificación y evaluación
-
Usabilidad y experiencia de usuario
Evaluación
-
Evaluación continua del trabajo en la asignatura
Bibliografía
-
Shneiderman, Plaisant, Cohen, Jacobs, Elmqvist (2018). Designing the User Interface. Strategies for Effective Human-Computer Interaction, 6th Edition, Pearson.
-
A. J. Ko: User Interface Software and Technology, http://faculty.washington.edu/ajko/books/user-interface-software-and-technology/index.html
-
Benyon, D. (2013): Designing Interactive Systems. A comprehensive guide to HCI, UX and interaction design, Addison Wesley.
1.2. Un poco de historia
| Historia de las interfaces de usuario (WIMP) |
Vannevar Bush
Fue un físico estadounidense que trabajó en el MIT y en el Laboratorio de Investigación de la Oficina de Servicios de Guerra durante la Segunda Guerra Mundial. En 1945 publicó un artículo en la revista Atlantic Monthly titulado As We May Think en el que propuso un sistema de almacenamiento y recuperación de información basado en la idea de un hipotético dispositivo denominado memex.
Memex fue el hipotético dispositivo hipertextual propuesto por Bush, un sistema de almacenamiento y recuperación de información que permitía la navegación entre documentos y la creación de hipervínculos entre ellos. Bush propuso que el dispositivo fuera capaz de almacenar y recuperar información de forma automática, de forma que el usuario pudiera concentrarse en la búsqueda de información y no en la gestión de la misma.
Ivan Sutherland
En 1963, en el MIT, desarrolló el primer prototipo de un dispositivo de interacción humano-computador, el Sketchpad, que permitía al usuario interactuar con la computadora dibujando en una pantalla. Este dispositivo fue el antecedente de los sistemas de interacción gráfica de hoy en día.
Douglas Engelbart
En 1962, en el Stanford Research Institute, desarrolló el NLS (oN-Line System), un sistema de interacción humano-computador que permitía al usuario interactuar con la computadora a través de un teclado, un ratón y una pantalla. Este sistema fue el antecedente de los sistemas de interacción gráfica de hoy en día.
Alan Kay
En 1968, en el Xerox Palo Alto Research Center (PARC), desarrolló Smalltalk, un lenguaje de programación orientado a objetos que permitía la creación de interfaces gráficas de usuario. Este lenguaje fue el antecedente de los lenguajes de programación orientados a objetos de hoy en día.
En 1973, Xerox desarrolló Xerox Alto, el primer prototipo con interfaces gráficas de usuario WIMP (Windows, Icons, Menus, Pointer).
La interfaz WIMP de Xerox Alto fue la primera GUI que permitía la creación de ventanas, iconos, menús y ratón. Esta interfaz fue el antecedente de las interfaces gráficas de usuario de hoy en día. Xerox Alto (1973) no fue un producto comercial, pero su tecnología fue licenciada primero por Apple y luego por Microsoft para sus propios sistemas operativos. Xerox Star (1981) fue el primer producto comercial que utilizó la interfaz WIMP, pero no tuvo éxito en el mercado debido a su precio.
| WIMP |
Steve Jobs
Steve Jobs visitó el PARC de Xerox en 1979 y se llevó consigo la idea de la interfaz gráfica de usuario WIMP.
En 1983, Jobs presentó el Apple Lisa, el primer ordenador personal de Apple que operaba con interfaz gráfica de usuario WIMP y un ratón. La tecnología del Lisa fue utilizada posteriormente en el Apple Macintosh (1984), que se convirtió en el primer ordenador personal de éxito comercial con interfaz gráfica de usuario WIMP.
Bill Gates
Bill Gates incorpora la interfaz WIMP a Windows.
| Bill Gates a Steve Jobs, sobre la tecnología de Xerox |
Steve Jobs (again)
Apple incorpora las pantallas táctiles capacitivas a sus dispositivo móvil iPhone, lo que amplía el interés en nuevas formas de entrada y en las interfaces gráficas de usuario basadas en gestos.
Es importante distinguir entre las mejores interfaces de usuario para entrada y las mejores para salida.
Sam Altman
Sam Altman, director ejecutivo de Open AI, propone el término Language User Interface (LUI) para referirse a las interfaces de usuario basadas en lenguaje natural:
-
Interacciones conversacionales (chatbots)
-
Sugerencias generadas por Large Language Models (LLM)
-
Interacciones contextualizadas
A pesar de que los LLM son una tecnología clave para la interacción verbal de entrada (chatbots), las interfaces de salida siguen siendo muchas veces gráficas, visuales o de otro tipo (por ejemplo, hápticas).
1.3. Un poco de teoría
| Interfaces de usuario |
-
Comportamiento funcional determinista del ordenador
-
Las UI (User Interface) hacen un mapping de las capacidades sensoriales, cognitivas y sociales del humano hacia las funciones de la máquina
-
Las UI deben ofrecer representaciones "aprendibles" (learnable): algunas lo hacen y otras no
| Learnability ("aprendibilidad") |
|
¿Cuáles de las siguientes interfaces proporcionan representaciones aprendibles? |
|
|
¿Todas las UI proporcionan un comportamiento funcional determinista? |
| Disciplinas involucradas |
| Múltiples teorías |
-
La teoría de la actividad se centra en el análisis de las actividades que el usuario realiza con el sistema y en la descripción de las tareas que el usuario realiza con el sistema.
-
Los modelos conceptuales se basan en la idea de que el usuario tiene una representación mental del sistema y que esta representación mental se construye a partir de la experiencia del usuario con el sistema.
-
La semiótica se basa en la idea de que el usuario interpreta el sistema como un conjunto de signos.
| Affordances ("asequibilidades") y feedback (retroalimentación) |
|
|
¿Qué implica este significante? |
1.4. Temario detallado
Tema 1. Interacción + Lenguajes visuales y de bloques
Teoría Estilos de interacción End-user development Lenguajes visuales de bloques |
Herramientas Scratch, Snap!, App Inventor, Tinker CAD, Workflows N8N, etc. |
Tema 2. Interacción multimodal y verbal
Teoría Interacción multi-modal Interfaces verbales |
Herramientas DialogFlow, IBM Watson, Amazon Lex, Rasa NLU, N8N, ChatGPT, etc. |
Tema 3. Entornos inmersivos: realidad virtual, aumentada y mixta
Teoría Conceptos Dispositivos y demostración |
Herramientas Vuforia, Unity 3D, VEDILS, etc. |
Tema 4. Videojuegos y aprendizaje: evaluación y ludificación
Teoría Videojuegos como herramientas de aprendizaje, gamificación y evaluación |
Herramientas Twine, H5P, etc. |
Tema 5. Usabilidad y experiencia de usuario
Teoría Usabilidad, Experiencia de usuario, Accesiblidad, Arquitectura de la información, Diseño de la interacción |
Herramientas Evaluación de UX |
2. ESTILOS DE INTERACCIÓN
| Estilos de interacción representativos |
2.1. Manipulación directa
-
Es el paradigma inherente en las interfaces WIMP (Windows, Icons, Menus and Pointers)
-
Uso intensivo del drag-and-drop
-
Navegación fluida
Características de la manipulación directa
Ejemplos de manipulación directa
-
Sistemas de información geográfica con GPS
-
Videojuegos
-
CAD/CAM
|
|
¿Son las interfaces interactivas tipo WIMP naturales o aprendibles? |
| Ver la serie The Billion Dollar Code sobre los orígenes de Google Earth. |
Futuro de la manipulación directa
|
|
¿Qué futuro espera a la manipulación directa? |
-
Pantallas táctiles
-
Interfaces 2D y 3D
-
Inteligencia artificial
Distancia traslacional
Distancia entre el usuario y la representación de la metáfora
|
|
¿Qué distancia traslacional suponen estas UI? |
2.2. Lenguajes de comandos
2.3. Lenguajes de programación visual
| Los primeros lenguajes propuestos por el End-user development |
Lenguajes de bloques
Lenguajes de construcción y modelado
2.4. Lenguaje humano
| A tratar en el tema Interacción multimodal y verbal |
2.5. Entornos inmersivos
| A tratar en el tema Entornos inmersivos |
3. END-USER DEVELOPMENT
Los usuarios más avanzados suelen necesitar poder personalizar o ampliar las aplicaciones que manejan. Por ejemplo: Organizar recetas de cocina con Airtable.
-
Algunos programas y apps pueden tener un cierto grado de libertad para configurar su comportamiento. Otros son cajas herméticamente cerradas a las que un usuario avanzado puede querer modificar de su comportamiento.
-
Si no hay un botón que haga exactamente lo que el usuario quiera, su única alternativa es pedírselo al desarrollador del programa (al que le puede resultar conveniente hacerlo o no, y si lo hace normalmente querrá cobrar por ello).
Esta es una reclamación tradicional de los defensores del software libre y FLOSS (Free and Libre Open Source). En la práctica, reconstruir una aplicación y modificarla a partir del código fuente requiere un esfuerzo y exige habilidades avanzadas de desarrollo de software.
-
Algunas herramientas permiten plugins que se ejecutan dentro de la aplicación principal para hacer las ampliaciones o modificaciones.
-
Otras herramientas ofrecen una Application Programming Interface (API) para que los desarrolladores puedan hacer esas ampliaciones desde fuera y dejen a la aplicación principal hacer el resto.
El software debería ser ampliable y extensible de una forma más fácil y rápida, para que cualquier usuario final o end-user pueda automatizar, personalizar o construir su propia herramienta a partir de una dada. Para ello necesitan un lenguaje de End-User Development (EUD).
-
El objetivo de la HCI/HMI pasa de hacer sistemas fáciles de usar a hacer sistemas fáciles para desarrollar
-
Desafío ⇒ construir sistemas que permitan a usuarios sin conocimientos de programación combinar de forma creativa artefactos hechos de software
-
Combinación de artefactos ⇒ crear, modificar y ampliar artefactos software
-
Los end-users no son desarrolladores profesionales
A set of methods, techniques, and tools that allow users of software systems, who are acting as non-professional software developers, at some point to create, modify, or extend a software artifact
End-User Development: An Emerging Paradigm
3.1. End-User Programming
|
|
¿Por qué end-user? |
-
Los ingenieros de software profesionales construyen aplicaciones de propósito general diseñadas para ser empleadas por muchas personas
-
Los programadores end-user son usuarios avanzados, no necesariamente programadores profesionales, que modifican o crean herramientas ad hoc para su uso personal o para compartir con unos pocos colegas, todo lo más.
|
Lectura recomendada |
|
|
¿Por qué algunos ingenieros prefieren Python y otros Excel? |
| Python en Excel |
3.2. Computational Thinking
Los entornos y lenguajes de EUD ofrecen la capacidad de crear con una herramienta, más allá de la capacidad de usar una herramienta.
[…] incorporates both understanding (as is the focus in most traditional science) and shaping (as is the focus in engineering and other professions)
On Computing: The Fourth Great Scientific Domain
Pero para poder crear y desarrollar software, hacen falta unos mínimos conocimientos y habilidades sobre los conceptos básicos sobre lo que un ordenador puede hacer, cómo lo hace y cómo instruirlo para que lo haga. Esto es el terreno del pensamiento computacional o computational thinking subyacente al Computing (en español, traducido por "Informática").
Computational Thinking involves solving problems, designing systems, and understanding human behavior, by drawing on the concepts fundamental to computer science.
Computational thinking is a fundamental skill for everyone, not just computer scientist […]; involves solving problems, designing systems, and understanding human behaviour, by drawing on the concepts fundamental to CS […]; is thinking recursively. It is parallel processing […]; is using abstraction and decomposition when […] designing a large complex system […]; is thinking in terms of prevention, protection, and recovery from worst-case scenarios […]; is using heuristic reasoning to discover a solution.
Computational Thinking -- Communications of the ACM
|
|
¿Recuerdan a Vannevar Bush? |
|
|
Lectura recomendada |
3.3. Low code
El low code es una evolución del EUD, que permite a los usuarios crear aplicaciones sin necesidad de escribir mucho código.
Algunos ejemplos de lenguajes de low code son:
-
Microsoft PowerApps
-
Google AppSheet (sucesor de App Maker)
-
Apple SwiftUI / Swift Playgrounds
-
Oracle Visual Builder y Oracle APEX
-
Salesforce Lightning
-
Mendix
-
GeneXus
-
OutSystems
3.4. Embodiment o Encarnación
Una de las partes más difíciles de la construcción de software es que requiere que el programador mantenga varias abstracciones en su mente. El programador debe comprender el dominio del problema, modelar las estructuras de datos y el flujo del programa, y finalmente trasladar todo a una representación simbólica (código en un lenguaje).
La capacidad de razonamiento abstracto y concentración exigida a un ingeniero de software para escribir software no es viable para alguien que solo quiere resolver su problema particular mediante el ordenador y que suele ser experto en otros dominios ajenos al de la programación.
Hacen falta formas que requieran menos razonamiento abstracto y menos capacidad mental para modelar los programas y los datos, dejando más capacidad para pensar en el dominio de la aplicación.
Una forma de hacer esto es el embodiment o encarnación, es decir, ofrecer al usuario final representaciones concretas para los elementos de un programa que funcione.
Las encarnaciones son normalmente visuales, pero también de otros tipos (auditivas, hápticas, etc.)
|
|
¿Excel usa alguna encarnación? |
3.5. Programación literaria
-
Literate Programming: Invento de Donald Knuth en 1983
-
El código fuente se parece mucho más a un documento que a un listado de código
-
Bloques de código embebido en un documento
-
Genera un documento legible junto a código ejecutable
|
|
Lectura recomendada |
3.6. Herramientas
Herramientas GUI
Lenguajes block-based
-
Microsoft
Lenguajes mixtos
4. UX E INTELIGENCIA ARTIFICIAL
4.1. Evolución del EUD
El EUD ha evolucionado en tres grandes generaciones:
-
En la primera, el usuario debía escribir todo el código directamente, lo que exigía conocimientos técnicos avanzados y limitaba la creación de soluciones a perfiles especializados.
-
La segunda generación trajo plataformas de low code y no code, donde los usuarios podían construir aplicaciones y automatizaciones mediante interfaces visuales, arrastrando y configurando bloques, reduciendo la dependencia de programadores expertos.
-
Una tercera generación, impulsada por la IA Generativa y el prompting, permite que los usuarios describan lo que quieren en lenguaje natural y el sistema genera, adapta o ejecuta el flujo automáticamente a través de agentes inteligentes (v.g. herramientas tipo n8n). Esto democratiza aún más la creación.
4.2. La IA y el futuro de las UI
Según Enrico Tartarotti, la muerte de las UI que se han utilizado durante los últimos 40 años se considera un hecho. A pesar de los esfuerzos recientes por perfeccionar y embellecer estas interfaces, las mismas compañías están intentando eliminarlas por completo, reemplazándolas con simples "prompts de texto en blanco y negro" que recuerdan a las líneas de comando de los años 80.
Esta transición se debe a que, si bien las UIs tradicionales son muy buenas para la salida (mostrar información de forma visual), son deficientes en la entrada (la necesidad de navegar por menús y hacer clics).
Por el contrario, los nuevos chatbots han resuelto el problema de la entrada al "entender" el lenguaje natural, aunque su salida sigue siendo el texto plano. En el futuro post-UI, las interfaces no se construirán, sino que se generarán sobre la marcha a través de agentes que responden al lenguaje, lo que puede llevar a que las UIs desaparezcan en gran medida.
4.3. La IA como sistema operativo
El intento de OpenAI de usar ChatGPT como un sistema operativo (SO) o interfaz universal para todas las aplicaciones se resume en su ambición de convertir a ChatGPT en una plataforma de aplicaciones, buscando reemplazar o evitar la necesidad de las GUI tradicionales. Este esfuerzo ha pasado por varias fases y se basa en la idea de que la forma de interactuar con el software está cambiando fundamentalmente.
La analogía que se hace es que los LLM tienen propiedades que los asemejan a los sistemas operativos (SO).
-
ChatGPT como plataforma: OpenAI está apostando fuertemente por convertir a ChatGPT en una plataforma de aplicaciones. El objetivo es que ChatGPT actúe como un SO que te mantenga completamente encerrado en su ecosistema.
-
La analogía del SO: Los LLMs se ven como una especie de nuevo sistema operativo. El LLM en sí es como la CPU y las ventanas de contexto son como la memoria. El LLM orquesta computación y memoria para resolver problemas.
El experimento de la interfaz universal
OpenAI ha intentado varias aproximaciones para lograr que ChatGPT sea la interfaz de interacción principal:
-
Inicialmente, lanzaron GPT Plugins
-
Luego, intentaron una ligera variación llamada GPTs
-
Actualmente, están intentando implementar Apps in ChatGPT.
El paradigma de la entrada y salida
La clave de este intento radica en la capacidad de los chatbots para manejar la entrada del usuario de forma humana, aunque su salida sea actualmente deficiente:
-
Entrada: con un chatbot puedes "divagar" en modo de voz o escribir un prompt mal formado, y el LLM es muy bueno para entender lo que quieres.
-
Salida: sin embargo, fallan en la salida; son malos mostrando la información o haciéndote sentir en control, volviendo a interfaces similares a las líneas de comando de los años 80.
Agentes autónomos
AgentKit de OpenAI es un conjunto unificado de herramientas diseñado para que los desarrolladores puedan construir, desplegar y optimizar agentes de IA (agents).
Es la alternativa de OpenAI a soluciones open source como n8n.
4.4. Autonomía parcial
Andrej Karpathy considera las aplicaciones parcialmente autónomas como una de las mayores oportunidades en la era del software impulsado por LLM. Estas aplicaciones representan una forma de interactuar con los modelos de lenguaje que va más allá de simplemente usar el LLM directamente como una terminal o un sistema operativo (como copiar y pegar código en un chat).
Estas aplicaciones están diseñadas para la cooperación entre humanos e IA (Human in the loop). En esta cooperación, la IA se encarga de la generación del trabajo, mientras que los humanos realizan la verificación o auditoría. El objetivo principal es hacer que este ciclo de generación y verificación sea lo más rápido posible.
Aplicaciones parcialmente autónomas
Las aplicaciones parcialmente autónomas, como Cursor (para programación) y Perplexity (para investigación), comparten varias propiedades fundamentales:
-
Gestión del contexto: Los LLM dentro de estas aplicaciones manejan una enorme cantidad de la gestión del contexto por el usuario.
-
Orquestación de LLMs: Orquestan múltiples llamadas a diferentes modelos LLM, incluyendo modelos de embeddings, modelos de chat y modelos específicos que aplican cambios (como diffs de código).
-
GUI Específica: Poseen una GUI especializada para la aplicación.
-
La GUI es vital para la auditoría, ya que utiliza la capacidad de visión artificial 😉 del cerebro humano.
-
Leer texto es un esfuerzo, pero mirar representaciones visuales es rápido y fácil. Por ejemplo, es más fácil ver un diff de código en rojo y verde que leerlo en texto, y es más rápido aceptar o rechazar un cambio con un comando de teclado que escribirlo.
-
-
Control deslizante de autonomía (autonomy slider): El usuario debe tener control sobre el nivel de autonomía que desea otorgar a la herramienta.
-
Esta autonomía se puede ajustar según la complejidad de la tarea.
-
El rango puede ir desde una baja autonomía (como la finalización con un toque o modificar solo un fragmento de código) hasta la autonomía total del agente (como permitir que el agente modifique todo un repositorio).
-
Atar en corto a la IA
Dado que los LLMs son sistemas falibles y propensos a alucinaciones y déficits cognitivos, es crucial "atar en corto" a la IA.
-
La IA puede ser sobre-reactiva y generar resultados excesivamente grandes (como un diff de 10,000 líneas de código) que se convierten en un cuello de botella para la verificación humana.
-
Para que el bucle de generación-verificación sea rápido, es mejor trabajar en trozos pequeños e incrementales. Esto se logra siendo más concreto en las indicaciones (prompts).
Al igual que sucedió con el piloto automático en la conducción autónoma (un producto de autonomía parcial), la dirección correcta es construir productos de autonomía parcial en lugar de grandes demostraciones llamativas de agentes totalmente autónomos. Durante la próxima década, la oportunidad reside en desarrollar software que mueva gradualmente ese control deslizante de autonomía hacia una mayor automatización.