Modelo para enTornos Interactivos basados en Sonido para Aprender, mTISA

Jaime Sánchez Departamento de Ciencias de la Computación

Universidad de Chile Chile

jsanchez@dcc.uchile.cl

Nelson Baloian Departamento de Ciencias de la Computación

Universidad de Chile Chile

nbaloian@dcc.uchile.cl

Héctor Flores Departamento de Ciencias de la Computación

Universidad de Chile Chile

hflores@dcc.uchile.cl

RESUMEN El software educativo ha sido continuamente criticado por no utilizar modelos explícitos que permitan su generalización y replica. Prácticamente cada software educativo posee un modelo implícito que no siempre es develado. En el último tiempo diversos investigadores en los EEUU, Reino Unido y Chile han desarrollado una diversidad de interfaces para niños ciegos basadas en sonido especializado. Este estudio tiene por finalidad proponer un modelo para enTornos Interactivos basados en Sonido para Aprender, mTISA. Este modelo intenta cubrir una necesidad por modelos de desarrollo de software para niños ciegos, tanto para futuras réplicas en otros contextos, como para fines de evaluación y mejoramiento de software. Es así como mTISA consiste en un modelo de procesos con su arquitectura, incorporando funcionalidades para evaluar y retroalimentar al aprendiz, así como establecer diferencias cualitativas en el desarrollo de software educativo para personas con y sin discapacidad visual.

1. Introducción Un principio indiscutido para el diseño de sistemas que apoyen el aprendizaje por medio de computadores es que se deben aprovechar todas las capacidades multimediales de las máquinas. Esto implica necesariamente que usuarios con discapacidades sensoriales visuales tendrán problemas o estarán definitivamente imposibilitados para usarlos. Por ello, se han desarrollado varios sistemas especiales para estos usuarios. Los sistemas dirigidos a usuarios con discapacidades visuales persiguen principalmente facilitar el acceso al mundo digital, cuyos sistemas están basados en gran medida en interfaces gráficas, como es el caso de los juegos (educativos o no) y la navegación en la Web. Es entonces necesario traducir, adaptar o proyectar la información que normalmente se presenta en forma gráfica por otros medios susceptibles de ser percibidos por estas personas. Este trabajo propone un modelo de desarrollo software educativo para personas con discapacidad visual. El modelo se centra en incorporar las funcionalidades necesarias para poder evaluar y dar correcta retroalimentación al aprendiz, y establecer las diferencias en el desarrollo de software educativo para las personas con discapacidad visual, con el desarrollo de software educativo para personas capaces de interactuar visualmente con el computador. El modelo consta de dos partes: un modelo de los procesos que permite obtener un software educativo para personas con discapacidad y la arquitectura del sistema resultante al aplicar el modelo de procesos. El objetivo de contar con un modelo como el aquí descrito es servir de guía para el desarrollo de nuevos sistemas y ayudar a la evaluación (y posible mejora) de sistemas ya existentes. 2. Sistemas para personas con discapacidades visuales Se han desarrollado diversos sistemas que implementan entornos virtuales o "realidades virtuales" con interfaces humano-computador capaces de ser usadas por personas ciegas. Estos se basan en la presentación de información gráfica por traductores text-to-speech que leen las páginas Web desplegadas en un browser y entornos de navegación de espacios tridimensionales mediante sonidos que se alejan, se acercan o se mueven para la representación mental del espacio [5] o para que los usuarios adquieran o desarrollen habilidades cognitivas [9]. Esto se puede ver en [6] en que personas no videntes desarrollan formas especiales de navegación dentro de un ambiente desconocido y representan estructuras espaciales con dificultad cognitiva. Además, estos sistemas se han desarrollado para ser utilizados con diferentes dispositivos de input, como concepts keyboards, tablets, switches e interfaces táctiles [13] con forcefeedback[7]. The HOMER UIMS producido por Anthony Savidis y Constantine Stephanidis [8,9] desarrolla interfaces duales para la integración de videntes y no videntes. HOMER integra la interacción visual y no visual con objetos y sus relaciones. El Browser BrookesTalk reproduce una página Web usando voz sintetizada en palabras, sentencias, y párrafos, ofreciendo diferentes vistas de la página Web para simular un “scanning” [10]. Un juego para la concentración auditiva descrito en [2] consiste en juntar pares de diferentes niveles de figuras geométricas, básicas y derivadas. Para la representación gráfica de figuras geométricas se necesita construir un espacio de sonido bidimensional. Este concepto permite a la representación gráfica, por ejemplo los iconos, ser representada por la percepción de sonidos en movimiento en el plano espacial. En 1989 Meera Blattner introdujo los “earcons”, como mensajes de audio no verbales que proveen información a los usuarios acerca de los objetos del computador, operaciones e interacciones [11,12]. Cada dimensión corresponde a un instrumento musical y los puntos de la trama corresponden a pares de frecuencias sobre una escala. El movimiento horizontal de izquierda a derecha es equivalente a una variación de frecuencia del primer instrumento, y el movimiento vertical como la variación de frecuencia del segundo de ellos. Para personas no videntes los sistemas tienden a transformar la información gráfica en un formato háptico o audible. AudioDoom[1,3] permite a niños no videntes explorar e interactuar con mundos virtuales usando sonido espacializado. Este fue inspirado por el tradicional juego Doom, donde el jugador se mueve dentro de pasillos descubriendo el ambiente y resolviendo problemas simulados

con objetos y entes que habitan en el mundo virtual. VirtualAurea por Sánchez [3] fue desarrollado después que se probara que los ambientes virtuales basados en sonido generan el desarrollo de estructuras cognitivas espaciales en niños no videntes. VirtualAurea es una herramienta de editores de sonido espacial que puede ser usada por padres y profesores para el diseño de una amplia variedad de mapas espaciales, como por ejemplo, la estructura interna de la escuela y salas, pasillos y otras estructuras de una casa. Los usuarios pueden así integrar diferentes sonidos asociándolos a objetos y entidades en una historia. VirtualAurea ha sido usado para desarrollar estructuras cognitivas espaciales y temporales complejas en niños no videntes. 3. Modelo del proceso de desarrollo del sistema El modelo tiene como hipótesis que el sistema de aprendizaje se basa en la representación computacional de una situación real, es decir, el ambiente virtual con el cual el aprendiz interactúa es una representación de algún sistema real imaginado y existente.

Figura 1. Modelo del proceso de desarrollo

El primer paso en el proceso de diseño es sin duda reconocer, delimitar y describir las metas cognitivas que el usuario deberá alcanzar al usar este software. En general, la literatura señala que los sistemas para personas con discapacidad tienen por objetivo ayudar a corregir alguna deficiencia en el aprendizaje, comunicación o acceso causada por la discapacidad. Esto determina, por un lado, la alegoría del mundo real que se usará como ambiente de interacción y por otro, las definiciones para evaluar el desempeño del alumno [14]. Esto último implica definir un modelo para representar el conocimiento conjuntamente con el modelo que represente qué porción del conocimiento ha o no ha adquirido el alumno. Una vez definido el entorno y sus reglas y los parámetros para medir el aprendizaje, se procede a modelar la situación produciendo así el modelo computacional del mundo real a representar y el modelo computacional del conocimiento a adquirir, así como un modelo del aprendiz. El siguiente paso es realizar la proyección del modelo en una interfaz que sea asequible para la persona con discapacidad. Lo que se debe proyectar aquí son principalmente las variables de salida del modelo al igual que el feedback y/o resultado de la evaluación que le dará el sistema al aprendiz. Aquí se debe tener en cuenta todos los dispositivos de interacción (tradicionales o no) de que se disponga y evaluar cuáles de ellos podrán de mejor manera servir para proyectar los valores del modelo (tanto los de entrada como los de salida).

Luego, se utiliza y testea la efectividad del software. Esta evaluación debería realizarse a los distintos niveles de interacción descritos en [3]: Apresto, exploración, adopción y apropiación. Finalmente, el proceso entra en un ciclo en que los resultados de esta evaluación podrían cambiar algunos de los componentes del sistema 4. Modelo de la arquitectura del software resultante Para describir el modelo utilizaremos la metodología que usa Zeigler [15]. Esta consiste primero en presentar una definición informal a través de un esquema de las componentes y sus interacciones que participan en el sistema. Las componentes son entes del modelo que generan datos, es decir, contienen variables. La descripción formal debe utilizar un lenguaje formal para describir las interacciones y las transiciones entre los estados del sistema.

4.1. Definición informal del modelo Aplicando el proceso de desarrollo descrito en el punto anterior debería resultar un sistema con una arquitectura como la que describe la figura 2.

Figura 2. Arquitectura del sistema resultante Para el modelo presentado se determinan los siguientes componentes: 4.1.1 Metáfora del mundo real: (Modelo) Según la definición de las habilidades cognitivas que se estimulan se diseñan metáforas de la vida real y actividades que realizará el alumno para lograr las metas cognitivas, teniendo en cuenta la motivación que provean estas al alumno. 4.1.2 Editores Son herramientas para la construcción de un modelo interno basado en representación gráfica en 2D/3D y/o representación auditiva. Para las personas con discapacidad los modelos pueden ser generados usando acciones drag and drop sobre iconos o imágenes de una galería. Las representaciones equivalentes de estas entidades se deben dar en la forma de texto o de transcripción fonética. Las personas con ceguera eligen los elementos de los mundos internos generados a través del uso de tablets sensibles o dispositivos hápticos.

4.1.3 Representación computacional del sistema real Este componente corresponde a la representación computacional del problema o metáfora del mundo real, es decir, modela el conocimiento. En esta componente están las funciones, los parámetros y las variables del estado del sistema que describen la situación en que se encuentra el mundo representado y cómo se realizará la transición de un estado a otro, dada la interacción del aprendiz con el sistema y reflejado en las variables de entrada. 4.1.4 Estrategias Esta componente proporciona las estrategias a utilizar para modelar el estado del conocimiento del aprendiz. Estas son aportadas por la Inteligencia Artificial (IA) aplicada a tutores inteligentes. Alguna de estas son: Modelo Overlay [16], que trata el conocimiento del aprendiz como un subconjunto del conocimiento de un experto, Modelo Diferencial [17], el cual es una modificación del modelo anterior y divide el conocimiento del aprendiz en dos categorías: conocimiento que el aprendiz debería conocer y conocimiento que no se esperaría sea conocido por el aprendiz y Modelo de Perturbación [16], el cual supone que el aprendiz posee conocimiento potencialmente diferente en cantidad y calidad respecto a un experto. Este último puede representar el conocimiento y las creencias del aprendiz más allá del rango del modelo del experto. 4.1.5 Modelo del aprendiz Esta componente representa lo que el sistema "piensa" que el alumno ha aprendido hasta ahora. Contiene una representación del conocimiento o habilidades que el alumno debe adquirir, las variables de estado del alumno que representan el nivel de aprendizaje para un momento dado y las reglas sobre cómo se actualiza esta información dada la interacción del alumno con el sistema, y reflejada en el cambio de un estado a otro del modelo del mundo real. Así, el modelo del alumno está dado por el proceso de inferir el conocimiento de un individuo analizando su comportamiento [4]. 4.1.6 Evaluación Esta componente define la diferencia que existe entre el modelo del conocimiento representado en el sistema y el modelo del conocimiento del alumno generado por las estrategias. Así, se genera una medida de error que es proyectada a la interfaz como retroalimentación al alumno. 4.1.7 Sistema de proyección Es el componente principal para certificar que el sistema será asimilado íntegramente por un usuario no vidente. Es el encargado de generar la proyección de todas las interacciones, variables de estado y feedbacks desde y hacia el sistema, en el capítulo 6.5 de este trabajo se presentan atributos para el desarrollo adecuado de software para no videntes.

4.2 Definición Formal del Modelo Para una definición formal podemos definir al modelo por medio de las siguientes funciones: 1) f ),(),(

1 stet ssssii +

→

ts : variables de estado del sistema en el momento t.

es : variables de entrada al sistema

ss : variables de salida

2) 11 ),,( ++ → tttt assag

at: variables de estado del modelo del alumno en un instante t. Esta función representa el cambio en las variables que describen el estado del alumno en cuanto a su aprendizaje, debido a los resultados de la última interacción.

3) tt eaaE >−),(a : representa el conocimiento o habilidad al que idealmente debe llegar el alumno. Esta información está representada interiormente en el sistema.

te : representa la evaluación del sistema al estado de aprendizaje del alumno Esta función contrasta el nivel actual de aprendizaje del alumno, representado por las variables de estado del alumno, con el nivel ideal al que debería llegar y emite una medida de evaluación o error. Esta debe servir para emitir un feedback que el alumno pueda usar para corregirse. Tanto el feedback como las variables de salida deben reflejarse en una proyección de sus valores sobre los dispositivos de salida. Para la proyección de los elementos del sistema en la interfaz se modela con la siguiente función:

4) e

ts

sIPyIesP

→

→− )(

),(1

I : Interfaz del sistema, dispositivos de salida

Debe existir también el proceso inverso, es decir, el que mapea las entradas al sistema en valores para las variables de entrada del sistema. P dependerá de los dispositivos de entrada y salida que se puedan usar con usuarios ciegos, y es junto a la especificación de las metas cognitivas que se deben alcanzar con el software que se diseña, la parte del modelo que más diferencia el desarrollo de un software para usuarios sin discapacidad de uno para usuarios con discapacidad. Aislar esta parte del resto del diseño tiene por objetivo concentrar la atención de los diseñadores en las posibilidades que se pueden aprovechar para desarrollar un software educativo para personas con discapacidad. De esta forma, se evita que el diseño se limite desde su concepción por el hecho que la interacción con el usuario esté de alguna manera limitada. 5. Guidelines El objetivo de esta sección es definir los atributos, características y criterios que deben ser considerados en la elaboración de software para personas ciegas y con baja visión. ¿Qué elementos debe poseer un software educativo para ciegos?, ¿Cuál es la importancia que reviste cada uno de estos elementos?, ¿Poseen todos la misma importancia?, son las preguntas fundamentales que orientan el presente análisis. Para resolver estas interrogantes y poder establecer una tipología de software educativo para no videntes, hemos determinado realizar, en primer lugar, una revisión de la relación del software y los modelos de aprendizaje, para determinar si es posible distinguir diferentes tipos de software educativo para personas ciegas, según sea el modelo de aprendizaje en que se basan. Posteriormente, se analizará cada uno de los atributos genéricos del software educativo con el objetivo de adaptarlos a la realidad educativa de los ciegos definiéndolos operacionalmente. Finalmente, buscamos proponer criterios de evaluación específicos para este tipo de software, a la luz del análisis realizado de los atributos genéricos y de los criterios de evaluación de software educativos propuestos Sánchez [18] en el libro “Aprendizaje Visible Tecnología Invisible”. Como ejemplo, se aplicará la evaluación con estos criterios al software para no videntes desarrollados por nuestro equipo de investigación: AudioBattleShip, AudioMemorice, VirtualAurea, El Castillo Musical, AudioDoom y a Granja de Theo y Seth

5.1. Tipología de Software Educativo Basado en Sonido para Personas Ciegas

5.1.1. Software educativo basados en sonido para personas ciegas y modelos de aprendizaje Tal como señala Sánchez [18], si relacionamos los diferentes modelos de aprendizaje con el diseño de software, encontraremos que existen tres tipos de software educativo: presentación, representación y construcción. La definición y caracterización de estos depende de las teorías o metodologías de aprendizaje que subyacen en cada caso, no obstante la puesta en práctica de estos modelos teóricos o metodológicos se ven matizados cuando se trabaja con no videntes, por lo tanto también creemos necesario hacer visible esta diversificación en el caso del software educativo.

5.1.2. Software educativo de presentación de información y conocimiento para

personas ciegas Definido como aquél software que sólo presenta información y conocimientos bajo un modelo tutorial de aprendizaje basado fundamentalmente en modelos conductistas del aprender y en que el usuario tiene una baja intervención en la acción, el control y el ritmo de desarrollo del software, ya que estas características están previamente determinadas por el software. La elaboración de software educativo para ciegos bajo esta modalidad debe considerar los siguientes aspectos: La presentación de la información del software educativo debe ser clara y concisa, no debe ser muy extensa, ya que se debe considerar que se entregará auditivamente. De gran importancia resulta que la verbalización considere todas las entonaciones, flexiones, tonalidades, etc., existentes en la emisión de un mensaje para favorecer que la recepción de la información del usuario ciego sea fidedigna.

El software educativo debe ser elaborado considerando una secuencia de aprendizaje que vaya por etapas, pequeños pasos de creciente complejidad y abstracción. La presentación de información en el software educativo debe considerar el desarrollo secuencial de unidades temáticas que discrimine y profundice los conceptos considerados más importantes. El software educativo debe utilizar comandos para revisar un contenido y/o ingresar a la búsqueda de información, se sugiere limitarlos al uso a aquellas teclas que ya resultan conocidas por los ciegos, por ejemplo los comandos del software Jaws y controles de Windows, que les resultan más familiares. La información contenida en el software educativo debe ser de fácil acceso y considerar indicaciones claras que apoyen la exploración de la misma.

El software educativo debe poseer una ayuda que debe estar siempre presente para favorecer el aprendizaje cognitivo. Se debe tener en cuenta que este tipo de software educativo es recomendable sólo para entregar información al ciego, la que debe ser complementada con tareas y actividades concretas, de otra manera no tendrá ningún significado. El uso de este tipo de software podría resultar un excelente complemento para trabajos expositivos o de investigación del alumno.

5.1.3. Software educativo de representación de información y conocimiento para

personas ciegas El software de representación de información y conocimiento se orienta a organizar la información y el conocimiento de la misma forma como se organizaría en la memoria. Este software debiera considerar lo siguiente para su elaboración. Las actividades que el alumno pueda realizar y representar en el software educativo deben estar organizadas de tal manera que le permitan orientarse, saber dónde está, que lugares ha recorrido y hacia dónde puede ir.

El software educativo puede presentar diferentes niveles de representación de la información, pues así el alumno podrá transitar desde las ideas más generales a las más específicas. Esto le ayudaría a formular su propio mapa conceptual. El software debe presentar los contenidos considerando las experiencias más cercanas de los aprendices, para lograr aquellas que son menos significativas o desconocidas por ellos. Las explicaciones del software educativo, sean estas verbales o gráficas, deben motivar a que el alumno vaya incorporando nuevos conceptos que amplíen el significado de los ya existentes. Se sugiere que este tipo de software educativo incluya funcionalidades que le permita al alumno manejar, representar y organizar efectivamente la información que el software presenta.

5.1.4. Software educativo de construcción de información y conocimiento para

personas ciegas El software para construcción de información y conocimiento es aquél que centra su acción en el alumno, le provee de herramientas, materiales, elementos y estrategias para construir y reconstruir su propio conocimiento. En su elaboración el software para construcción de información y conocimiento debe considerar los siguientes aspectos. Una organización interna y manejo detallado de la funcionalidad de las herramientas disponibles (audio, imágenes, texto), clasificadas y de fácil acceso, por lo tanto el diseño de este tipo de programas debe contemplar estrategias para familiarizar el software y su funcionalidad con el usuario final.

Este tipo de software debe considerar la construcción del conocimiento, entregando al usuario a través de las herramientas disponibles, la oportunidad de utilizarlo como medio de exposición y presentación de la información y conocimiento que ha construido. El software debe permitir al usuario desarrollar nuevas ideas o conceptos basados en el conocimiento pasado y presente, a través de la selección y transformación de información, construcción de hipótesis y la toma de decisiones.

En consecuencia, el software debe considerar la posibilidad que el alumno pueda volver a trabajar múltiples veces y en diferentes momentos sobre el material o contenido específico, para favorecer la construcción de lo que ha aprendido previamente. De esta manera, se logrará la reorganización de la estructura cognoscitiva, la cual se modifica según se incorporen nuevos conocimientos. Asimismo, debemos considerar mecanismos que hagan presente al alumno la existencia de estas nuevas estructuras. Este tipo de software educativo debe estar orientado a usuarios que posean un alto dominio informático, para que su acción se centre en la tarea que desarrolla, más que en el uso del dispositivo.

6. Atributos Genéricos del Software Educativo Basado en Sonido para Personas Ciegas

6.1. Constructividad Este aspecto implica que el software debe permitir al usuario ejecutar acciones y construir a partir de las herramientas del software. En el caso del software educativo para ciegos, este atributo se logra en la medida que se entreguen las pistas necesarias que permitan construir un esquema mental en el usuario, aspecto que le ayudará a desenvolverse en el ambiente virtual. Este aspecto es muy importante porque la constructividad debe estar orientada a construir un concepto general de software en los usuarios ciegos, concepto que hasta ahora no existe, así como debe permitir que el usuario interactúe directa y libremente con los elementos que se le presentan y poder decidir respecto al resultado final. Cabe destacar que la constructividad se encuentra directamente relacionada con la etapa de apropiación del software. Mientras más afianzada esté la etapa de apropiación en el usuario, mayor será el nivel de constructividad que desarrolle.

Para favorecer el desarrollo de la constructividad en el usuario ciego debe existir o hacer lo siguiente: Un guión que contextualice en forma general el software Un diálogo permanente entre el software y el usuario Los diálogos deben ser precisos respecto de los sucesos Las pistas auditivas deben ser estandarizadas y no arbitrarias Estandarizar el uso de periféricos Estandarizar la distribución de elementos Incrementar los contenidos de acuerdo a la relación del usuario con el software y sus

necesidades Incorporar diferentes niveles en los juegos Entregar progresivamente las posibilidades de construcción Utilizar metáforas relacionadas con la experiencia del alumno

6.2. Navegabilidad

Las posibilidades que tenga el usuario ciego de desenvolverse en el espacio virtual están directamente relacionadas con la posibilidad de construir mentalmente el espacio que navega y basándose en ello, desplazarse. Este desplazamiento debe ser a través de pistas programadas en las funciones del teclado, así como de pistas auditivas claramente definidas. La navegación en un software de este tipo debe efectuarse mediante teclado, de esta forma el usuario ciego podrá acceder al software de manera autónoma. Las teclas que se deben utilizar para estos fines deben tender a la estandarización, ya que de esta manera el uso de un nuevo software no implicará un nuevo aprendizaje en lo que se refiere a interacción. En consecuencia, el software deberá permitir al usuario moverse por los distintos botones presionando alguna tecla por definir (se sugiere el tabulador), desplegar menús en el caso de que los haya y desplazarse a través de los mismos. A medida que el usuario ciego se posiciona en cada uno de los botones deberá proporcionarse una retroalimentación auditiva que otorgue el nombre del botón o icono, junto con leer los menús.

6.3. Interactividad

Un software es interactivo cuando permite una retroalimentación inmediata con el usuario, aspecto que favorece la interacción cognitiva por la cual el usuario comprende y cambia su entendimiento, lo que ayuda a desarrollar la estructura del pensamiento. La interactividad del usuario con discapacidad visual con el software debe ser a través de pistas audibles, imágenes bien definidas, y con la utilización de teclas y/o comandos estandarizados previamente. En un usuario ciego la interactividad debe favorecer el desarrollo de la iniciativa y potenciar el autoaprendizaje, a través de un aprendizaje heurístico que permita y estimule el descubrimiento y la aplicación de los contenidos aprendidos en el software a otras áreas de su educación.

6.4. Contenido

En un software diseñado para personas con discapacidad visual las instrucciones que se proporcionan deben ser audibles, ya que éste no podrá leer órdenes o enunciados que aparezcan en la interfaz. No obstante éstas igualmente pueden existir para las personas videntes y con baja visión que utilicen el recurso. Las instrucciones verbales deben ser claras, precisas y breves, ya que el usuario deberá recordarlas al momento de interactuar con el software. Por esta razón, es recomendable que el usuario tenga también la posibilidad de volver a escuchar estas instrucciones cuando así lo requiera.

6.5. Interfaz Fuentes: La tipografía a utilizar debe ser de palo seco, evitar en lo posible utilizar tipografías romanas o con serif, a menos que sean todas en mayúsculas, descartar completamente el uso de tipos decorativos. Tamaño no menor a los 18 puntos, con un interletraje medio, debe ser de un color que posibilite un buen contraste con el fondo sobre el cual se encuentra. Cabe destacar que los contrastes más favorables para las personas con baja visión son amarillo-azul, negro-blanco. Imágenes: Deben poseer un buen contraste con los fondos, deben ser sencillas, claras y precisas, de manera tal que el usuario pueda reconocerlas fácilmente con sus restos visuales. Por lo general, se opta por imágenes más icónicas que fotográficas. Colores: Fuertes y contrastantes, de preferencia dentro de la gama de los azules y amarillos, ya que estos tonos son los que percibe de mejor manera una persona con visión residual, debido a que son diametralmente opuestos tanto en croma como en luminiscencia. Iconos: Simples, grandes, con un mensaje claro, de buen contraste con el fondo. Deben ser interpretados fácilmente por el usuario, además deben tener asociada una locución o sonido para que la persona ciega pueda saber dónde se encuentra posicionado y las posibilidades que este icono proporciona.

Botones: Deben ser grandes y sencillos, además a ellos debe estar asociada una locución o sonido, para que los usuarios ciegos puedan saber dónde se encuentran posicionados y cuál es su función. Audio: En el caso del software para personas ciegas el audio se convierte en el componente más importante del producto, por esta razón éste debe ser de la más alta calidad y contemplar todas aquellas instancias donde se hace imprescindible su existencia. La utilización de este medio se justifica en la presentación del producto, en las diferentes instancias de interacción, en la descripción de los iconos, botones, lectura de menús, musicalización de contexto, etc. Las locuciones que se incluyan en el producto deberán ser realizadas por voces congruentes con el grupo de usuario al cual está orientado el software, es decir, si el recurso es un producto para niños se sugiere emplear una voz entretenida y motivadora, que posea una buena articulación y que sea grata de escuchar.

7. Conclusiones Este trabajo reporta la formulación de un modelo para enTornos Interactivos basados en Sonido para Aprender, mTISA. El modelo responde a una necesidad por modelos de desarrollo de software para niños ciegos, tanto para futuras réplicas en otros contextos, como para fines de evaluación y mejoramiento de software. El modelo mTISA es un modelo de procesos con su arquitectura, incorporando funcionalidades para evaluar y retroalimentar al aprendiz, así como establecer diferencias cualitativas en el desarrollo de software educativo para personas con y sin discapacidad visual. Junto con presentar y describir formal y operacionalmente el modelo mTISA, se proponen guidelines para el diseño de software educativo para niños ciegos sobre la base de una tipología, así como también se discuten los principales atributos genéricos que debe incorporar dicho software. El próximo paso de los autores será evaluar la viabilidad de dicho modelo en productos de aprendizaje basados en sonido ya elaborados para niños ciegos, para luego dar paso a la construcción de nuevo software que se ajuste fielmente al modelo y lo valide en distintos contextos de aprendizaje de niños ciegos. Con ello, se espera contribuir con un modelo explícito y funcional que permita su generalización y replica en el campo de la educación de los niños ciegos.

8. Agradecimientos Este reporte ha sido financiado por el Fondo Nacional de Desarrollo Científico y Tecnológico, Fondecyt, Proyecto # 1030158. 9. Referencias 1. Lumbreras, M., Sánchez, J. Interactive 3D Sound Hyperstories for Blind Children. CHI ‘99, Pittsburg PA, USA (1999), 318-325. 2. Roth, P., Petrucci, L., Assimacopoulos, A., Pun, Th. Concentration Game, an Audio Adaptation for the blind. CSUN 2000 Conf. Proceedings, Los Angeles, USA http://www.csun.edu/cod/conf2000/proceedings/gensess_proceedings.html . 3. Sánchez, J. Interactive virtual acoustic environments for blind children. Proceedings of ACM CHI ´2001, Seattle, Washington, April 2-5, 2001, 23-25. 4. Dillenbourg, P., Self, J.: A Framework for Learner Modelling. Interactive Learning Environment Vol. 2, Issuse (2), pp. 111-137,1992. 5. Mereu, S., Kazman, R.: Audio enhanced ·D interfaces for visually impaired users. Proc. ACM CHI 96 (1996), 72-78 6. Morley, S., Petrie, H., O’Neill A.-M., McNally, P.: The Use of Non-Speech Sounds in a Hypermedia Interface for Blind Users, in Edwards, A.D.N., Arato, A., and Zagler, W.L.(Eds.):’Computers and Assistive Technology’. Proc. ICCHP’98. XV, IFIP World Computer Congreso (1998) 205-214 7. Ressler, S., Antonishek, B.: Integrating Active Tangible Devices with a Synthetic Evironment for Collaborative Engineering. Proc. 2001 Web3D Symposium. Paderborn, Germany, Febr. 19-22 (2001) 93-100 8. Savidis, A., Sthphanidis, C.: Developing Dual User Interfaces for Integrating Blind and Sighted Users: HOMER UIMS, Chi’95 conf. Proceedings, Denver, CO (1995) 106-113 9. Savidis, A., Sthphanidis, C., Korte, A., Crispie, K., Fellbaum, K.: A generic direct-manipulation 3D-auditory environment for hierarchical navigation in non-visual interaccion. Proc. ACM ASSETS 96 (1996) 117-123 10. Zajicek M., Powell C., Reeves C.: A Web Navigation Tool for the Blind, ASSETS’98, 3rd ACM/SIFCAPH Conf. On Assistive Technologies, Los Angeles, USA (1998) 204-206 11. Brewster, S.A: Using earcons to improve the usability of a graphics package. HCI’98, People and Computers XIII, Sept. 1-4(1998) Sheffield Hallam University, Sheffield, UK 12. Blattner, M., Sumikawa, D., and Greenberg, R.: Earcons and icons: Their structure and common design principles. Human-Computer Interaction 4, (1) (1998) 11-44. 13. Lange, Max O.: Tactile Graphics – as easy as that. CSUN’s 1999 Conference Proceedings. March 15-20, Los Angeles, USA 14. Baloian, N., Luther, W., Sánchez, J.: Modeling Educational Software for People with Disabilities: Theory and Practice. Submitted to ASSETS 2002 conference 15. B.P. Zeigler, Theory of modeling and simulation, Wiley, New York, USA, 1976

16. Kass, R.: Student Modeling in Intelligent Tutoring Systems –Implications for User Modeling User Models in Dialog Systems (A. Kobsa & W. Wahlster,eds.), pp. 386-410, 1989 17. Clancey, W.J., Methodology for Building an Intelligent Tutoring System”, en KEARSLEY, G., “Artificial Intelligence and Instruction - Applications and Methods, pp. 193-227, 1987. 18. Sánchez, J. Aprendizaje Visible, Tecnología Invisible. Santiago: Dolmen Ediciones, 2001.